I'm trying to deploy a Groovy/Grails app that uses GroovyWS (which wraps CXF
2.0.5) to OC4J, to no avail.
That's not to say I can't get the deploy to work. I can, but as soon as I
use the GroovyWS jar to create a client that has a couple of transport
classes in the WSDL, no go.
First, I had a problem with the fact that CXF (the main component of
GroovyWS) exec() to "javac" in order to compile the generated transport
classes. On the UNIX host my OC4J is running, it couldn't find javac. I
fixed this by placing a system property "path" in my container setup that
pointed at the jdk.
Now that it can find javac, however, I get compile errors to the effect that
javac can't find the import classes from jaxb:
package javax.xml.bind.annotation does not exist
[java] import javax.xml.bind.annotation.XmlAccessType;
(many of this type of exceptions occur) etc.
I've tried a couple things, both obvious and stuff I've found on the net:
- Added a system property "classpath" to include a copy of the jar with the
missing classes, no luck.
- Removed the CXF classes in groovyWS-all-0.4.jar, and added the newest CXF
jar to the war, no change
I've debugged a bit, and know that the classLoader I'm passing into new
WSClient is a URLClassLoader when I run in Jetty locally, but a
PolicyClassLoader (which extends URLClassLoader) when it runs on OC4J. I've
seen reference to this in some posts, but can't see how it would affect an
exec() to javac. Wouldn't the shell exec() runs in have it's own classpath?
Anyone gotten this to work? We're pretty much an OC4J house, and I'd really
hate to have to stand up a Tomcat or something just for this.
Thanks.
--
View this message in context:
http://www.nabble.com/GroovyWS-%28CXF%29-and-OC4J-issues-tp21672502p21672502.html
Sent from the cxf-user mailing list archive at Nabble.com.
