axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: [axis2] More Modules and classpaths
Date Fri, 01 Jun 2007 12:57:25 GMT
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>

Cheers,
--Glen

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


Mime
View raw message