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 Doug Davis <du...@us.ibm.com> on 2007/02/14 23:06:12 UTC

accessing methods in a module

If I have a module that exposes some static utility methods - what is the 
way axis2 developers are supposed to model that?
For example, let's say a popular module like WS-Addressing were to expose 
some utility method to convert a chunk of XML into an EPR.  Clearly logic 
that falls within the WS-Addressing module's domain but useful for more 
than just the module itself.  Applications (on the client and/or server) 
may need this kind of utility for their own purposes.  From my 
understanding, the module classloading logic in axis2 is such that if I 
wanted to expose these static methods I would need to duplicate the 
appropriate jar files.  In other words, I need to copy the jars from the 
.mar file out into the normal classloader path - e.g. WEB-INF/lib.  If 
correct, this seems less then friendly since from the application's point 
of view, once the module is engaged they may wonder why those classes are 
not available to be used - and this would mean that module developers 
would need to package their code in such a way that jars could easily be 
extracted for reuse outside of the module w/o duplicating all jars (and 
they would need to communicate which jars need to be copied in their 
docs). 

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com

Re: accessing methods in a module

Posted by Davanum Srinivas <da...@gmail.com>.

Doug,

Please log it as an enchancement request. Let's see what we can do.

thanks,
dims

On 2/15/07, Doug Davis <du...@us.ibm.com> wrote:
>
>   It could be but for some reason it feels different.  I have this image in my head that when I create a *.mar file its a self contained unit of functionality and people can move it around as needed.  Not unlike a *.jar file.  Its a collection of pieces needed for a particular piece of functionality. In this case the functionality is for 'axis' and the scope under which it works is 'axis'.  Now, I agree that perhaps the classes in a *.mar need to be scoped in some way - for example, perhaps not all modules are engaged for a particular invocation of a service, so in those situations I can understand why the classes in that module would be hidden.  However, in cases where the module is engaged shouldn't the classes within that module be visible?  IMO, the turning on of a module is akin to adding a jar file to your classpath. But I could be thinking about modules incorrectly.
>   I agree that I could create a shared utility jar but then if feels like I lose some of the benefits of having a *.mar in the first place. Having a single package that I can drop into my axis environment w/o having to also carry around secondary set of jar files to work around classloader issues just feels less than optimal - from a usability perspective.
>
>  thanks
>  -Doug
>  ______________________________________________________
>  STSM  |  Web Services Architect  |  IBM Software Group
>  (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com
>
>
>
>  "Manoj Khangaonkar" <kh...@gmail.com>
>
> 02/15/2007 02:43 PM
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
>
> cc
>
>
> Subject Re: accessing methods in a module
>
>
>
>
>
>
>
>
> Doug,
>
> Is this problem any different from any other code re-use problem with says EJB jars or WEB wars , Service aars ?
>
> In most of these cases - an "application" classloader with load the classes in the jar/war. So classes
> in 1 jar/war are not visible to others.
>
> Any utility classes that need to be shared - are first packaged as utility jars. But the utility jar needs to
> be copied and packaged with each EJB jar/WEB war that needs to use the utility classes.
>
> Mj
>
>
>
>
> On 2/15/07, Doug Davis <du...@us.ibm.com> wrote:
>
>  I suspect that moving all utils (from all modules) into the kernel isn't an option  :-)
>
>  thanks
>  -Doug
>  ______________________________________________________
>  STSM  |  Web Services Architect  |  IBM Software Group
>  (919) 254-6905  |  IBM T/L 444-6905  |   dug@us.ibm.com
>
>
>  "David Illsley" <da...@gmail.com>
>
> 02/15/2007 03:49 AM
>
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
>
>
> To axis-dev@ws.apache.org, dims@apache.org
>
> cc
>
>
> Subject Re: accessing methods in a module
>
>
>
>
>
>
>
>
>
>
>
>  Hi Doug,
>  The example you picked actually happened... did you know that? The
>  toOM/fromOM for EndpointReference are now in the kernel module so they
>  are available to everyone. The reason I did't push for services to be
>  able to access classes in mars is because it would still be a
>  development time headache to persuade my favoured IDE to look inside a
>  jar in a mar.
>
>  David
>
>  On 14/02/07, Davanum Srinivas <da...@gmail.com> wrote:
>  > Doug,
>  >
>  > Come to think of it. i think If you place the mar file in WEB-INF/lib.
>  > The module is loaded and the code in there is available to services.
>  > Need to test it of course...
>  >
>  > -- dims
>  >
>  > On 2/14/07, Doug Davis < dug@us.ibm.com> wrote:
>  > >
>  > > If I have a module that exposes some static utility methods - what is the
>  > > way axis2 developers are supposed to model that?
>  > > For example, let's say a popular module like WS-Addressing were to expose
>  > > some utility method to convert a chunk of XML into an EPR.  Clearly logic
>  > > that falls within the WS-Addressing module's domain but useful for more than
>  > > just the module itself.  Applications (on the client and/or server) may need
>  > > this kind of utility for their own purposes.  From my understanding, the
>  > > module classloading logic in axis2 is such that if I wanted to expose these
>  > > static methods I would need to duplicate the appropriate jar files.  In
>  > > other words, I need to copy the jars from the .mar file out into the normal
>  > > classloader path - e.g. WEB-INF/lib.  If correct, this seems less then
>  > > friendly since from the application's point of view, once the module is
>  > > engaged they may wonder why those classes are not available to be used - and
>  > > this would mean that module developers would need to package their code in
>  > > such a way that jars could easily be extracted for reuse outside of the
>  > > module w/o duplicating all jars (and they would need to communicate which
>  > > jars need to be copied in their docs).
>  > >
>  > >  thanks
>  > >  -Doug
>  > >  ______________________________________________________
>  > >  STSM  |  Web Services Architect  |  IBM Software Group
>  > >  (919) 254-6905  |  IBM T/L 444-6905  |   dug@us.ibm.com
>  >
>  >
>  > --
>  > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>  > For additional commands, e-mail: axis-dev-help@ws.apache.org
>  >
>  >
>
>
>  --
>  David Illsley - IBM Web Services Development
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>  For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>



-- 
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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