Hi jeff, Could you file a JIRA issue for this? I think we (the CXF devs) need to do some debugging within GlassFish.
http://issuses.apache.org/jira/browse/CXF Thanks, - Dan On 7/25/07, Jeffrey Metcalf <[EMAIL PROTECTED]> wrote: > > Hi All, > > I have an update on this issue. Apparently the problem is that glassfish > (sun appserv 9.0) requires that all resource-refs be found on the Thread > context classloader. which is a parent to the web application classloader > for the deployed CXF service. I believe that this translates to an > application server classloader. From the CXF and Spring framework > perspective, this would be a glassfish problem/limitation. If I append > all > the CXF modules and dependencies to the application server classpath, all > problems go away and my service deploys and operates without a hitch. To > me > this is wrong and violates best practice. I don't want the CXF modules > and > dependencies (like spring framework) on the application server classpath. > Has anyone run into this problem on glassfish or other appservers and have > a > workaround consistent with J2EE application server best practices? > > Best regards, > > -Jeff > > > > >Hi Willem, > > > >Thanks for your help. After repackaging my WAR according to your > >instructions (with a few minor modifications), I was able to get much > >further and the service actually deploys on glassfish v1. My latest > error > >(which prevents my service from starting) is the following: > > > >java.lang.IllegalArgumentException: [org.apache.cxf.Bus] is not an > allowed > >property value type > > > >Any thoughts? I can provide more details if necessary. > > > >Cheers, > > > >-Jeff > > > >> > >>Hi Jeff, > >> > >>You can workaround by replacing the CXF bundler jar with the CXF module > >>jars. > >>In your case , you need to include: > >>cxf-rt-core-* > >>cxf-rt-frontend-simple-* > >>cxf-rt-frontend-jaxws-* > >>cxf-rt-bindings-soap-* > >>cxf-rt-bindings-xml-* > >>cxf-rt-api-* > >>cxf-rt-common-utilities-* > >>cxf-common-schemas-* > >>cxf-rt-transports-http-2.1-* > >> > >>or you can use the below dependences to build an war with maven. > >> > >> <dependencies> <dependency> > >> <groupId>org.apache.cxf</groupId> > >> <artifactId>cxf-rt-core</artifactId> > >> <version>${cxf.version}</version> > >> </dependency> > >> <dependency> > >> <groupId>org.apache.cxf</groupId> > >> <artifactId>cxf-rt-frontend-jaxws</artifactId> > >> <version>${cxf.version}</version> > >></dependency> <dependency> > >> <groupId>org.apache.cxf</groupId> > >> <artifactId>cxf-rt-transports-http</artifactId> > >> <version>${cxf.version}</version> > >></dependency> > >> </dependencies> > >> > >>Willem. > >> > >> > >>Jeffrey Metcalf wrote: > >>>Hi All, > >>> > >>>I am posting this question to inquire if anyone has thoughts on my > >>>problem. I developed a "top-down" SOAP web service from WSDL using the > >>>CXF wsdl2java tool and was able to successfully generate my service > >>>interface and stub implementation. After following the CXF user manual > >>>guide I configured my web.xml and beans.xml files according to the > basic > >>>examples. Pretty straightforward stuff. After bundling my code along > >>>with the standard third party CXF and other dependencies according to > >>>J2EE Web Archive specifications, I deployed the WAR file to glassfish > and > >>>get the following error message: > >>> > >>>Fatal Error from EJB Compiler -- Service DOMMessageProviderService has > an > >>>endpoint with non-HTTP binding but there is no WSDL; Deployment cannot > >>>proceed > >>>.. > >>>.. > >>>.. > >>> > >>>I have tried this on both glassfish 1.0 and 2.0 and get the same error > in > >>>both cases. As far as I can tell, the DOMMessageProviderService has > >>>nothing to do with my code. I poked around and was able to find an > >>>org.apache.cxf.js.rhino.DOMMessageProvider class in the core CXF jar. > >>>This seems to be intended for use with Javascript based services, and > >>>again is completely unrelated to my code. It almost seems to me that > >>>glassfish is hunting through all my class files in my dependencies > >>>looking for classes annotated with @WebService and trying to deploy > them. > >>> > >>>BTW...I am able to deploy the exact same WAR file to tomcat 5. It > >>>deploys and runs with no problems. The downside for me is that TC5 is > >>>not a full J2EE container and lacks some of the features I need from > >>>glassfish. > >>> > >>>Has anyone run across this or a similar problem? If so, any > workaround? > >>> > >>>Cheers, > >>> > >>>-Jeff > >>> > >>>_________________________________________________________________ > >>>Need a brain boost? Recharge with a stimulating game. Play now! > >>>http://club.live.com/home.aspx?icid=club_hotmailtextlink1 > >>> > > > >_________________________________________________________________ > >Don't get caught with egg on your face. Play Chicktionary! > >http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 > > > > _________________________________________________________________ > http://liveearth.msn.com > > -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
