Hi Stephan, to comment on your JAX-WS question: I kind of deferred it until now. I've also seen that there are a couple of places where there are direct dependencies on the RI which may need to be looked at closely. At any rate, I've been using CXF in OSGi with some success, so it may be possible to use CXF instead of the RI when working in an OSGi environment. After all, the JAX-WS APIs are supposed to give some degree of implementation-independence. Maybe the RI can also be made to work for us here. I'll run into that eventually and make the necessary experiments.
On 28.04.2010 21:57:05 Stephan Klevenz wrote: > Hi Jerimias, > > Thanks for bringing OSGi into discussion. This is very interesting. > > When we decided to moved the SessionFactoryImpl into the client package > then we did not consider OSGi. One reason for that was because of the > session is some kind of entry point into API and in the client package > it is just easy to find. I think we can revert this decision and move > back the factory to the runtime package. What do others think? > > Well, I'm not really an OSGi expert and that is why I'm asking > another question. OpenCMIS depends on other artifacts that are not OSGi > bundles. > For example JAX-WS is a plain set of libraries. How will be this > dependencies handled within a OSGi container? > > Regards, > Stephan > > > Am 28.04.2010 um 17:45 schrieb Jeremias Maerki: > > > Hi there, > > > > I hope I'm not duplicating someone else's work, but I've started to add > > OSGi metadata and other OSGi-related wiring (starting with the client), > > so OpenCMIS can eventually be deployed in an OSGi container. I'm happy > > to offer these changes to the project if there's interest. > > > > The problem I'm facing right now is that the SessionFactory interface > > and the SessionFactoryImpl class are both in the same package: > > org.apache.chemistry.opencmis.client > > That creates a collision which makes it impossible to consume a > > SessionFactory service published to the OSGi service registry, since an > > internal compatibility check fails and no service is returned. > > > > The problem would easily be solved by moving SessionFactoryImpl to the > > "runtime" subpackage. But I must also say that I don't really see the > > point to have SessionFactory alone in the "client" package when all the > > other related interfaces are in the "api" subpackage. I'd be happy, > > though, if we could at least move SessionFactoryImpl as indicated above. > > > > WDYT? > > > > Thanks, > > Jeremias Maerki > > > Jeremias Maerki
