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. > 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? 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 > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
