Ok I still really have little idea how dependencies are classloaders are going to work for M2, and this worries me a bit as I've had to spend so many hours in the past sorting out classloader issues in Tuscany. If the <dependency> element is optional and I don't use one and don't use Maven meta-data is there any way to handle dependencies? If i want to use AXIOM in my app and shared across the WS binding and the JavaScript container how do I get the AXIOM classes in a common classloader? How are the data binding extensions going to be using the correct classloader for a container or application? I know you said I could share AXIOM between two extensions by adding it as a dependency of a composite that is their parent but could you give an example of what that looks like for those examples? I expect i'm just being slow, so sorry for all the questions.
...ant On 9/17/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
