Folks,
Comments inline
Simon Laws wrote:
Hi Rajini
Re. 4 on Simon's list. Maybe it is useful to more clearly distinguish
between those Tuscany modules that are expect to be loaded statically,
assembly, core, etc and those that expected to be loaded dynamically,
binding.?, implementation.? etc. I find the term "module" a little
unsatisfactory. Raymond, in his diagram, used Tuscany core and Tuscany
extension and in a previous post used Tuscany runtime and Tuscany
extension. I prefer the latter pair just because we have a maven module
called core.
+1
This leads to a 4a and 4b based on Raymond's post/diagram
4a Tuscany extension module code shouldn't be able to see other extension
modules (not sure what the dotted line on the diagram implies but I expect
that it's to do with modules like binding-ws-axis2 and binding-ws
interacting) or application code or Tuscany runtime code other than via the
SPI.
Hmm, first, this ain't the case today and it will need some thought.
The "Java" extensions do share code and it would be crazy for them not
to share the code. So, Spring uses stuff out of the base Java extension
- and I am sure that other "Java" type extensions would want to do the
same.
In an OSGi world, it would be fine to express the dependency in a simple
way. For non-OSGi I'm not sure of the best route.
I suspect that other extension types may want to share stuff as well.
4b Tuscany runtime code shouldn't be able to see Tuscany extension code or
application code.
That sounds a bit odd. Perhaps I've not got the right end of the stick,
but the some code - either core and or extensions has to get very
intimate with the application code. Introspection, instantiation,
injection - all has to be done either by core code or extension code.
Perhaps I've not understood the separation you're looking for?
Then, from reading your comments, we have to be clearer about what the SPI
is providing an interface to because it current includes interfaces to the
underlying runtime modules but also the host-embedded classes which strike
me as being more API than SPI. We are reorganizing the domain/node
interfaces at the moment so hopefully we can clear this last point up as
part of that.
Regards
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
