axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal Jayasinghe <>
Subject Re: [Axis2] Improvements to engaging modules in Axis2
Date Fri, 14 Mar 2008 14:29:02 GMT

> Hi Devs,
> We have a use case where  a client or stub need to be invoked from a 
> web service running in server side. If this client or stub need to use 
> any QOS such as security etc,
> [1]. It needs to create an AxisConfiguration pointing to a repository 
> containing such modules
> [2] It could use the AxisConfiguration that is available from server, 
> if the server AxisConfiguration has relevant QOS modules.
> If the client uses the first approach, it needs to point to a 
> repository   and possibly to an axis2.xml. Thus, either the user has 
> to use the server's repository or user has to ship his own one. If 
> user uses the server's repository, this would possibly cause axis 
> faults from different reasons. Ex: if the repository contains services 
> that need https or jms transport and if user has given default 
> axis2.xml or some other axis2.xml, user cannot create AxisConfiguration.  
Nope that will not happen , service deployment issues will not affect 
the creation of AxisConfiguration. So if your services in the repo need 
jms or https support then , that will not affect creation of 

Well what I can suggest is to add your modules into classpath and then 
create serviceClient using its default constructor , or create default 
AxisConfiguration and then create ServiceClient. In either case you will 
get support for all the modules in the class path.
> Even if use has given axis2.xml that comes with server, this could 
> fail, if it is optimized for server.
hmm , can you please explain this a bit.
> If the client uses 2nd approach, it could also produce axis faults, if 
> the user is not aware of the environment.
> Thus, the most safe and user centric way to support this scenario is 
> to give the user the ability to create a default AxisConfiguration and 
> later allow the user to "install" modules into AxisConfiguration. 
> Thus, this would require an extension to AxisConfiguration ,say
Well still you can do that without introducing new class or interface 
just use following methods in DeployementEngine

DeployementEngine.buildModule(File , axisConfiguration) ;
> public class AxisConfiguration .. {
>   ...
>   // Install a module to Axis2
>   public int installModule(URL moduleLocation) throws AxisFault {...}
>   // Uninstall a module with the given id or url
>   public void uninstallModule(int id) {...}
>   public void uninstallModule(URL moduleLocaiton) throws AxisFault {...}
> }
> Thus, user can create an empty AxisConfiguration and later he could 
> install a module say Sandesha2.mar from 
> or 
> file:/usr/local/share/Ramprt-1.4.mar or from a public registry and do 
> users work. "installModule" only install a given module archive with  
> .mar extension and nothing else and produced an unique id that can be 
> later used to reference that module.
> Later one could remove (merely uninstall) a module saying, 
> AxisConfiguration#uninstallModule(URL moduleLocation) or 
> AxisConfiguration#uninstallModule(int id) giving an ID that coming 
> from when installing the module.
> Simply,  we would like a way to install modules (only the required 
> ones) from runtime, if the associated AxisConfiguration dose not have 
> the required modules.
I understand what you mention here , however as I mentioned above you 
can get that working without changing AxisConfiguration. Anyway I have 
no problem with adding those above methods into AxisConfiguration.

So I am 0+ on this

Thank you!

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

View raw message