Doug, Please log it as an enchancement request. Let's see what we can do.
thanks, dims On 2/15/07, Doug Davis <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] "Manoj Khangaonkar" <[EMAIL PROTECTED]> 02/15/2007 02:43 PM Please respond to [email protected] To [email protected] 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 <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] "David Illsley" <[EMAIL PROTECTED]> 02/15/2007 03:49 AM Please respond to [email protected] To [email protected], [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
