axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <>
Subject Re: [axis2] More Modules and classpaths
Date Sat, 02 Jun 2007 07:02:48 GMT
On 6/1/07, Glen Daniels <> wrote:
> Hi folks!
> Deepal Jayasinghe wrote:
> > Paul Fremantle wrote:
> >> Yes that wasn't the behaviour I was expecting!
> Me neither, and I think the current way of doing things is both
> unexpected and potentially dangerous.  Consider this:
> CLASSPATH=/dev/axis2.jar;/otherStuff
> where we have
> /dev
>    axis2.jar
>    unused-module.mar
> The normal expectation here is that the user gets exactly what she puts
> on the classpath - axis2.jar IS on the classpath, so of course classes
> from that JAR will be loaded.  The mar file in /dev, however, is NOT in
> fact on the classpath, and in this case the user has dropped an unused
> (perhaps experimental) mar file in their development directory.  With
> our current code, all of a sudden that module is active in the Axis2
> installation, which seems very inappropriate to me.  Also, what if the
> user WANTS a module on the classpath, but doesn't have write access to
> the directory where axis2.jar lives?
> Java classpath management is tricky enough already without suddenly
> loading classes from places that the user did NOT specify just because
> Axis2 decided that "parallel" mars are now fair game.  Had I noticed
> this behavior when it went in, I'm pretty sure I'd have -1'ed it at the
> time.
> I would much rather see us respecting explicit additions of modules to
> the classpath, which lets them live anywhere the user wants to put them,
> than continue the current behavior.
> >> The idea of putting modules in the classpath was motivated by the
> >> following scenario:
> >>
> >> I have a client, I don't want to set up a "repository" because I'm
> >> just deploying this client somewhere on someone's filesystem, so I
> >> can't point to a modules directory easily. So I can just stick
> >> addressing.mar into the client classpath to enable addressing.
> > Yes , agreed.
> Hm, the scenario Paul is talking about is exactly what I want to do...
> have you changed your mind? :)
> >> However, this only works in the case where the modules don't require
> >> changes to the Axis2.conf. Unfortunately, the Sandesha2 module
> >> requires the axis2.conf to have some phases added. Now personally, I
> >> think it might make sense to add the RM phases into the default
> >> Axis2.conf, but nonetheless, maybe we should also address how to make
> >> it easy to supply an axis2.conf as well that replaces the inbuilt one.
> > +1 for adding RM and Security related phases into axis2.xml
> -1 to adding RM phases into axis2.xml.  (Don't we already have a
> "Security" phase in there, though?)
> +1 for allowing module configurations to add Phases as easily as they
> add Handlers, which neatly solves this problem.
> <module name="Security">
>    <InFlow>
>      <!-- Add Decrypt phase if not already present.  If it's there -->
>      <!-- already, just confirm that it matches these rules (i.e.  -->
>      <!-- after Transport)                                         -->
>      <phase name="Decrypt" after="Transport">
>        <handler name="DecryptionHandler" class="..."/>
>      </phase>
>      <handler name="OtherHandler" class="...">
>        <order phase="Dispatch"/>
>      </handler>
>    </InFlow>
>    ...
> </module>

I am not sure the practical limitations of doing this but,
+1 for adding Phases in InFlow and OutFlow and placing them using the phase
order rules like
in handlers. I belive this would allow us to develop modules as real
pluggable components.


> --Glen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Amila Suriarachchi,
WSO2 Inc.

View raw message