You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Saminda Abeyruwan <sa...@gmail.com> on 2008/03/14 13:20:05 UTC
[Axis2] Improvements to engaging modules in Axis2
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. Even if use has given axis2.xml that comes with
server, this could fail, if it is optimized for server.
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
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
http://ws.apache.org/axis2/qos/Sandesha2-1.5.mar<http://wos2.org/qos/axis2/Mercury-1.0.mar>or
file:/usr/local/share/Ramprt-1.4.mar<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.
Thank you
Saminda
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: [Axis2] Improvements to engaging modules in Axis2
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Saminda,
Could you live with a ExtensibleAxisConfiguration that extends AxisConfiguration and put these methods on it? You can do
that right now :) no?
- -- dims
Saminda Abeyruwan wrote:
| 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. Even if use has given axis2.xml that comes with
| server, this could fail, if it is optimized for server.
|
| 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
|
| 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
| http://ws.apache.org/axis2/qos/Sandesha2-1.5.mar<http://wos2.org/qos/axis2/Mercury-1.0.mar>or
| file:/usr/local/share/Ramprt-1.4.mar<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.
|
| Thank you
|
| Saminda
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFH2nLggNg6eWEDv1kRAjbnAKCovk8b1iDbV/tVhuqk7xvmZVxK2ACfWf9s
CgTlxs437gMhPnELHSi7las=
=VfnC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Improvements to engaging modules in Axis2
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I personally would prefer if we make changes if at all we agree after we get 1.4 out. Please create a JIRA so that we
don't forget.
- -- dims
Deepal Jayasinghe wrote:
|
|> 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
| AxisConfiguration.
|
| 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
|> http://ws.apache.org/axis2/qos/Sandesha2-1.5.mar 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!
| Deepal
|
|
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFH29nbgNg6eWEDv1kRAqBWAKD1pw7j3Oaa6YkJhA3mGwi4UnkTlQCgpbIq
YRXmpJ+tK6Jp816sc31JIiM=
=WmwE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Improvements to engaging modules in Axis2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> 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
AxisConfiguration.
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
> http://ws.apache.org/axis2/qos/Sandesha2-1.5.mar 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!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org