axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toshiyuki Kimura <>
Subject Re: Hot WS Deployment In Axis
Date Sun, 01 Aug 2004 06:31:27 GMT

   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;
  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.

   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.


Toshi <>

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
> ------------------------------------

View raw message