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 Srinath Perera <he...@opensource.lk> on 2004/07/29 04:29:01 UTC
Hot WS Deployment In Axis
To which extent the Axis supports the Hot deployment of the web services ?
1) We can use the admin client to add the entry to the server-config.wsdd
2) But how about loading the class files .. To my experinace so far we
need the class files present at the classapth when axis started.
For the Geronimo Integration I think we need that hot deployment feature.
If it is not there I would try to .. like to hear any comments plus the
pointers to what is the best way to implement it.
Thanks
Srinath
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Davanum Srinivas <da...@gmail.com>.
For #1, we should start picking up steam on JSR 181
(http://www.jcp.org/en/jsr/detail?id=181) based on Ias' implementation
(check email archives)
On Fri, 30 Jul 2004 00:27:18 -0700 (PDT), Toshiyuki Kimura
<to...@apache.org> wrote:
> Hi Steve and folks,
>
> Thank you for the comments.
>
> I agree with you on most of the descriptions what you want to say.
> However, please let me explain the background of my thoughts.
>
> I think Axis is one of major JAX-RPC compliant runtime nowadays.
> Then, Axis also works fine with an awful lot of application servers.
> But, I guess that it might be getting difficult to keep the position
> somewhere after coming up J2EE 5.0 to grow popular (- ,if we don't
> take measures to follow-up these infrastructures.)
>
> In the pending spec, I'd like to focus on two things below;
>
> 1) EoD (Ease-Of-Development) of Web Services
> Users will be able to implement any types (POJOs or EJBs)
> of Web Services with a couple of meta-tags. Then, the tag
> also works as a deployment descriptor.
> => The current development on Axis is not so difficult, but
> I think we (Axis-dev team) should improve our features.
>
> 2) Web Service runtime becomes a mandatory package of J2EE
> The JAX-RPC runtime was an optional package before J2EE
> 1.4. But, Web Services runtimes are becoming to be tightly
> coupled with the J2EE containers, and then it will become
> prominent in the near future, in my opinion as JSR-224 EG
> member.
> => Thus, I said before, "In addition, the Geronimo will
> make it convenient to implement the above feature, it
> might be a hard work with the others such as the standing
> AP servers of the third parties though."
>
> In addition, I'd like to put my thoughts for the class loading
> matter. If an implement is a class for Web Service absolutely,
> the role of loading might be for JAX-RPC runtime like as Axis.
> But, in some of cases, these classes of endpoint might be used
> from other Java programs (i.e. NON-Web Service clients). Thus,
> these class should be loaded into the default loader of container
> except the '*.jws', at least.
>
> Thanks,
>
> Toshi <to...@apache.org>
>
> On Thu, 29 Jul 2004, Steve Loughran wrote:
>
> > Toshiyuki Kimura wrote:
> >> Hi Srinath and Dims,
> >>
> >> I've been hoping to implement this feature also. I think
> >> it's depending upon not Axis but application servers. This
> >> means, the loading of the implementations as web services
> >> is a role of the AP server that Axis is deployed. If the AP
> >> server is supporting a hot deploy feature, I think that we
> >> can implement it easy with the following architecture.
> >>
> >> .........*.........*.........*.........*.........*.........*
> >> <- Client side -> <----- Server side ----->
> >>
> >> +-------------+ +-------------+
> >> | GUI | | AP server |
> >> +-------------+ +-------------+
> >> | (invoke) ^
> >> V | (deploy)
> >> +-------------+ +--------------+
> >> | AdminClient |------->| AdminService |--> [server-config]
> >> +-------------+ +--------------+
> >>
> >> Step 1: A user set an endpoint implementation to the GUI
> >> Step 2: The client side of Axis generates a wsdd for the
> >> implementation semi-automatically (... Hopefully)
> >> Step 3: The client side of Axis deploys the web service with
> >> the existing mechanism
> >> Step 4: The server side of Axis registers the web service
> >> to the server-config.wsdd
> >> Step 5: The client side of Axis sends the class of web service
> >> via SwA (SOAP with Attachments)
> >> Step 6: The server side of Axis receives the class and put it
> >> on the specified directory for the hot deployment
> >>
> >> NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
> >> into one step.
> >> .........*.........*.........*.........*.........*.........*
> >>
> >> In addition, the Geronimo will make it convenient to implement
> >> the above feature, it might be a hard work with the others such
> >> as the standing AP servers of the third parties though.
> >>
> >
> > 1. I dont think the classes should be uploaded this way. Or to
> > put it differently, it is not really axis' role to get into
> > deployment, as it takes on a whole new set of problems, problems
> > which need full time engineers to fix.
> >
> > The tool I work on by day (http://smartfrog.org/) does this,
> > and the whole live update and security problems are very
> > challenging. What if one endpoint is serving up data of one
> > version, and you deploy a new endpoint with a new version?
> > You'd need separate classloaders, and that makes it very hard to
> > share stuff across endpoints, as suddenly the same class can come
> > from separate places. Equality logic, singletons and the like
> > all break.
> >
> > 2. Axis on smartfrog does do live deploy where you can get new
> > code in. But you have to put the new classes into a separate jar,
> > sign it then put it on a URL that is accessible by the service,
> > before sending a deploy request to the service. But it has a very
> > complex model of classloading that breaks bits of axis too (every
> > instance of a deployer component can have its own classpath,
> > which means that the context classloader doesnt cut it, as that
> > value doesn't change whenever you enter or exit an (RMI) method
> > call.
> >
> > 3. What we could do is add extra hooks in axis for classloading.
> > And if we serialize any of our own state to session objects we
> > could do it with objects that have serialversionUIDs so that they
> > are compatible across builds. No, that wont work if we just add
> > object instances to the context. We'd need to actually serialize/
> > deserialize stuff to be robust against classloader changes.
> >
> > -Steve
> >
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
> The hot deployment feature with jws will be coming up in the near
> future regardless of whether you appreciate the worth of JWS as good
> or bad. I think that the related spec has already been starting the
> discussion to decide which way to steer on JCP works.
I have not use jws much and not much fit to commented. To me it is open
issue. :)
> In my current understanding, I'd like to try to write a map for the
> Axis related projects onto a few JSRs;
>
> a) Axis implementation -> JSR-101 / [JSR-181 / JSR-224]
> b) Axis-ews implementation -> JSR-109(EWS 1.0)
> c) Axis-geronimo implementation -> [EWS 1.1] / JSR-220 / JSR-224
> d) Apache Beehive -> JSR-181?
>
> The above is not in Axis-dev side point of view, but in JCP-side
> one. Or rather, the key is where (the core of) Axis wants to go for
> in the future.
let me try fill the map and get back you
(at least JAXB/JAXME come there)
Thanks
Srinath
Re: Hot WS Deployment In Axis
Posted by Toshiyuki Kimura <to...@apache.org>.
Hi Srinath,
The hot deployment feature with jws will be coming up in the near
future regardless of whether you appreciate the worth of JWS as good
or bad. I think that the related spec has already been starting the
discussion to decide which way to steer on JCP works.
In my current understanding, I'd like to try to write a map for the
Axis related projects onto a few JSRs;
a) Axis implementation -> JSR-101 / [JSR-181 / JSR-224]
b) Axis-ews implementation -> JSR-109(EWS 1.0)
c) Axis-geronimo implementation -> [EWS 1.1] / JSR-220 / JSR-224
d) Apache Beehive -> JSR-181?
The above is not in Axis-dev side point of view, but in JCP-side
one. Or rather, the key is where (the core of) Axis wants to go for
in the future.
Thanks,
Toshi
-----Original Message-----
From: Srinath Perera [mailto:hemapani@opensource.lk]
Sent: Thursday, August 05, 2004 10:50 PM
To: axis-dev@ws.apache.org
Subject: Re: Hot WS Deployment In Axis
Hi Toshi;
Sorry for the late reply ..
My first reaction was the jws is not for serious things.
yap it is a good hot deployment:) .. But I think it is limited.
if it is we have to give the jws full feature. Does the work worth
what we get(is OPEN)?.
Any way it is a intersting option :)
Thanks
Srinath
> Srinath,
>
> I think you might have three points of view as follows on
> the class loading matter;
>
> a) Axis (basic engine of) implementation
> b) Axis-ews implementation
> c) Axis-geronimo implementation
>
> Then, it becomes larger and larger in the order as a) to c)
> that the governance area of class loadings. The a) is for the
> POJO-based implementations of Web Services, and the b) is for
> the EJB-based implementations. Then the c) has to work as a
> J2EE container as like as J2EE 1.4(or the later) implementation
> what supports both (POJOs, EJBs and jws) types of Web Services.
>
> By the way, I said before;
> <snip>
> If an implement is a class for Web Service absolutely, the
> role of loading might be for JAX-RPC runtime like as Axis.
> But, in some of cases, these classes of endpoint might be
> used from other Java programs (i.e. NON-Web Service clients).
> Thus, these class should be loaded into the default loader of
> container except the '*.jws', at least.
> </snip>
>
> If you're talking on the role of a) only, I'd like to point
> out a new direction for the class loading. In the above snip,
> you might be able to find out a solution;
>
> - The impl must be a Web Service, if the extension is 'jws'
> - The class should not be called from NON-Web Service clients
> - Axis can be a (main part of) loader for the class
> - Now, Axis has been doing this for 'jws'
>
> I believe the POJO-based JAX-RPC implementation is easy to
> convert into a 'jws' component. But, it's not that I want to
> say all of POJO-based components should be 'jws' or we should
> automatically convert a POJO into 'jws', at this time.
>
> I just wanted to point out one of easy approach. That is,
> Axis users might be able to have a hot deployment feature
> easier, if they use 'jws'. Even if it's not a perfect solution.
>
> Thanks,
>
> Toshi <to...@apache.org>
>
>
> On Sat, 31 Jul 2004, Srinath Perera wrote:
>
>>
>>>> 2) If the remote deployment is needed we can front this code to
>>>> something
>>>> to find and copy the module to the hot deployment lib.
>>>
>>> Exactly. If you look at a lot of the job submission stuff in the grid
>>> world, the front ends fetch your content using umpteen various
>>> protocols
>>> and then stick them in your filesystem, before handing the stuff off
to
>>> the next stage (the next stage being what I am involved in).
>>>
>>> A design like this can be used with a front end attachment based
>>> protocol if needed, but it doesnt have to be.
>> yap :)
>>
>>> Some thoughts
>>>
>>> 1. what if a module is already loaded in a different classloader?
>>> Reload?
>>>
>>> 2. what if a module is already loaded in a parent classloader? What if
>>> we are hosted under JBoss with its own funny logic?
>>>
>>> 3. what if two services want to dynamically load in a jar file -and
>>> want to share a classloader , so that they can share instances of the
>>> classes.
>>>
>>> #3 is why ant's taskdef lets you identify a classloader by name; all
>>> tasks loaded with the same name share the classloader. Costin (of
>>> tomcat
>>> fame) helped out on there. We really need consultation with him or
>>> another classloader expert before getting too far into trouble.
>>>
>>> -stee
>>> One option is to make classloaders
>> yes .. it is tough let me try to find answers. I am not sure that I can
>> :)
>>
>> 1,2 this works only if we load the webservices only in this way. It is
>> not
>> much nice to ask people to make the jar's and make this is the only
>> class
>> loading mechanisum.
>>
>> and for #3 yes if we need that support it will make a mess :(
>>
>> Thanks
>> Srinath
>>
>> ------------------------------------
>> Lanka Sofware Foundation
>> ------------------------------------
>>
>
>
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
Hi Toshi;
Sorry for the late reply ..
My first reaction was the jws is not for serious things.
yap it is a good hot deployment:) .. But I think it is limited.
if it is we have to give the jws full feature. Does the work worth what we
get(is OPEN)?.
Any way it is a intersting option :)
Thanks
Srinath
> Srinath,
>
> I think you might have three points of view as follows on
> the class loading matter;
>
> a) Axis (basic engine of) implementation
> b) Axis-ews implementation
> c) Axis-geronimo implementation
>
> Then, it becomes larger and larger in the order as a) to c)
> that the governance area of class loadings. The a) is for the
> POJO-based implementations of Web Services, and the b) is for
> the EJB-based implementations. Then the c) has to work as a
> J2EE container as like as J2EE 1.4(or the later) implementation
> what supports both (POJOs, EJBs and jws) types of Web Services.
>
> By the way, I said before;
> <snip>
> If an implement is a class for Web Service absolutely, the
> role of loading might be for JAX-RPC runtime like as Axis.
> But, in some of cases, these classes of endpoint might be
> used from other Java programs (i.e. NON-Web Service clients).
> Thus, these class should be loaded into the default loader of
> container except the '*.jws', at least.
> </snip>
>
> If you're talking on the role of a) only, I'd like to point
> out a new direction for the class loading. In the above snip,
> you might be able to find out a solution;
>
> - The impl must be a Web Service, if the extension is 'jws'
> - The class should not be called from NON-Web Service clients
> - Axis can be a (main part of) loader for the class
> - Now, Axis has been doing this for 'jws'
>
> I believe the POJO-based JAX-RPC implementation is easy to
> convert into a 'jws' component. But, it's not that I want to
> say all of POJO-based components should be 'jws' or we should
> automatically convert a POJO into 'jws', at this time.
>
> I just wanted to point out one of easy approach. That is,
> Axis users might be able to have a hot deployment feature
> easier, if they use 'jws'. Even if it's not a perfect solution.
>
> Thanks,
>
> Toshi <to...@apache.org>
>
>
> On Sat, 31 Jul 2004, Srinath Perera wrote:
>
>>
>>>> 2) If the remote deployment is needed we can front this code to
>>>> something
>>>> to find and copy the module to the hot deployment lib.
>>>
>>> Exactly. If you look at a lot of the job submission stuff in the grid
>>> world, the front ends fetch your content using umpteen various
>>> protocols
>>> and then stick them in your filesystem, before handing the stuff off to
>>> the next stage (the next stage being what I am involved in).
>>>
>>> A design like this can be used with a front end attachment based
>>> protocol if needed, but it doesnt have to be.
>> yap :)
>>
>>> Some thoughts
>>>
>>> 1. what if a module is already loaded in a different classloader?
>>> Reload?
>>>
>>> 2. what if a module is already loaded in a parent classloader? What if
>>> we are hosted under JBoss with its own funny logic?
>>>
>>> 3. what if two services want to dynamically load in a jar file -and
>>> want to share a classloader , so that they can share instances of the
>>> classes.
>>>
>>> #3 is why ant's taskdef lets you identify a classloader by name; all
>>> tasks loaded with the same name share the classloader. Costin (of
>>> tomcat
>>> fame) helped out on there. We really need consultation with him or
>>> another classloader expert before getting too far into trouble.
>>>
>>> -stee
>>> One option is to make classloaders
>> yes .. it is tough let me try to find answers. I am not sure that I can
>> :)
>>
>> 1,2 this works only if we load the webservices only in this way. It is
>> not
>> much nice to ask people to make the jar's and make this is the only
>> class
>> loading mechanisum.
>>
>> and for #3 yes if we need that support it will make a mess :(
>>
>> Thanks
>> Srinath
>>
>> ------------------------------------
>> Lanka Sofware Foundation
>> ------------------------------------
>>
>
>
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Toshiyuki Kimura <to...@apache.org>.
Srinath,
I think you might have three points of view as follows on
the class loading matter;
a) Axis (basic engine of) implementation
b) Axis-ews implementation
c) Axis-geronimo implementation
Then, it becomes larger and larger in the order as a) to c)
that the governance area of class loadings. The a) is for the
POJO-based implementations of Web Services, and the b) is for
the EJB-based implementations. Then the c) has to work as a
J2EE container as like as J2EE 1.4(or the later) implementation
what supports both (POJOs, EJBs and jws) types of Web Services.
By the way, I said before;
<snip>
If an implement is a class for Web Service absolutely, the
role of loading might be for JAX-RPC runtime like as Axis.
But, in some of cases, these classes of endpoint might be
used from other Java programs (i.e. NON-Web Service clients).
Thus, these class should be loaded into the default loader of
container except the '*.jws', at least.
</snip>
If you're talking on the role of a) only, I'd like to point
out a new direction for the class loading. In the above snip,
you might be able to find out a solution;
- The impl must be a Web Service, if the extension is 'jws'
- The class should not be called from NON-Web Service clients
- Axis can be a (main part of) loader for the class
- Now, Axis has been doing this for 'jws'
I believe the POJO-based JAX-RPC implementation is easy to
convert into a 'jws' component. But, it's not that I want to
say all of POJO-based components should be 'jws' or we should
automatically convert a POJO into 'jws', at this time.
I just wanted to point out one of easy approach. That is,
Axis users might be able to have a hot deployment feature
easier, if they use 'jws'. Even if it's not a perfect solution.
Thanks,
Toshi <to...@apache.org>
On Sat, 31 Jul 2004, Srinath Perera wrote:
>
>>> 2) If the remote deployment is needed we can front this code to
>>> something
>>> to find and copy the module to the hot deployment lib.
>>
>> Exactly. If you look at a lot of the job submission stuff in the grid
>> world, the front ends fetch your content using umpteen various protocols
>> and then stick them in your filesystem, before handing the stuff off to
>> the next stage (the next stage being what I am involved in).
>>
>> A design like this can be used with a front end attachment based
>> protocol if needed, but it doesnt have to be.
> yap :)
>
>> Some thoughts
>>
>> 1. what if a module is already loaded in a different classloader? Reload?
>>
>> 2. what if a module is already loaded in a parent classloader? What if
>> we are hosted under JBoss with its own funny logic?
>>
>> 3. what if two services want to dynamically load in a jar file -and
>> want to share a classloader , so that they can share instances of the
>> classes.
>>
>> #3 is why ant's taskdef lets you identify a classloader by name; all
>> tasks loaded with the same name share the classloader. Costin (of tomcat
>> fame) helped out on there. We really need consultation with him or
>> another classloader expert before getting too far into trouble.
>>
>> -stee
>> One option is to make classloaders
> yes .. it is tough let me try to find answers. I am not sure that I can :)
>
> 1,2 this works only if we load the webservices only in this way. It is not
> much nice to ask people to make the jar's and make this is the only class
> loading mechanisum.
>
> and for #3 yes if we need that support it will make a mess :(
>
> Thanks
> Srinath
>
> ------------------------------------
> Lanka Sofware Foundation
> ------------------------------------
>
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
>> 2) If the remote deployment is needed we can front this code to
>> something
>> to find and copy the module to the hot deployment lib.
>
> Exactly. If you look at a lot of the job submission stuff in the grid
> world, the front ends fetch your content using umpteen various protocols
> and then stick them in your filesystem, before handing the stuff off to
> the next stage (the next stage being what I am involved in).
>
> A design like this can be used with a front end attachment based
> protocol if needed, but it doesnt have to be.
yap :)
> Some thoughts
>
> 1. what if a module is already loaded in a different classloader? Reload?
>
> 2. what if a module is already loaded in a parent classloader? What if
> we are hosted under JBoss with its own funny logic?
>
> 3. what if two services want to dynamically load in a jar file -and
> want to share a classloader , so that they can share instances of the
> classes.
>
> #3 is why ant's taskdef lets you identify a classloader by name; all
> tasks loaded with the same name share the classloader. Costin (of tomcat
> fame) helped out on there. We really need consultation with him or
> another classloader expert before getting too far into trouble.
>
> -stee
> One option is to make classloaders
yes .. it is tough let me try to find answers. I am not sure that I can :)
1,2 this works only if we load the webservices only in this way. It is not
much nice to ask people to make the jar's and make this is the only class
loading mechanisum.
and for #3 yes if we need that support it will make a mess :(
Thanks
Srinath
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
I just realize something ... if we need that the WS to accsess another WS
it can agien be given by a option in wsdd. But this is just like j2ee
classloding. (I get a feeling if we are to suport all the cases we have to
use the same methods used in J2EE).
As pointed out at the start then it may be lot of pain we donot want to
put inside the axis :( .. but if people likes to live with one or two
limitations that is a differant story :)
Thanks
Srinath
> Samuel Meder wrote:
>> ----- Original Message -----
>> From: "Steve Loughran" <st...@apache.org>
>> To: <ax...@ws.apache.org>
>> Sent: Saturday, July 31, 2004 12:29 AM
>> Subject: Re: Hot WS Deployment In Axis
>>
>>
>> [...]
>>
>>>Some thoughts
>>>
>>>1. what if a module is already loaded in a different classloader?
>>> Reload?
>>
>>
>> Do you mean reload as in set up a duplicate? I think there need to be
>> separate operations for update vs load a different version.
>>
>>
>>>2. what if a module is already loaded in a parent classloader? What if
>>>we are hosted under JBoss with its own funny logic?
>>
>>
>> Fault.
>
> I think of that whenever I have to try and bash axis-on-jboss into
> shape. Indeed, we could change happyaxis.jsp to warn about the special
> joys there.
>
>>
>>
>>>3. what if two services want to dynamically load in a jar file -and
>>>want to share a classloader , so that they can share instances of the
>>>classes.
>>
>>
>> Yea, this may be tricky. In our environment we end up doing this quite a
>> bit between a factory service and a service acting on the objects
>> created by the factory. Granted we could potentially work around this by
>> pushing things into the parent loader, but that doesn't seem all that
>> clean.
>
> aah, you are doing Gt4.x, arent you? with the factory stuff. Even
> without that, it is a common case that multiple endpoints are related,
> share content and generally like to be friends. The current model "we
> are all equal in the webapp classloader" works, but does not seem
> flexible enough for everyone's needs.
>
> -Steve
>
>
>
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Steve Loughran <st...@apache.org>.
Samuel Meder wrote:
> ----- Original Message -----
> From: "Steve Loughran" <st...@apache.org>
> To: <ax...@ws.apache.org>
> Sent: Saturday, July 31, 2004 12:29 AM
> Subject: Re: Hot WS Deployment In Axis
>
>
> [...]
>
>>Some thoughts
>>
>>1. what if a module is already loaded in a different classloader? Reload?
>
>
> Do you mean reload as in set up a duplicate? I think there need to be separate operations for update vs load a different version.
>
>
>>2. what if a module is already loaded in a parent classloader? What if
>>we are hosted under JBoss with its own funny logic?
>
>
> Fault.
I think of that whenever I have to try and bash axis-on-jboss into
shape. Indeed, we could change happyaxis.jsp to warn about the special
joys there.
>
>
>>3. what if two services want to dynamically load in a jar file -and
>>want to share a classloader , so that they can share instances of the
>>classes.
>
>
> Yea, this may be tricky. In our environment we end up doing this quite a bit between a factory service and a service acting on the objects created by the factory. Granted we could potentially work around this by pushing things into the parent loader, but that doesn't seem all that clean.
aah, you are doing Gt4.x, arent you? with the factory stuff. Even
without that, it is a common case that multiple endpoints are related,
share content and generally like to be friends. The current model "we
are all equal in the webapp classloader" works, but does not seem
flexible enough for everyone's needs.
-Steve
Re: Hot WS Deployment In Axis
Posted by Samuel Meder <me...@mcs.anl.gov>.
----- Original Message -----
From: "Steve Loughran" <st...@apache.org>
To: <ax...@ws.apache.org>
Sent: Saturday, July 31, 2004 12:29 AM
Subject: Re: Hot WS Deployment In Axis
[...]
>
> Some thoughts
>
> 1. what if a module is already loaded in a different classloader? Reload?
Do you mean reload as in set up a duplicate? I think there need to be separate operations for update vs load a different version.
> 2. what if a module is already loaded in a parent classloader? What if
> we are hosted under JBoss with its own funny logic?
Fault.
> 3. what if two services want to dynamically load in a jar file -and
> want to share a classloader , so that they can share instances of the
> classes.
Yea, this may be tricky. In our environment we end up doing this quite a bit between a factory service and a service acting on the objects created by the factory. Granted we could potentially work around this by pushing things into the parent loader, but that doesn't seem all that clean.
/Sam
> #3 is why ant's taskdef lets you identify a classloader by name; all
> tasks loaded with the same name share the classloader. Costin (of tomcat
> fame) helped out on there. We really need consultation with him or
> another classloader expert before getting too far into trouble.
>
> -stee
> One option is to make classloaders
>
> > 3) will the fact that the service is loaded from diff class loader (we can
> > set the context loader as the parent) will mess up execution somehow. I
> > belive not .. But I need to check.
>
>
>
Re: Hot WS Deployment In Axis
Posted by Steve Loughran <st...@apache.org>.
I guess it depends on what role axis has. If you view Axis as a core
part of the app server it is different to a webapp you redeploy in the
app server. And, with JWS pages, we sort of have a live update mechanism
in there.
Srinath Perera wrote:
> Thanks Dims .. I get the dynamic class loading done for axis-geronimo
> using ClassUtils. (will send a patch first thing next week).
> Steve and Toshi;
> I have few thoughts for the hot deployment process .. I am not sure how
> easy or hard to implement this on the Axis. Any comments are welcome.
>
> 1) We need the Hot Deployment, But do we need remote hot deployment?
> 2) If we do I prefer what steve said rather that using SwA what do you think
>
> what if we define a hot deployment dir (as Toshi plans) and specify the
> name of the module in the server-config.wsdd file as a parameter. The user
> who need hot deployment should create the jar having the class files and
> specify the name of the module in server-config.wsdd file.
> <service name="echo" ..>
> .....
> <parameter name="module" value="echo.jar"/>
> </service>
> Then at loading the service Axis will search the hot deployment
> dir for the module as given in the wever-config.wsdd file then create a
> clessloader and load the class
>
> 1) This make sure the loaded class is the one the deployer intended. (not
> from some other jar.)
> 2) If the remote deployment is needed we can front this code to something
> to find and copy the module to the hot deployment lib.
Exactly. If you look at a lot of the job submission stuff in the grid
world, the front ends fetch your content using umpteen various protocols
and then stick them in your filesystem, before handing the stuff off to
the next stage (the next stage being what I am involved in).
A design like this can be used with a front end attachment based
protocol if needed, but it doesnt have to be.
Some thoughts
1. what if a module is already loaded in a different classloader? Reload?
2. what if a module is already loaded in a parent classloader? What if
we are hosted under JBoss with its own funny logic?
3. what if two services want to dynamically load in a jar file -and
want to share a classloader , so that they can share instances of the
classes.
#3 is why ant's taskdef lets you identify a classloader by name; all
tasks loaded with the same name share the classloader. Costin (of tomcat
fame) helped out on there. We really need consultation with him or
another classloader expert before getting too far into trouble.
-stee
One option is to make classloaders
> 3) will the fact that the service is loaded from diff class loader (we can
> set the context loader as the parent) will mess up execution somehow. I
> belive not .. But I need to check.
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
Thanks Dims .. I get the dynamic class loading done for axis-geronimo
using ClassUtils. (will send a patch first thing next week).
Steve and Toshi;
I have few thoughts for the hot deployment process .. I am not sure how
easy or hard to implement this on the Axis. Any comments are welcome.
1) We need the Hot Deployment, But do we need remote hot deployment?
2) If we do I prefer what steve said rather that using SwA what do you think
what if we define a hot deployment dir (as Toshi plans) and specify the
name of the module in the server-config.wsdd file as a parameter. The user
who need hot deployment should create the jar having the class files and
specify the name of the module in server-config.wsdd file.
<service name="echo" ..>
.....
<parameter name="module" value="echo.jar"/>
</service>
Then at loading the service Axis will search the hot deployment
dir for the module as given in the wever-config.wsdd file then create a
clessloader and load the class
1) This make sure the loaded class is the one the deployer intended. (not
from some other jar.)
2) If the remote deployment is needed we can front this code to something
to find and copy the module to the hot deployment lib.
3) will the fact that the service is loaded from diff class loader (we can
set the context loader as the parent) will mess up execution somehow. I
belive not .. But I need to check.
Thanks
Srinath
Re: Hot WS Deployment In Axis
Posted by Toshiyuki Kimura <to...@apache.org>.
Hi Steve and folks,
Thank you for the comments.
I agree with you on most of the descriptions what you want to say.
However, please let me explain the background of my thoughts.
I think Axis is one of major JAX-RPC compliant runtime nowadays.
Then, Axis also works fine with an awful lot of application servers.
But, I guess that it might be getting difficult to keep the position
somewhere after coming up J2EE 5.0 to grow popular (- ,if we don't
take measures to follow-up these infrastructures.)
In the pending spec, I'd like to focus on two things below;
1) EoD (Ease-Of-Development) of Web Services
Users will be able to implement any types (POJOs or EJBs)
of Web Services with a couple of meta-tags. Then, the tag
also works as a deployment descriptor.
=> The current development on Axis is not so difficult, but
I think we (Axis-dev team) should improve our features.
2) Web Service runtime becomes a mandatory package of J2EE
The JAX-RPC runtime was an optional package before J2EE
1.4. But, Web Services runtimes are becoming to be tightly
coupled with the J2EE containers, and then it will become
prominent in the near future, in my opinion as JSR-224 EG
member.
=> Thus, I said before, "In addition, the Geronimo will
make it convenient to implement the above feature, it
might be a hard work with the others such as the standing
AP servers of the third parties though."
In addition, I'd like to put my thoughts for the class loading
matter. If an implement is a class for Web Service absolutely,
the role of loading might be for JAX-RPC runtime like as Axis.
But, in some of cases, these classes of endpoint might be used
from other Java programs (i.e. NON-Web Service clients). Thus,
these class should be loaded into the default loader of container
except the '*.jws', at least.
Thanks,
Toshi <to...@apache.org>
On Thu, 29 Jul 2004, Steve Loughran wrote:
> Toshiyuki Kimura wrote:
>> Hi Srinath and Dims,
>>
>> I've been hoping to implement this feature also. I think
>> it's depending upon not Axis but application servers. This
>> means, the loading of the implementations as web services
>> is a role of the AP server that Axis is deployed. If the AP
>> server is supporting a hot deploy feature, I think that we
>> can implement it easy with the following architecture.
>>
>> .........*.........*.........*.........*.........*.........*
>> <- Client side -> <----- Server side ----->
>>
>> +-------------+ +-------------+
>> | GUI | | AP server |
>> +-------------+ +-------------+
>> | (invoke) ^
>> V | (deploy)
>> +-------------+ +--------------+
>> | AdminClient |------->| AdminService |--> [server-config]
>> +-------------+ +--------------+
>>
>> Step 1: A user set an endpoint implementation to the GUI
>> Step 2: The client side of Axis generates a wsdd for the
>> implementation semi-automatically (... Hopefully)
>> Step 3: The client side of Axis deploys the web service with
>> the existing mechanism
>> Step 4: The server side of Axis registers the web service
>> to the server-config.wsdd
>> Step 5: The client side of Axis sends the class of web service
>> via SwA (SOAP with Attachments)
>> Step 6: The server side of Axis receives the class and put it
>> on the specified directory for the hot deployment
>>
>> NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
>> into one step.
>> .........*.........*.........*.........*.........*.........*
>>
>> In addition, the Geronimo will make it convenient to implement
>> the above feature, it might be a hard work with the others such
>> as the standing AP servers of the third parties though.
>>
>
> 1. I dont think the classes should be uploaded this way. Or to
> put it differently, it is not really axis' role to get into
> deployment, as it takes on a whole new set of problems, problems
> which need full time engineers to fix.
>
> The tool I work on by day (http://smartfrog.org/) does this,
> and the whole live update and security problems are very
> challenging. What if one endpoint is serving up data of one
> version, and you deploy a new endpoint with a new version?
> You'd need separate classloaders, and that makes it very hard to
> share stuff across endpoints, as suddenly the same class can come
> from separate places. Equality logic, singletons and the like
> all break.
>
> 2. Axis on smartfrog does do live deploy where you can get new
> code in. But you have to put the new classes into a separate jar,
> sign it then put it on a URL that is accessible by the service,
> before sending a deploy request to the service. But it has a very
> complex model of classloading that breaks bits of axis too (every
> instance of a deployer component can have its own classpath,
> which means that the context classloader doesnt cut it, as that
> value doesn't change whenever you enter or exit an (RMI) method
> call.
>
> 3. What we could do is add extra hooks in axis for classloading.
> And if we serialize any of our own state to session objects we
> could do it with objects that have serialversionUIDs so that they
> are compatible across builds. No, that wont work if we just add
> object instances to the context. We'd need to actually serialize/
> deserialize stuff to be robust against classloader changes.
>
> -Steve
>
Re: Hot WS Deployment In Axis
Posted by Srinath Perera <he...@opensource.lk>.
Thanks Dims, Toshiyuki, Steve for thoughts
let me think way to do this with axis,ews and geronimo .. and I will be
back to verify my thoughts ..
thanks
Srinath
> Toshiyuki Kimura wrote:
>> Hi Srinath and Dims,
>>
>> I've been hoping to implement this feature also. I think
>> it's depending upon not Axis but application servers. This
>> means, the loading of the implementations as web services
>> is a role of the AP server that Axis is deployed. If the AP
>> server is supporting a hot deploy feature, I think that we
>> can implement it easy with the following architecture.
>>
>> .........*.........*.........*.........*.........*.........*
>> <- Client side -> <----- Server side ----->
>>
>> +-------------+ +-------------+
>> | GUI | | AP server |
>> +-------------+ +-------------+
>> | (invoke) ^
>> V | (deploy)
>> +-------------+ +--------------+
>> | AdminClient |------->| AdminService |--> [server-config]
>> +-------------+ +--------------+
>>
>> Step 1: A user set an endpoint implementation to the GUI
>> Step 2: The client side of Axis generates a wsdd for the
>> implementation semi-automatically (... Hopefully)
>> Step 3: The client side of Axis deploys the web service with
>> the existing mechanism
>> Step 4: The server side of Axis registers the web service
>> to the server-config.wsdd
>> Step 5: The client side of Axis sends the class of web service
>> via SwA (SOAP with Attachments)
>> Step 6: The server side of Axis receives the class and put it
>> on the specified directory for the hot deployment
>>
>> NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
>> into one step.
>> .........*.........*.........*.........*.........*.........*
>>
>> In addition, the Geronimo will make it convenient to implement
>> the above feature, it might be a hard work with the others such
>> as the standing AP servers of the third parties though.
>>
>
> 1. I dont think the classes should be uploaded this way. Or to put it
> differently, it is not really axis' role to get into deployment, as it
> takes on a whole new set of problems, problems which need full time
> engineers to fix.
>
> The tool I work on by day (http://smartfrog.org/) does this, and the
> whole live update and security problems are very challenging. What if
> one endpoint is serving up data of one version, and you deploy a new
> endpoint with a new version? You'd need separate classloaders, and that
> makes it very hard to share stuff across endpoints, as suddenly the same
> class can come from separate places. Equality logic, singletons and the
> like all break.
>
> 2. Axis on smartfrog does do live deploy where you can get new code in.
> But you have to put the new classes into a separate jar, sign it then
> put it on a URL that is accessible by the service, before sending a
> deploy request to the service. But it has a very complex model of
> classloading that breaks bits of axis too (every instance of a deployer
> component can have its own classpath, which means that the context
> classloader doesnt cut it, as that value doesn't change whenever you
> enter or exit an (RMI) method call.
>
> 3. What we could do is add extra hooks in axis for classloading. And if
> we serialize any of our own state to session objects we could do it
> with objects that have serialversionUIDs so that they are compatible
> across builds. No, that wont work if we just add object instances to the
> context. We'd need to actually serialize/deserialize stuff to be robust
> against classloader changes.
>
> -Steve
>
>
>
>
------------------------------------
Lanka Sofware Foundation
------------------------------------
Re: Hot WS Deployment In Axis
Posted by Steve Loughran <st...@apache.org>.
Toshiyuki Kimura wrote:
> Hi Srinath and Dims,
>
> I've been hoping to implement this feature also. I think
> it's depending upon not Axis but application servers. This
> means, the loading of the implementations as web services
> is a role of the AP server that Axis is deployed. If the AP
> server is supporting a hot deploy feature, I think that we
> can implement it easy with the following architecture.
>
> .........*.........*.........*.........*.........*.........*
> <- Client side -> <----- Server side ----->
>
> +-------------+ +-------------+
> | GUI | | AP server |
> +-------------+ +-------------+
> | (invoke) ^
> V | (deploy)
> +-------------+ +--------------+
> | AdminClient |------->| AdminService |--> [server-config]
> +-------------+ +--------------+
>
> Step 1: A user set an endpoint implementation to the GUI
> Step 2: The client side of Axis generates a wsdd for the
> implementation semi-automatically (... Hopefully)
> Step 3: The client side of Axis deploys the web service with
> the existing mechanism
> Step 4: The server side of Axis registers the web service
> to the server-config.wsdd
> Step 5: The client side of Axis sends the class of web service
> via SwA (SOAP with Attachments)
> Step 6: The server side of Axis receives the class and put it
> on the specified directory for the hot deployment
>
> NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
> into one step.
> .........*.........*.........*.........*.........*.........*
>
> In addition, the Geronimo will make it convenient to implement
> the above feature, it might be a hard work with the others such
> as the standing AP servers of the third parties though.
>
1. I dont think the classes should be uploaded this way. Or to put it
differently, it is not really axis' role to get into deployment, as it
takes on a whole new set of problems, problems which need full time
engineers to fix.
The tool I work on by day (http://smartfrog.org/) does this, and the
whole live update and security problems are very challenging. What if
one endpoint is serving up data of one version, and you deploy a new
endpoint with a new version? You'd need separate classloaders, and that
makes it very hard to share stuff across endpoints, as suddenly the same
class can come from separate places. Equality logic, singletons and the
like all break.
2. Axis on smartfrog does do live deploy where you can get new code in.
But you have to put the new classes into a separate jar, sign it then
put it on a URL that is accessible by the service, before sending a
deploy request to the service. But it has a very complex model of
classloading that breaks bits of axis too (every instance of a deployer
component can have its own classpath, which means that the context
classloader doesnt cut it, as that value doesn't change whenever you
enter or exit an (RMI) method call.
3. What we could do is add extra hooks in axis for classloading. And if
we serialize any of our own state to session objects we could do it
with objects that have serialversionUIDs so that they are compatible
across builds. No, that wont work if we just add object instances to the
context. We'd need to actually serialize/deserialize stuff to be robust
against classloader changes.
-Steve
Re: Hot WS Deployment In Axis
Posted by Toshiyuki Kimura <to...@apache.org>.
Hi Srinath and Dims,
I've been hoping to implement this feature also. I think
it's depending upon not Axis but application servers. This
means, the loading of the implementations as web services
is a role of the AP server that Axis is deployed. If the AP
server is supporting a hot deploy feature, I think that we
can implement it easy with the following architecture.
.........*.........*.........*.........*.........*.........*
<- Client side -> <----- Server side ----->
+-------------+ +-------------+
| GUI | | AP server |
+-------------+ +-------------+
| (invoke) ^
V | (deploy)
+-------------+ +--------------+
| AdminClient |------->| AdminService |--> [server-config]
+-------------+ +--------------+
Step 1: A user set an endpoint implementation to the GUI
Step 2: The client side of Axis generates a wsdd for the
implementation semi-automatically (... Hopefully)
Step 3: The client side of Axis deploys the web service with
the existing mechanism
Step 4: The server side of Axis registers the web service
to the server-config.wsdd
Step 5: The client side of Axis sends the class of web service
via SwA (SOAP with Attachments)
Step 6: The server side of Axis receives the class and put it
on the specified directory for the hot deployment
NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
into one step.
.........*.........*.........*.........*.........*.........*
In addition, the Geronimo will make it convenient to implement
the above feature, it might be a hard work with the others such
as the standing AP servers of the third parties though.
Hope it helps you and I'd like to go along with you.
Regards,
Toshi
-----Original Message-----
From: Davanum Srinivas [mailto:davanum@gmail.com]
Sent: Thursday, July 29, 2004 12:09 PM
To: axis-dev@ws.apache.org; hemapani@opensource.lk
Subject: Re: Hot WS Deployment In Axis
Srinath,
Right now Axis defers to the context class loader and relies
on the servlet engine's hot-deploy capabilities. There are
hooks to plugin a custom class loader )See ClassUtils.java.)
We can tweak that code if required.
thanks,
dims
On Wed, 28 Jul 2004 22:29:01 -0400 (EDT), Srinath Perera
<he...@opensource.lk> wrote:
> To which extent the Axis supports the Hot deployment of
> the web services ?
> 1) We can use the admin client to add the entry to the
> server-config.wsdd
> 2) But how about loading the class files .. To my experinace
> so far we need the class files present at the classapth when
> axis started.
>
> For the Geronimo Integration I think we need that hot
> deployment feature.
> If it is not there I would try to .. like to hear any comments
> plus the pointers to what is the best way to implement it.
>
> Thanks
> Srinath
>
> ------------------------------------
> Lanka Sofware Foundation
> ------------------------------------
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Hot WS Deployment In Axis
Posted by Davanum Srinivas <da...@gmail.com>.
Srinath,
Right now Axis defers to the context class loader and relies on the
servlet engine's hot-deploy capabilities. There are hooks to plugin a
custom class loader )See ClassUtils.java.) We can tweak that code if
required.
thanks,
dims
On Wed, 28 Jul 2004 22:29:01 -0400 (EDT), Srinath Perera
<he...@opensource.lk> wrote:
> To which extent the Axis supports the Hot deployment of the web services ?
> 1) We can use the admin client to add the entry to the server-config.wsdd
> 2) But how about loading the class files .. To my experinace so far we
> need the class files present at the classapth when axis started.
>
> For the Geronimo Integration I think we need that hot deployment feature.
> If it is not there I would try to .. like to hear any comments plus the
> pointers to what is the best way to implement it.
>
> Thanks
> Srinath
>
> ------------------------------------
> Lanka Sofware Foundation
> ------------------------------------
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/