On Sep 17, 2006, at 2:37 AM, ant elder wrote:
From whats been posted previously about this I'm still not really
clear
exactly how things are going to work. Here's a couple of questions:
Are composites required to use the non-standard dependency element
in the
SCDL? I'm hoping not and that there will be a way to get things
working
without that
They are not - that's value add that Tuscany provides. Unfortunately,
the spec does not define a mechanism for packaging code etc. with a
composite so there is no non-"non-standard" way to do it. Things that
are standard in Java, like Class-Path's specified in jar files, still
work but even using JAR files is "non-standard".
The <dependency> element I think is useful as it allows you to define
a composite using just a bare XML file - there's no need to bundle it
up into a JAR file just to associate the code with it. Using
declarative dependencies also allows the runtime to support different
resolution strategies which is good.
AIUI we will also be supporting dependencies from the Maven meta-data
in a jar - so if someone used Maven to build the war (or added the
info themselves) then we will be able to pick that up automatically
and they would not need to specify a <dependency> element at all.
Jim has also mentioned using OSGi bundling as well and I think that
would be another alternative we could support. If you have
suggestions on another way to get things working let's figure out how
we can make them all work together.
What does the classloader hierarchy look like for a complete
system? -
Could there be a couple of examples showing what classloaders
exist, what
their parents area and what jars they hold for a system which has a
couple
of extensions and and application composite?
I agree we need good documentation on the classloading strategy and
how it works.
One thing i'm wondering about
here is how classes get shared, say there are two extensions using
OMElement
then where do the AXIOM jars go?
We're trying to keep the classloading approach separate from where
the jars go. Experience has shown that using location to define
classloading hierarchy is not sufficient to cover the ways in which
people want to share or isolate the code. So the simple approach is
to put all the JARs in a well known place/structure (the repo) where
they can easily be used by a classloader hierarchy.
To answer your question, it depends on whether they two extensions
want to share AXIOM code (because they interact) or be isolated from
each other (to avoid coupling). SCA by default isolates composites
from each other (e.g. all peer interactions are by-reference) so if
the two composites are peers then they would each have their own copy
of AXIOM to fit the way the assembly spec works. If on the other hand
the two composites are related to each other then they would have a
common ancestor and the sharing would done by that ancestor. Putting
it another way, you can share AXIOM between two extensions by adding
it as a dependency of a composite that it their parent. This seems
natural as it works in the same way normal Java classloading does
where classes in parent classloader are shared by all its children.
I like being able to load all the dependencies into a WAR, for one
thing I
think it makes it much more obvious whats going on when you can see
all the
jars in the war. But, a war now ends up being quite complicated -
there's
the classes dir, the lib dir, the tuscany/boot dir, tuscany/
extensions, and
now also tuscany/repository with all its sub directories.
I think you've hit the nail on the head right here - if you put
everything in the jar then you get everything in the jar and it is
complicated. That is one reason for allowing people to externalize
the code so that we can make the jar simpler.
Is there anyway
there could be a more simple setup? For example, tuscany/boot is
really a
single flat directory for the Tuscany runtime jars, so could there
be a
similar way for extensions to also use a single flat directory?
We are doing that - WEB-INF/tuscany/extensions is a single flat
directory. Where the repo kicks in is for the hierarchy of
dependencies that all of those extensions have. With the advantage of
being able to reuse any of the Maven repos available to you on the
internet or in more secure locations inside your organization.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
