You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jeffrey Metcalf <je...@hotmail.com> on 2007/07/25 04:46:16 UTC
Unable to deploy CXF 2.0 service to glassfish (sun app server)
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
Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Posted by Bozhong Lin <bl...@iona.com>.
logged and tracked here [1]
Cheers,
Bo
[1] https://issues.apache.org/jira/browse/CXF-857
Dan Diephouse wrote:
> 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 <je...@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
>>
>
Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <je...@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
Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Posted by Jeffrey Metcalf <je...@hotmail.com>.
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
Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Posted by Jeffrey Metcalf <je...@hotmail.com>.
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
Re: Unable to deploy CXF 2.0 service to glassfish (sun app server)
Posted by Willem Jiang <ni...@iona.com>.
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
>