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]
