Hi
thanks for getting to the bottom of it...
Hello Sergey,
Thank you for your response.
I worked on my envionment after posting question and now have 2 problems...
1. I used CXF2.2.5 and 2.2.6 versions. The wadl which I generated through
2.2.5 can be generated proper stubs out of it. But with version 2.2.6
whatever the wadl is generated, I am not able to generate stubs out of it.
When I try to generate stubs from wadl (2.2.6), I get error "JClass name is
empty".
The difference between both the wadl file is 2.2.6 is adding <resourse
path="/"> tag in method defination if @path tag is missing. but the 2.2.5is
not adding any resourse tag if @Path is missing.
<resource path="/contact">
<resource path="/">
<method name="GET"></method>
</resource>
<resource path="/getstub">
<method name="GET"></method>
</resource>
</resource>
In 2.2.6 multiple methods sharing the same root are listed under a single resource (though one can configure WADL generator to wrap
every method), so this is a sideeffect. I believe the above fragment is perfectly correct, I asked a similar question on the wadl
list...Why can't SoapUI be a bit more 'tolerant' so to say (wondering, should they be called WebServicesUI instead) ? I think I
tried to wrap even those methods which have no @Path (internally they have a '/' path value) to avoid some possible ambiguities to
do with other resources having to 'inherit' higher level template parameters, etc.
Ex, consider you top-level GET method accepting a @PathParam("id") value...which at the wadl level will be listed as a template
parameter visible to both this GET method and the "/getstub" resource. Now, when a tool like SoapUI is about to let user to test
"/getstub", should it also offer it an option to enter the "id" value too ? I hope you see my point here. A code gen tool would see
a similar issue.
However in 2.2.6 you can register a WADLGenerator instance as a JAXRS provider and set
"useSingleSlashResource" property to false.
This will ensure you see no resources with path="/" (except for the case when
the very top level root resource has this value)
Perhaps this property should be set to false by default - I'll update it
2. I can run my application from eclipse using 2.2.5 and generate proper
stub and run web services very fine. So no issues when I use eclipse.
Problem occur when I try to use Tomcat without eclipse. First issue I get
is:
java.lang.RuntimeException:
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'org.apache.cxf.wsdl.WSDLManager' defined in URL
[bundleresource://22.fwk10630672:21/META-INF/cxf/cxf.fixml]: Instantiation
of bean failed; nested exception is
org.springframework.beans.BeanInstantiationException: Could not instantiate
bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw
exception; nested exception is java.lang.NoClassDefFoundError: Could not
initialize class com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder
org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:96)
org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:86)
CXF JAXRS still indirectly depends on wsdl4j (definirtely will have to fixed for 2.3 and maybe for 2.2.7). Please drop it into the
tomcat lib folder. Oh, you're using OSGI...So install this bundle :
http://svn.apache.org/repos/asf/servicemix/smx4/bundles/tags/org.apache.servicemix.bundles.wsdl4j-1.6.2_2/
thanks, Sergey
When I try to google it, results directing me, Its classloader problem. Now
my question is "How same set up is working from eclipse" and not from Tomcat
directly. Any suggestion from running independently in tomcat without
eclipse.
Ashish
Sergey Beryozkin-2 wrote:
Hi
Hello guys,
I am trying to generate stubs for my restful web service using SoapUi
3.1.
When I try it with Jetty in eclipse, I got proper stubs generated. But
same
when I try it with Tomcat, I am getting error.
For deploying in Tomcat, I am using CXfNonSpringServlet. For running into
tomcat, I have to remove 2 jars (xmlbeans-2.4.0.jar and xalen-1.1.jar)
otherwise I am getting linker error. But for jetty no need for removing
these jars. As I am removing these jar, wadl file generated with "type"
tag.
<xs:element maxOccurs="unbounded" minOccurs="0" name="Contact"
type="contact"/> .
I do not see how the presense or absense of xmlbeans or xalan jars
could've affected the way a wadl grammar section has been
generated...
Due to this type attribute, SoapUI is not able to generate proper java
client stubs. SoapUI is pointing to wadl-dist-1.0-SNAPSHOT.jar for
generating stubs.
What my finding is difference between wadl generated by jetty and tomcat
is
complex type attribute which is defined somewhere below in wadl file. For
jetty there is no complex type attribute.
Jetty ex:
<xs:element maxOccurs="unbounded" minOccurs="0" name="Contact">
after this line Contact object defination is present.
So it is an anonymous complex type, something like
<element name="Contact">
<complexType>
...
</complexType>
</element>
?
But for tomcat:
<xs:element maxOccurs="unbounded" minOccurs="0" name="Contact"
type="contact"/>
and "contact" is defined below in wadl file. When I try to generate with
this wadl file using SoapUI, I am getting error, complex type contact is
not
resolved.
Are sure it is not something like
<xs:element maxOccurs="unbounded" minOccurs="0" name="Contact"
type="tns:contact"/>
where tns is bound to some namespace ?
By the way, is it CXF (JAXRS) which generates WADL ? Can you attach the
WADL instance which SoapUI can not handle ?
cheers, Sergey
What I feel is 2 jars (xmlbeans-2.4.0.jar and xalen-1.1.jar) are required
to
generate proper wadl and client stub.
Now my question is, "How can I deploy webservices in tomcat with these 2
jars in it"? One more point, I am running it as osgi bundle not using
DOSGi.
--
View this message in context:
http://old.nabble.com/Deploying-web-services-in-tomcat.-tp27421210p27421210.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/Deploying-web-services-in-tomcat.-tp27421210p27437054.html
Sent from the cxf-user mailing list archive at Nabble.com.
