> -----Original Message-----
> From: Philip Housley [mailto:[email protected]]
> Sent: 16 February 2009 17:38
> To: [email protected]
> Subject: Deploying to WebLogic
>
> 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.
For anyone who might find themselves in the same hole, I found what seems to be
a working solution. The route I took was to isolate the application as much as
possible from the server, and use as many included classes as I could.
This meant packaging the war into an ear, which has more precise package class
loading options.
Steps:
1) Copy all resources that Tuscany needs to discover into META-INF. This
includes wsdls, xsds, definitions.xmls. Relative links between the files will
still be followed, so I copied my wsdl/ and xsd/ folders up to the META-INF
root level.
2) Don't use sca-contribution.xml, instead copy composites into a
sca-deployables folder.
3) In the end I found that no options were needed in weblogic.xml, not even
prefer-web-inf-classes. I do still have the file, as I needed resource refs,
but I don't think the file is required otherwise.
4) Create ear descriptions: application.xml is as normal for a single web app
deployment, weblogic-application.xml has something like:
<prefer-application-packages>
<package-name>javax.xml.namespace.QName</package-name>
<package-name>javax.jws.*</package-name>
<package-name>javax.xml.bind.*</package-name>
</prefer-application-packages>
This loads the correct interfaces, so you don't get QName method not found
messages, etc.
5) Include all the jars that you would for a Tomcat deployment, including
wstx-asl.
This makes a rather strange app, as the packaged classes get engaged earlier
than you would expect. As far as I can make out, the actual deployment uses
the woodstox parser, meaning that you get an unexpected error at this stage on
stdout. I don't think this is a problem, just a disagreement between xml
implementations as to what is valid.
All this means that you will probably need a separate maven profile to build
weblogic packages, but as I said, it seems to work out in the end, more or
less. I'm not sure that everything has to be as I've described, but this is a
working setup for me.
One more thing that might help, if you get an error about not being able to
cast one or the other stax processors (either wstx or weblogics,) I think this
is because they are considered to be implementing different versions of the
apis - that is, they implement the same classes in name, but there are two
different class objects in the system representing that interface. This means
that the better javax interfaces aren't being loaded in time, or something like
that.
Hope this helps someone someday.
Phil.
