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 jayachandra <ja...@gmail.com> on 2005/09/09 12:06:09 UTC
[Axis2] Subtle yet serious issue
Guys!
I've identified this with great hardship trying to run some saaj related
test kit.
The issue is, as a dependency for wsdl module (data binding) we are using
xbean-2.0.0-beta1.jar. But **this jar has redefined javax.xml.soap package
classes and the crucial of them SOAPMessageFactory.java, and
SOAPFactory.java (abstract classes) are pointing to axis 1.x version
implementation classes in their newInstance() methods**
So meaning, once the user deploys axis2 on tomcat, if this xbean jar comes
first in his classpath, then all the saaj specific implementation would be
referring to axis1.x implementation and not our Axis2
org.apache.axis2.saaj.* implementation.
@Ajith!
Do we need javax.xml.soap. package bundled along with xbean jar, in the
first place. I don't know why xml beans was using saaj apis. If we seriously
need them, can we tweak the jar such that the existing harded coded values
like "org.apache.axis.soap.SOAPMessageFactoryImpl" be modified to "
org.apache.axis2.saaj.SOAPMessageFactoryImpl" and rehost the jar at some
alternate location. Or more better, we can build saaj prior to wsdl module
and use axis2-saaj-${pom.version}.jar along with the jar containing core
xmlbeans classes.
Thank you
Jayachandra
--
-- Jaya
Re: [Axis2] Subtle yet serious issue
Posted by Venkat Reddy <vr...@gmail.com>.
Actually the original issue reported by Jaya seems slightly different.
The xbean-2.0.0-beta1.jar has classes like SOAPMessageFactory and
other javax.xml.soap classes. SOAPMessageFactory has hard-coded
reference to Axis 1.x implementation for SOAPMessageFactoryImpl, and
thus, clashing with Axis2 SAAJ implementation. I'm not sure if these
classes are really required for XML beans functionality. Could someone
tell us if there is an already existing bug report related to this, or
is this as designed?
- venkat
On 9/12/05, Steve Loughran <st...@apache.org> wrote:
> Steve Loughran wrote:
> > David Jencks wrote:
> >
> >> I'm not entirely sure what the problem you are running into is, but I
> >> recall some discussion on the xmlbeans list about something that
> >> sounds related to me. I think that in xbean-2.0.0.jar the classes
> >> involved have been moved into an xmlbeans package from the
> >> javax.xml.soap package. There are several other bug fixes in 2.0.0
> >> that made it usable in geronimo, so you may want to upgrade anyway.
> >>
> >> thanks
> >> david jencks
> >>
> >
> >
> > I've just had a look and in xmlbeans-2.0.0 there are
> >
> > org.apache.xmlbeans
> > javax.xml.namespace.QName (the java1.5 thingy?)
> > org.w3c.dom. DomConfiguration/DomStringList/TypeInfo/UserDataHandler
> >
> > repackage.*
> > schemaorg_apache_xmlbeans.*
> >
> > Now, jsr173_api.jar also includes javax.xml.namespace.QName, as does
> > xmlpublic.jar. I dont know why it is everywhere, but it is harmless, *as
> > long as nobody seals any of their JAR files*. The moment you try and
> > seal any of those jars, everything breaks. Which is why mixing in other
> > people's .class files is a bad thing, at least from the perspective of
> > those of us who do sign and seal our jars before deployment. I will have
> > to purge them all out.
> >
>
> looks like this is a known defect:
> http://issues.apache.org/jira/browse/XMLBEANS-193
>
> as an aside, this is why signing jars during dev is good practise. It
> verifies that your code can be signed, and so used in things like java
> web start.
>
Re: [Axis2] Subtle yet serious issue
Posted by Steve Loughran <st...@apache.org>.
Steve Loughran wrote:
> David Jencks wrote:
>
>> I'm not entirely sure what the problem you are running into is, but I
>> recall some discussion on the xmlbeans list about something that
>> sounds related to me. I think that in xbean-2.0.0.jar the classes
>> involved have been moved into an xmlbeans package from the
>> javax.xml.soap package. There are several other bug fixes in 2.0.0
>> that made it usable in geronimo, so you may want to upgrade anyway.
>>
>> thanks
>> david jencks
>>
>
>
> I've just had a look and in xmlbeans-2.0.0 there are
>
> org.apache.xmlbeans
> javax.xml.namespace.QName (the java1.5 thingy?)
> org.w3c.dom. DomConfiguration/DomStringList/TypeInfo/UserDataHandler
>
> repackage.*
> schemaorg_apache_xmlbeans.*
>
> Now, jsr173_api.jar also includes javax.xml.namespace.QName, as does
> xmlpublic.jar. I dont know why it is everywhere, but it is harmless, *as
> long as nobody seals any of their JAR files*. The moment you try and
> seal any of those jars, everything breaks. Which is why mixing in other
> people's .class files is a bad thing, at least from the perspective of
> those of us who do sign and seal our jars before deployment. I will have
> to purge them all out.
>
looks like this is a known defect:
http://issues.apache.org/jira/browse/XMLBEANS-193
as an aside, this is why signing jars during dev is good practise. It
verifies that your code can be signed, and so used in things like java
web start.
Re: [Axis2] Subtle yet serious issue
Posted by Steve Loughran <st...@apache.org>.
David Jencks wrote:
> I'm not entirely sure what the problem you are running into is, but I
> recall some discussion on the xmlbeans list about something that sounds
> related to me. I think that in xbean-2.0.0.jar the classes involved
> have been moved into an xmlbeans package from the javax.xml.soap
> package. There are several other bug fixes in 2.0.0 that made it usable
> in geronimo, so you may want to upgrade anyway.
>
> thanks
> david jencks
>
I've just had a look and in xmlbeans-2.0.0 there are
org.apache.xmlbeans
javax.xml.namespace.QName (the java1.5 thingy?)
org.w3c.dom. DomConfiguration/DomStringList/TypeInfo/UserDataHandler
repackage.*
schemaorg_apache_xmlbeans.*
Now, jsr173_api.jar also includes javax.xml.namespace.QName, as does
xmlpublic.jar. I dont know why it is everywhere, but it is harmless, *as
long as nobody seals any of their JAR files*. The moment you try and
seal any of those jars, everything breaks. Which is why mixing in other
people's .class files is a bad thing, at least from the perspective of
those of us who do sign and seal our jars before deployment. I will have
to purge them all out.
-Steve
Re: [Axis2] Subtle yet serious issue
Posted by David Jencks <dj...@apache.org>.
I'm not entirely sure what the problem you are running into is, but I
recall some discussion on the xmlbeans list about something that sounds
related to me. I think that in xbean-2.0.0.jar the classes involved
have been moved into an xmlbeans package from the javax.xml.soap
package. There are several other bug fixes in 2.0.0 that made it
usable in geronimo, so you may want to upgrade anyway.
thanks
david jencks
On Sep 9, 2005, at 3:06 AM, jayachandra wrote:
> Guys!
> I've identified this with great hardship trying to run some saaj
> related test kit.
>
> The issue is, as a dependency for wsdl module (data binding) we are
> using xbean-2.0.0-beta1.jar. But **this jar has redefined
> javax.xml.soap package classes and the crucial of them
> SOAPMessageFactory.java, and SOAPFactory.java (abstract classes) are
> pointing to axis 1.x version implementation classes in their
> newInstance() methods**
> So meaning, once the user deploys axis2 on tomcat, if this xbean jar
> comes first in his classpath, then all the saaj specific
> implementation would be referring to axis1.x implementation and not
> our Axis2 org.apache.axis2.saaj.* implementation.
>
> @Ajith!
> Do we need javax.xml.soap. package bundled along with xbean jar, in
> the first place. I don't know why xml beans was using saaj apis. If we
> seriously need them, can we tweak the jar such that the existing
> harded coded values like "
> org.apache.axis.soap.SOAPMessageFactoryImpl" be modified to
> "org.apache.axis2.saaj.SOAPMessageFactoryImpl" and rehost the jar at
> some alternate location. Or more better, we can build saaj prior to
> wsdl module and use axis2-saaj-${ pom.version}.jar along with the jar
> containing core xmlbeans classes.
>
> Thank you
> Jayachandra
> --
> -- Jaya
Re: [Axis2] Subtle yet serious issue
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hmm.. I'll have to look into this. The XMLbeans jar was included as is and I
have no Idea why they need to have saaj inside! Perhaps they have another
stripped down version that I can download and set in the project.properties
On 9/9/05, Venkat Reddy <vr...@gmail.com> wrote:
>
> Thats weird! Good find, Jaya :-)
> Is it within our control or do we need to convince XMLBeans folks to
> fix this issue?
>
> -venkat
>
> On 9/9/05, jayachandra <ja...@gmail.com> wrote:
> > Guys!
> > I've identified this with great hardship trying to run some saaj related
> > test kit.
> >
> > The issue is, as a dependency for wsdl module (data binding) we are
> using
> > xbean-2.0.0-beta1.jar. But **this jar has redefined javax.xml.soappackage
> > classes and the crucial of them SOAPMessageFactory.java, and
> > SOAPFactory.java (abstract classes) are pointing to axis 1.x version
> > implementation classes in their newInstance() methods**
> > So meaning, once the user deploys axis2 on tomcat, if this xbean jar
> comes
> > first in his classpath, then all the saaj specific implementation would
> be
> > referring to axis1.x implementation and not our Axis2
> > org.apache.axis2.saaj.* implementation.
> >
> > @Ajith!
> > Do we need javax.xml.soap. package bundled along with xbean jar, in the
> > first place. I don't know why xml beans was using saaj apis. If we
> seriously
> > need them, can we tweak the jar such that the existing harded coded
> values
> > like " org.apache.axis.soap.SOAPMessageFactoryImpl" be
> > modified to "org.apache.axis2.saaj.SOAPMessageFactoryImpl"
> > and rehost the jar at some alternate location. Or more better, we can
> build
> > saaj prior to wsdl module and use axis2-saaj-${ pom.version}.jar along
> with
> > the jar containing core xmlbeans classes.
> >
> > Thank you
> > Jayachandra
> > --
> > -- Jaya
>
--
Ajith Ranabahu
Re: [Axis2] Subtle yet serious issue
Posted by Venkat Reddy <vr...@gmail.com>.
Thats weird! Good find, Jaya :-)
Is it within our control or do we need to convince XMLBeans folks to
fix this issue?
-venkat
On 9/9/05, jayachandra <ja...@gmail.com> wrote:
> Guys!
> I've identified this with great hardship trying to run some saaj related
> test kit.
>
> The issue is, as a dependency for wsdl module (data binding) we are using
> xbean-2.0.0-beta1.jar. But **this jar has redefined javax.xml.soap package
> classes and the crucial of them SOAPMessageFactory.java, and
> SOAPFactory.java (abstract classes) are pointing to axis 1.x version
> implementation classes in their newInstance() methods**
> So meaning, once the user deploys axis2 on tomcat, if this xbean jar comes
> first in his classpath, then all the saaj specific implementation would be
> referring to axis1.x implementation and not our Axis2
> org.apache.axis2.saaj.* implementation.
>
> @Ajith!
> Do we need javax.xml.soap. package bundled along with xbean jar, in the
> first place. I don't know why xml beans was using saaj apis. If we seriously
> need them, can we tweak the jar such that the existing harded coded values
> like " org.apache.axis.soap.SOAPMessageFactoryImpl" be
> modified to "org.apache.axis2.saaj.SOAPMessageFactoryImpl"
> and rehost the jar at some alternate location. Or more better, we can build
> saaj prior to wsdl module and use axis2-saaj-${ pom.version}.jar along with
> the jar containing core xmlbeans classes.
>
> Thank you
> Jayachandra
> --
> -- Jaya