Thanks. I was really astounded to discover how hard it was to find a sort of 'hello world' sample of a Java main program that would bootstrap the OSGi environment, load some bundles, and get started.
On Sat, Jul 5, 2008 at 7:09 AM, David Savage <[EMAIL PROTECTED]> wrote: > 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 > >> > > >> > > >> > > >> > > > > > >
