axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: [axis2] More Modules and classpaths
Date Sat, 02 Jun 2007 07:02:48 GMT
On 6/1/07, Glen Daniels <glen@thoughtcraft.com> 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.

thanks,
Amila.

Cheers,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Amila Suriarachchi,
WSO2 Inc.

Mime
View raw message