I definitely agree that we should not be putting implementation into spi. We've been down the duplication path before and it did not work - the system and java containers quickly started to skew from each other (e.g. autowire only works for system components).
Is there a way in which we can factor implementation "shared" by the system and java containers into a separate module? That would provide a common basis for other containers based on a POJO IoC model; however, implementation dependencies may well pull in a lot more of core than appropriate. It would only be worth doing if we expected a lot more containers that can use that infrastructure - I'm not sure that will be the case as others are likely to have a different programming model. Given that I think the approach of merging them together combined with a example of a simple POJO container is the least worst option. -- Jeremy Jim Marino wrote: > In trying to eliminate reliance on core2 by container.java in the > sandbox and have it only rely on the extensibility SPI, it occurred to > me that this would mandate moving a lot of implementation classes from > core2 into SPI. I believe having container.java as a separate project > rely on core2 is the wrong approach. This leaves three options: > > - move the required classes to SPI > - make container.java not dependent on core classes by duplicating them > - merging container.java with core. > > I think moving the classes to SPI is not the best approach since they > are implementations. Having duplicate classes does not seem to be the > optimal approach either as that will result in a maintenance burden and > a lot of code repetition. As background, the sharing of classes > between core2 and container.java arises from the fact that the runtime > uses a POJO model to assemble system services, and hence there is > commonality between the two. > > I prefer to do the latter as it appears to be the cleanest. Also, > java.container is not a very good example of how to extend the > recursive core due to its "advanced" capabilities. I'd rather include a > simple Java container geared to demonstrating how to extend the > runtime. It would be helpful if people provide input over the next > day...I plan to implement choice 3 tomorrow if there are no alternatives. > > Jim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
