Jim Marino wrote:
On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote:
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?
That's exactly what we have, a clean SPI with mostly interfaces.
Container.java and core, however, both use java Pojo's (system
services, and Java C&I components) so there are some common reflection
and injection related classes. It doesn't make sense to duplicate
those classes and related test cases and maintain exact replicas in
two different projects of a significant amount of code. On the other
hand, keeping container.java separate and referencing those core
classes sends an unclear message to extension developers. The other
option, putting the implementation classes in SPI is in my view also
wrong for two reasons. First, they are implementation-related, Second,
they are not things we want to expose in the SPI.
So, to recap, we have a separate SPI extension package that does not
require extension developers to reference the core implementation.
Core, for example, is built on SPI. The issue I was bringing up in
this thread is that as core and container.java share a significant
amount of implementation, and container.java is central to both SCA
and the Java Tuscany implementation, it makes sense to combine the two
as opposed to duplicating the shared implementation.
Jim
--Jean-Sebastien
---------------------------------------------------------------------
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]
If I understand correctly, container.java and core both share utility
classes that handle reflection and handling of Java annotations. Since
we are a Java runtime other extensions and contributions to Tuscany will
probably need this kind of utilities so I'd like to propose that we
package them in tuscany-common.jar. This way they won't get mixed up
with the SPIs (I agree with you that putting implementation classes in
the SPI JAR is not good, I think the SPI JAR should just contain
interfaces), and we can keep the java implementation extension and the
core separate, which I think is important.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
