>> Does the first way of packaging outlined above meet your needs? I think it is a sensible way of packaging in the interim. However, as you mentioned there should be a more robust deployment model in the long term and it should be driven from a specification perspective rather than treated as an implementation issue. We also need to look into how SCA deployment model can work together with J2EE packaging and deployment model.
>> if you would like to help for Tuscany, just jump in by proposing some ideas to the list Thanks, I would definitely like to. I am familiarising myself with the codebase and running the sample apps. Once I am familiar with the stuff, I wouldn't mind helping out with docs, clearing compiler warnings etc, if you don't mind. We use Mule quite a bit at work and one of the things I find quite good with Mule is the ease of switching between different transports. Though, Mule's way of doing things in a loosely coupled manner on a SEDA-based model is quite elegant, in scenarios where you need strong typing we end up building custom stuff on top of Mule using dynamic proxies that expose strong interfaces and abstracts the interactions with the Mule event bus. This is one thing I quite like in SCA, the way it supports interface-based interactions. Ta Meeraj -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 01 May 2006 22:51 To: tuscany-dev@ws.apache.org Subject: Re: Location of sca.module J2EE deployment integration was one of the to-do items for the spec group (it hasn't been done yet). In terms of the scenario you outlined, I think it would be cleaner to package fragments in the jar files and the sca.module file in the war. This means there is one module per war but I think that is the cleanest approach (and it's what we support with Tomcat) since modules are generally things that are evolved and deployed together, it avoids having to deal with child classloaders, and it makes mapping module components to URIs much easier. Longer term I don't think this will provide a very robust deployment model for the scenarios SCA is designed for and we have been looking at OSGi as a more flexible mechanism. I'm planning to do an OSGi integration when we finish up with the JavaOne release if you are interested. I believe others are interested in deploying to Geronimo so we will need to figure out a broader J2EE deployment story sometime soon (if you would like to help for Tuscany, just jump in by proposing some ideas to the list). Does the first way of packaging outlined above meet your needs? Jim On May 1, 2006, at 1:46 PM, meeraj kunnumpurath wrote: > Thanks Jim. > > I was also thinking about how an SCA deployment unit would be loaded > within the context of a J2EE container. For example, if two module JAR > files are included in the WEB-INF\lib directory of a WAR file, then > would we need to child classloaders to the WAR classloader responsible > for loading each of the SCA modules. Or is there a different behaviour > expected in terms of classloader hierarchy as part of the SCA runtime? > Also, does SCA assembly model define how SCA modules are expected to > be deployed in a J2EE environment? > > Ta > Meeraj > > >> ----- Original Message ----- >> From: "Jim Marino" <[EMAIL PROTECTED]> >> To: tuscany-dev@ws.apache.org >> Subject: Re: Location of sca.module >> Date: Mon, 1 May 2006 13:14:55 -0700 >> >> >> There should be one module file per deployment unit. To get the >> intended behavior I believe you want (i.e. a module definition >> composed of a number of fragments), use sca.fragment files and places >> them in the classpath as they will be merged during load. >> On a file system, the directories would just need to be on the >> classpath. >> >> That said, the SCA deployment story needs a lot of work (some of >> which is currently underway). Having only one "top-level" >> sca.module file per deployment unit is a good thing since the URI is >> defined there. I'm not too keen on the classpath merge with multiple >> fragments and we've discussed a plan to move to more of an "include" >> style (i.e. sca.module can include a bunch of fragments or fragments >> can "include themselves" into a module). >> >> Let me know if you run into issues with the existing approach or have >> ideas on making things better. >> >> Jim >> >> >> >> On May 1, 2006, at 7:44 AM, meeraj kunnumpurath wrote: >> >> >>> Hi, >>> >>> Could someone please shed some light on the expected behaviour when >>> more than one sca.module file is found within the scope of the >>> thread context classloader? The spec requires a packaged module JAR >>> file to have exactly one sca.module file at the root. >>> Would this require each module JAR to be loaded by its own >>> classloader. Also, how would this work if the deployemnt unit is a >>> folder in the file- system? >>> >>> Thanks in advance >>> Meeraj >>> >>> -- _______________________________________________ >>> >>> Search for businesses by name, location, or phone number. -Lycos >>> Yellow Pages >>> >>> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ >>> default.asp?SRC=lycos10 >>> >>> >>> > > >> >> > > > -- > _______________________________________________ > > Search for businesses by name, location, or phone number. -Lycos > Yellow Pages > > http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ > default.asp?SRC=lycos10 > > This message has been checked for all email viruses by MessageLabs. ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs.
