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]
I would prefer another option: Define a clean SPI contract with just
interfaces so that containers (component implementation extensions) do
not have to depend on internal classes from the core project. I thought
that it was the reason for having an SPI project separate from core.
I think that the core runtime and the java container should be decoupled
with clean interface-based contracts between the two. What are the
technical issues preventing us from achieving that?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
