axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathy Chan (JIRA)" <>
Subject [jira] Commented: (AXIS-2146) Different class loading used in attachment type mapping causing NoClassDefFoundError
Date Thu, 26 Jan 2006 16:50:10 GMT
    [ ] 

Kathy Chan commented on AXIS-2146:

The problem can be solved by using the same classloader for both JavaUtils.isAttachmenSupported()
and the attachment code.  I thought it might be safer to change the JavaUtils.isAttachmentSupported()
to not use ClassUtils.forName() rather than switching the attachment code to use ClassUtils
(there will also be more places that had to be changed).  If the Axis development team goes
the route of changing attachment code to use ClassUtils.forName(may be because of "other problems
in class loading for various configurations such as App servers and the like"), then you might
also have to revisit possibly setting the AntClassLoader in Java2WSDLAntTask from:

AntClassLoader cl = new AntClassLoader(getClass().getClassLoader(),
                classpath == null ? createClasspath() : classpath,


AntClassLoader cl = new AntClassLoader(getClass().getClassLoader(),
                classpath == null ? createClasspath() : classpath,

I think switching parentFirst to true might be necessary so that the loading behaviour is
not changed too much by what's set through the classpath variable (in case the user is passing
in different versions of JARs in the classpath).

So, depending on what specific problem of not using ClassUtils.forName() will have on JavaUtils.isAttachmentSupport(),
I think using the normal classloader in JavaUtils.isAttachmentSupport() would be safer than
changing the loader behaviour in the attachment code.  Also, it seems to make more sense to
determine if attachment is supported by using what Axis could load from the lib directory
(i.e. the normal class loader) rather than what the user passes in the classpath variable
(the ClassUtils loader).

Another point to note is this problem started to show up once we moved from Axis 1.1 to 1.2.1.
 This problem was not there in Axis 1.0 or Axis 1.1.  So it might help to dig through the
change history to see which piece of the class loader behaviour got changed in Axis 1.2.1
and switch that back as part of this fix.

> Different class loading used in attachment type mapping causing NoClassDefFoundError
> ------------------------------------------------------------------------------------
>          Key: AXIS-2146
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2.1
>  Environment: Windows 2000
>     Reporter: Kathy Chan

> Driver:  Axis 1.2.1
> The problem is that when the Eclipse WTP Web services wizard invokes the Java2WSDLAxisAnt
task, the 
> task itself will construct an AntClassLoader around the classpath that the WS 
> wizard passes into the task.
> When creating Web service using Axis 1.2.1 runtime on a Tomcat 4.1 server,
> the classpath contains activation.jar and mail.jar.
> After the AntClassLoader is constructed, Axis will CACHE this classloader in a 
> class call ClassUtils. Later on, when the TypeMappingRegistry is initialized, 
> the TypeMappingRegistry will determine whether type mapping for attachment is 
> needed. The way this is determined is by calling:
> ClassUtils.forName("javax.activiation.DataHandler");
> Of course, when creating a Web service on Axis using Tomcat 4.1, 
> this returns true because ClassUtils uses the CACHED AntClassLoader, 
> which has activation.jar and mail.jar on its classpath. So the 
> TypeMappingRegistry will go ahead and initialize the type mapping for 
> attachment. However, in the attachment type mapping's initialization method, it 
> does a:
> Class.forName("javax.activiation.DataHandler");
> instead of a:
> ClassUtils.forName("javax.activiation.DataHandler");
> Since Class.forName("...") will go to the Eclipse class loader, which does not 
> have activation.jar and mail.jar on its classpath. A NoClassDefFoundError is 
> being thrown.
> This problem only starts happening with Axis 1.2.1.  The same scenario works in Axis
1.1 and Axis 1.0.
> This problem does not occur when using Tomcat 5.0 since mail.jar and activation.jar is
not in the classpath 
> passed to Java2WSDLAxisAnt task.  
> Here's the exception being thrown:
> --- Nested Exception ---
> java.lang.NoClassDefFoundError: javax/activation/DataSource
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(
>         at org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory.class$(J
>         at org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory.getSeria
> lizerClass(
>         at org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory.<init>(J
>         at org.apache.axis.encoding.DefaultTypeMappingImpl.initMappings(DefaultT
>         at org.apache.axis.encoding.DefaultTypeMappingImpl.<init>(DefaultTypeMap
>         at org.apache.axis.encoding.DefaultTypeMappingImpl.getSingletonDelegate(
>         at org.apache.axis.encoding.TypeMappingRegistryImpl.<init>(TypeMappingRe
>         at org.apache.axis.encoding.TypeMappingRegistryImpl.<init>(TypeMappingRe
>         at org.apache.axis.wsdl.fromJava.Emitter.<clinit>(
>         at
>         at
> mmand.executeAntTask(
>         at
> mmand.execute(
>         at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEng
> ine.runCommand(
>         at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEng
> ine.visitTop(
>         at org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEng
> ine.moveForwardToNextStop(
>         at org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineMa
> nager$
>         at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalCont
>         at
>         at
>         at org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineMa
> nager.runForwardToNextStop(
>         at
> ForwardToNextStop(
>         at org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.get
> NextPage(
>         at org.eclipse.wst.command.internal.env.ui.widgets.SimpleWizardPage.getN
> extPage(
>         at org.eclipse.jface.wizard.WizardDialog.nextPressed(
> 47)
>         at org.eclipse.jface.wizard.WizardDialog.buttonPressed(
> :345)
>         at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(
>         at org.eclipse.swt.widgets.TypedListener.handleEvent(
> 90)
>         at org.eclipse.swt.widgets.EventTable.sendEvent(
>         at org.eclipse.swt.widgets.Widget.sendEvent(
>         at org.eclipse.swt.widgets.Display.runDeferredEvents(
>         at org.eclipse.swt.widgets.Display.readAndDispatch(
>         at org.eclipse.jface.window.Window.runEventLoop(
>         at
>         at org.eclipse.wst.command.internal.env.ui.widgets.popup.DynamicPopupWiz
>         at org.eclipse.ui.internal.PluginAction.runWithEvent(
> 46)
>         at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection
> (
>         at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContri
>         at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionC
>         at org.eclipse.swt.widgets.EventTable.sendEvent(
>         at org.eclipse.swt.widgets.Widget.sendEvent(
>         at org.eclipse.swt.widgets.Display.runDeferredEvents(
>         at org.eclipse.swt.widgets.Display.readAndDispatch(
>         at org.eclipse.ui.internal.Workbench.runEventLoop(
>         at org.eclipse.ui.internal.Workbench.runUI(
>         at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav
> a:367)
>         at org.eclipse.ui.PlatformUI.createAndRunWorkbench(
>         at
> 3)
>         at org.eclipse.core.internal.runtime.PlatformActivator$
>         at
> va:376)
>         at
> va:163)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>         at java.lang.reflect.Method.invoke(
>         at org.eclipse.core.launcher.Main.invokeFramework(
>         at org.eclipse.core.launcher.Main.basicRun(
>         at
>         at org.eclipse.core.launcher.Main.main(
> We had to workaround the problem by explicitely not passing in mail.jar and activation.jar
(even though
> they are in the Tomcat 4.1 runtime library) when calling setClasspath for Java2WSDLAxisAnt
> so that Axis determines that isAttachmentEnabled is false and thus not do further attachment
> type mapping processing.
> We were trying to see if there's a way to manually set "isAttachmentEnable" to be false
but could not found one.  
> It would be helpful if an API exist for the user to optionally disable attachment processing
rather than having the Axis
> code "detects" it.
> Please let me know If you need any more information isolating the problem.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message