On 10/5/06, cr22rc <[EMAIL PROTECTED]> wrote:
Ken Tam wrote: > While working with Andy on fixing some of the Spring samples, and > taking a look at the way the war plugin has replaced the web distro, I > ran into a number of issues relating to extensions and their > dependencies. > > 1) It's not obvious how someone building a webapp sample expresses > their requirement for a particular extension. Given the maven focus > of our current infrastructure, the current way it seems this is done > is to just include the extension artifact as a <dependency> entry. > Does anyone have a better proposal? I think some metadata might help > here -- see the next point. > > 2) The war plugin doesn't understand extensions. Right now, anything > that's a <dependency> by default gets put into WEB-INF/lib, and it > might get moved into WEB-INF/tuscany/boot if the plugin determines it > only be a transitive dep of the webapp-host. This is totally > disconnected from the webapp extension loading mechanism, which > requires something to be present in WEB-INF/tuscany/extensions. So it > seems the war plugin could benefit from understanding what > dependencies are actually extensions, so it could populate it in the > right place. I would expect the standalone case to be similar (ie, > the sample build would also need to figure out to put it in the > extension directory where the DirScanExtender looks). I'm thinking > about adding metadata to the POM for extensions so that they can be > identified as such, but haven't thought about how to do this yet.. Maybe I'm misunderstanding but take a look at http://svn.apache.org/repos/asf/incubator/tuscany/java/sampleapps/bigbank/account/pom.xml If you look under tuscany-war-plugin in the build there are depenency elements. This gets me in the wars: WEB-INF\tuscany\extensions axis2-1.0-incubator-M2-SNAPSHOT.jar databinding-axiom-1.0-incubator-M2-SNAPSHOT.jar databinding-sdo-1.0-incubator-M2-SNAPSHOT.jar wsdl-1.0-incubator-M2-SNAPSHOT.jar But I admit don't know where this is documented. If it's even what your asking about.
That's exactly it, thanks for the pointer -- I should have grovelled the mojo more closely. This comment: /* Adds the extension artifacts specified using configuration/extensions to WEB-INF/tuscany/extensions */ actually explains it, it just wasn't clear to me that configuration/extensions mapped to corresponding elements in the POM. I see there's also handling for transitive dependencies of extensions, which I suspect will rapidly run users into the classloader issues I mentioned previously.
> 3) Extensions are loaded into a classloader that isolates them from > the application logic (the exact code in deployExtension() has FIXMEs > suggesting that while the exact classloader to be used is in flux, the > principal of isolation is true). Extensions often have their own > dependencies, which I believe fall into 2 categories: > > a) deps which need to be surfaced to application logic, and thus > shouldn't be in the same isolating classloader as the extension > itself. > b) deps that ought to be hidden from application logic, and can be in > the same isolating classloader. > > Taking the Spring extension as an example, the Spring framework jars > themselves would be type A deps. Right now, there is no clear way to > manage this -- for example, via maven the dep between the Spring > extension and the Spring framework jars is "just another dependency" > and so get treated just like any other jars. > > I'm starting to think that it may actually be counter-productive in > the short term to attempt automation of all this -- dependency > management in general tends to be a hard problem to automate anyways > (look how long it's taken maven to attack, and it's still nowhere near > perfect). The war plugin attempts to automagically figure out where > all jars need to go, but as I think I've shown, there's a lot of > missing metadata needed to do that right. What do folks think about > simplifying it by being more explicit, and then slowly moving back to > a more automatic model? > However even though I think the war plugin can put things in the right place for me it all still doesn't work at runtime. Last I tried it failed cause of this http://issues.apache.org/jira/browse/TUSCANY-765 Basically to make further progress for Big Bank I have an extremely ugly bat that essentially puts all back in web-inf/lib. Then in WEB-INF\tuscany\extensions all I have is a single scdl file that includes in a subdirectory the scdl of the extensions. This is so I can control the order its loaded. I essentially have BB now working with the fixes I put in for HTTP session support, and may others. So now this deploy and 765 is AFAIK the last hurdle to making it work "out the box."
Yeah, I haven't run into the ordering issue because I'm just dealing with individual extensions, but that completely makes sense. It feels like if we're going to stay on the track of this maven(-like) depot system for managing extensions, I would support going whole hog and relying on the POM to express all dependencies -- then your comment in 765: "If we plan on supporting just dropping in of extension jars to a directory will need a means to either prescan to resolve their dependencies or load all and then begin to autowire." would be addressed by doing the same kind of "prescan/resolution" that maven does today when there are transitive and redundant dependencies. Otherwise it feels like we are signing up for an increasingly crappy user experience as they are forced to understand what extensions depend on what other ones and in what order. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
