Sanjiva Weerawarana wrote:
On Tue, 2005-11-22 at 13:38 +0000, Steve Loughran wrote:
I actually create .aar files with no .class in them, just the
declaration, and make sure the real classes are in the same webapp.
Why do you do that? Is there a particular reason you don't want to
package up the service classes in the .aar?
1. when I started using axis2 0.92 you only had one service per aar; I
had two EPRs so had no other choice. Given the amount of effort it took
to get up to the state where axis.093 worked I have no desire to made
needless changes to other parts of the process.
> My concern is making other dependent jars available on the classpath
and doing so without affecting other applications.
remember, each webapp has its own classpath in WEB-INF/lib; anything
goes in there is private and webapp-wide.
Take a look at
http://marc.theaimsgroup.com/?l=axis-dev&m=113073286309556&w=2
(This has already been fixed and committed.) So we now have a very
flexible class loading model and I'm unclear why you don't want to use
it and want to drop down to putting everything in the webapp class
loader. You *of course* can do that .. but its not as flexible or
powerful as what we now have in Axis2 (think service versioning for
example (for which I have a proposal in progress)).
2. I am deploying under smartfrog, in a smartfrog started process
(http://smartfrog.org/). In a deployment descriptor, deploying the axis2
and jetty components in a new VM is as easy as declaring the process
name in the composite descriptor
myWebApp extends Axis2Webapp {
sfProcessName "newProcessName"
}
which itself could be redeployed on a new host
remoteWebApp extends myWebapp {
sfProcessHost "server.example1.org";
}
During undeployment the entire process will be terminated, so you have
100% sureness that the next deploy will pick up updated jar files, not
have legacy data stuck up on the servlet session, etc.
While I think hot deployment is good for iterative dev of things like
JSP and HTML pages, when it comes to code with lots of state, a fully
automated restart mechanism is far more reliable. Indeed, if you can
tear down the entire system image and rebuild it on demand, you have
absolute control over system state.
So to conclude, I think my deployment framework is more flexible and
powerful than those built into single applications, be they axis2,
jboss, tomcat, BIND, Vmware, mySQL whatever. We can handle them all in
a single deployment operation over a secure channel, then federate that
to the 500 nodes of a supercluster.
All I am trying to do w/ Axis2 is provide a SOAP interface for long-haul
deployment, and come to terms with the requirements for WSRF integration
that the grid people want.
Dims has been trying to rebuild my stuff, he will probably have
different opinions, especially about the complexity/brittleness of the
build process, which pushes both ant1.7alpha and the maven2 tasks to
its limits.
-Steve
