Hi Benson, We're using equinox and knopflerfish at the moment - we're currently resolving a couple of minor issues to get working on felix. Turns out there a couple of differences with the way felix handles locking in the base level osgi log service implementation compared to equinox and knopflerfish. Probably wouldn't effect most end users but we're trying to do some funky stuff as a platform and it's causing us some headaches.
Anyway that's all an aside. The bundle fragment system is part of the OSGi specification so should be supported by all OSGi containers not just equinox - certainly it works in knopflerfish but I've not yet tried felix. A word of warning, bundle fragments can initially seem very useful but often get very messy in the long term. It may well be posting questions on this to the osgi-dev list as I'm sure you'll get some very good feedback as to whether your use case warrants the hassle fragments can cause :) Regards, Dave 2008/7/5 Benson Margulies <[EMAIL PROTECTED]>: > Could I ask a question in return about OSGi? > > Are you using Felix or Equinox? Do you happen to know if the Eclipse native > code bundle fragment system is a generic OSGi feature or specific to > Eclipse? > > > On Fri, Jul 4, 2008 at 7:24 AM, David Savage <[EMAIL PROTECTED]> > wrote: >> >> Hi Daniel, >> >> This was with CXF 2.1.1 I'm actually working on getting CXF working >> within infiniflow (based on newton - http://newton.codecauldron.org) >> as a provider of a web services binding. >> >> I've now managed to get the JaxWsProxyFactoryBean working now though >> it still needs the patch I mentioned to >> org.apache.cxf.frontend.ClientProxyFactoryBean - diff file attached. >> In this usecase the CXF libraries are packaged in one bundle but the >> "client" code i.e. the code that asks for the proxy to be created is >> packaged in a separate bundle. The CXF code is then linked to the >> client through the SCA of a binding. >> >> This allows multiple client bundles to reuse CXF without having to >> embed it in the client bundle (or for that matter even know that CXF >> is involved - they just ask for an SCA <binding.ws /> which happens to >> be implemented by CXF). However this means that the client bundle does >> not have the CXF libraries in it's bundle classpath - hence the need >> to do some classloader juggling via the Thread.contextClassLoader. >> >> In general I'm not a big fan of using Thread.contextClassLoader as >> it's a little ambiguous - prefer an explicit declaration of the >> classloader to be used but this would have been a much larger change >> to the CXF code which I didn't want to attempt without the aid of a >> safety net :) >> >> The "javax.xml.ws.WebServiceException: Could not find wsdl:binding >> operation info..." issue turned out to be with the way I was using the >> interface/impl - the combination that worked in the end was to >> explicitly add the @WebService etc annotations to the class/interface >> etc, like so: >> >> package com.paremus.infiniflow.example.cxf; >> >> import javax.jws.WebParam; >> import javax.jws.WebService; >> >> @WebService >> public interface HelloWorld { >> String sayHello(@WebParam(name="text") String name); >> } >> >> ------------------------------------------------------------- >> >> package com.paremus.infiniflow.example.cxf; >> >> import javax.jws.WebService; >> >> @WebService(endpointInterface = >> "com.paremus.infiniflow.example.cxf.HelloWorld", >> serviceName = "HelloWorld") >> >> public class HelloWorldImpl implements HelloWorld { >> public String sayHello(String name) { >> return "Hello " + name; >> } >> } >> >> I didn't get around to exploring what the minimum set of annotations >> was to get this working. Incidentally is there a case for CXF >> automagically inferring webservice info from interfaces that are this >> trivial? It seems a little verbose in this case to have to annotate a >> single method interface/impl. Though I appreciate this is not the >> general use case... >> >> I'm still having some problems with https but not sure this is OSGi >> related so possibly best to follow up in a separate email thread if >> necessary. I currently suspect issue is with my certificate chain as >> get a message >> >> 2008-07-03 13:23:25.023::WARN: EXCEPTION >> javax.net.ssl.SSLHandshakeException: Received fatal alert: >> certificate_unknown >> at >> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150) >> >> When the JaxWsProxy tries to invoke the method call on the client. >> >> Regards, >> >> Dave >> >> 2008/7/1 Daniel Kulp <[EMAIL PROTECTED]>: >> > >> > Have you tried this with CXF 2.1.1 or 2.1 or other? >> > >> > We did some work in 2.1.1 to hopefully help some of the issues, but I'm >> > not really sure about this specific issue. >> > >> > >> > In general, we kind of recommend using the spring dynamic modules for >> > OSGi. The servicemix 4 folks have an example at: >> > http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside >> > that shows how that works. When you do that, all the spring config >> > things should work. >> > >> > Dan >> > >> > On Jun 27, 2008, at 12:02 PM, David Savage wrote: >> > >> >> Hi there, >> >> >> >> I'm trying to get cxf to work in an OSGi environment and have been >> >> banging my head against the desk a bit, suspect it might be due to leaping >> >> in at the deep end but any help would be appreciated. >> >> >> >> Ok here's what I've got working: >> >> >> >> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean(); >> >> svrFactory.setServiceClass(HelloWorld.class); >> >> svrFactory.setServiceBean(HelloWorldImpl()); >> >> svrFactory.setAddress("http://localhost:9000/hello"; ); >> >> svrFactory.create(); >> >> >> >> This launches an internal jetty server and when I test this using a web >> >> browser I can at least see that the server is running as I get a soap >> >> response: >> >> >> >> <soap:Envelope> >> >> <soap:Body> >> >> <soap:Fault> >> >> <faultcode>soap:Server</faultcode> >> >> <faultstring>No such operation: </faultstring> >> >> </soap:Fault> >> >> </soap:Body> >> >> </soap:Envelope> >> >> >> >> However I've not been able to get a client working in OSGi. Initially >> >> this was due to code in the org.apache.cxf.frontend.ClientProxyFactoryBean >> >> which assumed the classloader to generate the proxy would be the loader of >> >> the client interface. I've worked around that in a local patch here by >> >> setting Thread.contextClassLoader. >> >> >> >> Here's what I have on the client side: >> >> >> >> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean(); >> >> factory.setServiceClass(reference.getInterface()); >> >> factory.setAddress("http://localhost:9000/hello";); >> >> // set context classloader >> >> ... >> >> HelloWorld proxy = factory.create(); >> >> proxy.sayHello("World"); >> >> >> >> >> >> However the client still fails due to a null BindingDetails object >> >> which is loaded when my test method is invoked: >> >> >> >> javax.xml.ws.WebServiceException: Could not find wsdl:binding operation >> >> info for web method sayHello. >> >> at >> >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150) >> >> at $Proxy35.sayHello(Unknown Source) >> >> >> >> Is there a stage I'm missing here? >> >> >> >> I'm also trying to get cxf to work with an https connection (both >> >> client and server). On the server side I've figured out that the process >> >> has >> >> something to do with doing something like: >> >> >> >> server = svrFactory.create(); >> >> >> >> JettyHTTPDestination dest = (JettyHTTPDestination) >> >> server.getDestination(); >> >> JettyHTTPServerEngine engine = (JettyHTTPServerEngine) >> >> dest.getEngine(); >> >> >> >> if ( secure ) { >> >> TLSServerParameters params = new TLSServerParameters(); >> >> // set params >> >> engine.setTlsServerParameters(params); >> >> } >> >> >> >> But again I'm not having much luck. Is there any example code I can >> >> follow or that someone can post to show how this should work? >> >> >> >> Thanks in advance for any help. >> >> >> >> Regards, >> >> >> >> Dave >> >> >> >> _______________________________________________________________________ >> >> Paremus Limited. Registered in England >> >> No. 4181472 >> >> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA >> >> Postal Address: 107-111 Fleet Street, London, EC4A 2AB >> >> The information transmitted is intended only for the person(s) or >> >> entity to which it is addressed and may contain confidential and/or >> >> privileged material. Any review, retransmission, dissemination or other >> >> use >> >> of, or taking of any action in reliance upon, this information by persons >> >> or >> >> entities other than the intended recipient is prohibited. >> >> If you received this in error, please contact the sender and delete the >> >> material from any computer. >> >> _______________________________________________________________________ >> > >> > --- >> > Daniel Kulp >> > [EMAIL PROTECTED] >> > http://www.dankulp.com/blog >> > >> > >> > >> > > >
