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.
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."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
