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]
