cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Date Fri, 27 Jul 2007 15:42:50 GMT
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 <jeffrey_metcalf@hotmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message