I'm leaning towards combining them because separating commonalities
out into a third project is basically creating an "SPI2". Also, most
of the stuff that would be pulled out is related to injection and
reflection which I don't think we want to expose as an API at this
point.
Jim
On Jun 20, 2006, at 8:09 AM, Jeremy Boynes wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
