> -----Original Message-----
> From: Dave Sowerby [mailto:[email protected]]
> Sent: 16 February 2009 18:44
> To: [email protected]
> Subject: Re: Deploying to WebLogic
>
> Hey Phil,
>
> I feel your pain! I went through all of this process some time ago -
> I even documented the changes required, which you can see at:
>
> http://davesowerby.blogspot.com/2008/08/update-on-weblogic-with-
> tuscany.html
>
> Basically, it's all to do with incompatibilities between the provided
> weblogic XML parsers and those as introduced by Tuscany. The major
> problem is that from the weblogic side, you simply can't remove these
> libraries as they are part of the core weblogic.jar - so you can't
> even deprioritise them. So the solution is all about removing
> Tuscany's libraries and using weblogic's.
>
> If you follow the exclusions I highlight in that blog post (which I
> believe is referenced from the Tuscany FAQs), and add in these two new
> exclusions for 1.4 that follow you should hopefully be set!!
>
> Cheers,
>
> Dave.
>
> <dependency>
> <groupId>xerces</groupId>
> <artifactId>xmlParserAPIs</artifactId>
> <version>2.6.0</version>
> <scope>provided</scope>
> </dependency>
>
> <dependency>
> <groupId>org.apache.woden</groupId>
> <artifactId>woden-impl-dom</artifactId>
> <version>1.0M8</version>
> <scope>provided</scope>
> </dependency>
Thanks Dave, that has got me part way there but...
Your steps worked on the simple samples, (calculator-webapp/ws-webapp), but
there are more XML issues when I try to introduce security etc.
I'm now getting errors like:
java.lang.IllegalArgumentException: prefix cannot be "null" when creating a
QName
at javax.xml.namespace.QName.<init>(QName.java:170)
at
weblogic.xml.stax.XMLStreamReaderBase.getAttributeName(XMLStreamReaderBase.java:339)
at
javax.xml.stream.util.StreamReaderDelegate.getAttributeName(StreamReaderDelegate.java:128)
at
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.readExtendedAttributes(BaseAssemblyProcessor.java:870)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:192)
at
[ Huge amounts more ]
As far as I can work out this is because of using weblogic's version of
javax.xml.namespace.QName, which apparently doesn't have the same API as the
default (woden's I assume.) I have tried to switch to the normal woden
dependency, but I can't get it noticed except by preferring the classes in the
webapp, which brings back the original stax conflicts.
To make matters worse, WebLogic seems to be inconsistent in what it does when
trying to deploy. There are some combinations of settings which are accepted
when updating a deployment, but not when deploying it initially.
Any suggestions even more gratefully received than normal, I've been fighting
with this all day now.
Phil
> On Mon, Feb 16, 2009 at 5:38 PM, Philip Housley
> <[email protected]> wrote:
> > Hi,
> >
> > I'm trying to deploy a Tuscany driven web application to a WebLogic 9.2
> Server, and I'm finding the traditional dependency issues associated with
> that. The app works fine on Tomcat, but won't get past the
> deployment/startup stage on WebLogic.
> >
> > All the problems seem to be due to which stax parser is being engaged.
> There are various different messages depending on where I try to put the
> wstx jar in the classpath, and whether I tell WebLogic to prefer classes
> from the war, but I really can't see that any of the variations are
> getting me any closer. Has anyone tried doing this recently? Preferably
> with a 1.4 Tuscany on a 9.2 WebLogic, but any thoughts are welcome.
> >
> > It still seems to be the case that I will need to dump all my composites
> into META-INF, but that's a secondary problem at the moment.
> >
> > To run through some things I have tried:
> >
> > 1) Normal deploy, using a regular build with no weblogic specific
> descriptors.
> > 2) Setting weblogic.xml to have prefer-web-inf-classes=true.
> > 3) Putting wstx jar in the lib folders in WL (to insert it onto the
> classpath earlier in the process.)
> > 4) Updating to wstx 3.2.8 (which says it solves some app server issues.)
> > 5) Configuring the stax library using system properties set at runtime.
> >
> > Errors come from the range of:
> >
> > *) Complete failure to deploy (I think this is when it tries to use the
> war's stax impl to do the deployment, and it can't handle it.)
> >
> > *) java.lang.ClassCastException: com.ctc.wstx.stax.WstxInputFactory
> > at
> javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
> > at
> weblogic.servlet.internal.WebAppHelper.addListenerElements(WebAppHelper.ja
> va:244)
> > at
> weblogic.servlet.internal.WebAppHelper$IOHelperImpl.parseXML(WebAppHelper.
> java:224)
> > at
> weblogic.descriptor.DescriptorCache.parseXML(DescriptorCache.java:324)
> > at
> weblogic.servlet.internal.WebAppHelper.registerTagLibListeners(WebAppHelpe
> r.java:174)
> > Truncated. see log file for complete stacktrace
> >
> > * Successfully starts the node, but then failing to find any composites
> (I think only when they are in the classes folder, where WL can't see them
> for it's own reasons.)
> >
> > * Starts, but fails to parse the contribution metadata, saying that the
> Namespace for the composites is unknown. Or various other XML
> comprehension failures, presumably caused by using WLs internal stax
> engine.
> >
> > Is there any known way to build/deploy for WL? Or alternatively, does
> anyone recognize of the errors and know what do to about them? Sorry that
> this email is so long, but I'm in a bit of a rush, and didn't want to
> waste anyone's time by letting them suggest things that I have already
> tried.
> >
> > Thanks for any insights at all,
> >
> > Phil
> >
