On 04/08/2013 02:41 PM, Daniel Kulp wrote:
On Apr 8, 2013, at 2:19 PM, Glen Mazza <[email protected]> wrote:
OK, I removed the <Require-Bundle/> tag and the web service provider still works --
thanks. I've incurred a couple more issues, however, I don't know if these are CXF bugs (I'll
type up a JIRA if they are) or just "features":
1.) For what I thought, if I *don't* define a etc/org.ops4j.pax.web.cfg file
indicating my desired HTTP port the web service will default to port 8080.
However, in Karaf 2.3.2 (at least) I'm not able to get the WSDL to appear
unless I explicitly create that file with a defined org.osgi.service.http.port
value (whether 8040 or 8080 or whatever, the web service will use whatever port
I define). Question: Is this a CXF bug, the need to have explicitly create
this configuration file even if I just want the default of 8080? (Or maybe
Karaf is using another default value? I'm not sure, the Karaf log file just
tells me that Pax web has started with no port indication if I don't define
that config file.)
Honestly, I have no idea. :-( It might be 8181, but I'm not sure.
If you're on Linux, try doing a "netstat -anp" and see what ports the "java"
processes are holding.
Yes, it's 8181, and now that I know the port I confirmed the web service
works without the .cfg file. I put in a JIRA item for Pax Web to always
log the port being used to eliminate the guesswork in trying to figure
out the port: https://ops4j1.jira.com/browse/PAXWEB-556
2.) My process to install the web service is as follows (works like a charm):
karaf@root> features:addurl
mvn:org.apache.cxf.karaf/apache-cxf/2.7.4/xml/features
karaf@root> features:install cxf
karaf@root> install
mvn:org.gmazza.blog-samples.web-service-tutorial/web-service-tutorial-service/1.0-SNAPSHOT
Bundle ID: 159
karaf@root> start 159
karaf@root> list
START LEVEL 100 , List Threshold: 50
ID State Blueprint Spring Level Name
[ 135] [Active ] [ ] [ ] [ 80] Apache MINA Core (2.0.5)
[ 158] [Active ] [ ] [ ] [ 50] Apache CXF Compatibility
Bundle Jar (2.7.4)
[ 159] [Active ] [Created ] [ ] [ 80] -- Web Service Provider
(1.0.0.SNAPSHOT)
However, for a simple SOAP web service with no security I'm guessing I
shouldn't have to install the whole cxf feature (which includes everything) but
just cxf-jaxws, as defined in the CXF features file:
http://svn.apache.org/viewvc/cxf/trunk/osgi/karaf/features/src/main/resources/features.xml?view=markup
But if I do that I get this error:
karaf@root> features:addurl
mvn:org.apache.cxf.karaf/apache-cxf/2.7.4/xml/features
karaf@root> features:install cxf-jaxws
karaf@root> install
mvn:org.gmazza.blog-samples.web-service-tutorial/web-service-tutorial-service/1.0-SNAPSHOT
Bundle ID: 104
karaf@root> start 104
Error executing command: Error starting bundles:
Unable to start bundle 104: Unresolved constraint in bundle
web-service-tutorial-service [104]: Unable to resolve 104.0: missing
requirement [104.0] osgi.wiring.bundle;
(osgi.wiring.bundle=org.apache.cxf.bundle)
karaf@root> list
START LEVEL 100 , List Threshold: 50
ID State Blueprint Level Name
[ 104] [Installed ] [ ] [ 80] -- Web Service Provider
(1.0.0.SNAPSHOT)
Question: Are we always supposed to install the cxf feature regardless of what
CXF service we're using (whether REST or SOAP), or is there a bundle missing in
the cxf-jaxws feature definition preventing me from using just that for my SOAP
service?
It sounds like the "Require-Bundle" header is still there. If you do a "headers
104", what is printed?
Yes, Require-Bundle was still there -- I had removed it from the client
but I forgot the service. Both now work with the cxf-jaxws feature alone.
Thanks!
Glen
Dan
Thanks,
Glen
On 04/08/2013 11:35 AM, Daniel Kulp wrote:
On Apr 8, 2013, at 11:26 AM, Glen Mazza <[email protected]> wrote:
Hi, my WSDL-first tutorial provides an option to host the web service provider
on an OSGi container (
http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep3-service). My
maven-bundle-plugin configuration in the service's pom.xml (which works fine)
is as follows:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Require-Bundle>org.apache.cxf.bundle,org.springframework.beans</Require-Bundle>
<Export-Package>service</Export-Package>
</instructions>
</configuration>
</plugin>
Question though, I don't know if I should be using a more granular bundle than the
"org.apache.cxf.bundle" listed above -- I can't find a sample using something different,
but IIRC CXF had/has a huge deprecated OSGi bundle that included everything, I'm unsure if
"org.apache.cxf.bundle" is referring to that super-bundle, and hence I should be using
something else today.
With "modern" CXF usage, you shouldn't need the Require-Bundle stuff there at
all, especially if you flip to using Blueprint instead of Spring.
Another question: What object in the CXF source code is "org.apache.cxf.bundle" precisely referring to -- I can't
find it within the CXF features file (
http://svn.apache.org/viewvc/cxf/trunk/osgi/karaf/features/src/main/resources/features.xml?view=markup) and a <grep -r
"org.apache.cxf.bundle" . --include "pom.xml"> from the CXF trunk is returning nothing. Stated
another way, if the CXF team wanted to change the name of the require-bundle to "org.apache.cxf.bundle.banana",
which pom.xml file (or other file?) in the CXF source would need to be changed to accomplish that?
Well, it's actually one of two bundles depending on the environment:
osgi/bundle/all - the big massive bundle from the <=2.5.x days.
<bundle.symbolic.name>${project.groupId}.bundle</bundle.symbolic.name>
or:
osgi/bundle/compatible - for >=2.6.x, this is a tiny bundle named the same as
the big bundle designed to provide some level of compatibility with the older big
bundle by providing a bundle with the same name (so the Require-Bundle works).
In any case, for modern usage, I'd recommend removing the Require-Bundle
entirely and let the maven bundle plugin do it's thing properly.
Hope that helps!
Dan
Thanks,
Glen
--
Glen Mazza
http://www.jroller.com/gmazza/
Twitter: glenmazza
--
Glen Mazza
http://www.jroller.com/gmazza/
Twitter: glenmazza
--
Glen Mazza
http://www.jroller.com/gmazza/
Twitter: glenmazza
