Thanks, everyone. With this, I can now fetch the SessionFactory from the
OSGi service registry and enumerate the repositories via AtomPub:

ka...@root> cmis:play
ID: dummy-rep
Name: Dummy Repository
Description: Dummy Repository
Product Name: OpenCMIS Server
Product Version: 1.0
Vendor Name: OpenCMIS
CMIS Version: 1.0
Root Folder ID: root
Thin Client URI: null
ka...@root>

Tomorrow, I'll make further experiments.

On 29.04.2010 14:59:49 Florent Guillaume wrote:
> Done.
> http://svn.apache.org/viewvc?rev=939300&view=rev
> 
> 
> On Thu, Apr 29, 2010 at 2:55 PM, Florian Müller <[email protected]> wrote:
> > +1
> >
> > Florian
> >
> > -----Original Message-----
> > From: Florent Guillaume [mailto:[email protected]]
> > Sent: Donnerstag, 29. April 2010 04:36
> > To: chemistry-dev
> > Subject: Re: Issues with OSGi-compatibility in OpenCMIS Client
> >
> > Thanks Jeremias for the OSGi work, this is indeed nice.
> >
> > I agree with you guys that we can move SessionFactoryImpl into
> > client.runtime without a problem. Everyone has autocompletion in their
> > IDE anyway, so it's not a big deal I think.
> > I'm also in favor of moving SessionFactory to client.api.
> >
> > I can do it if there's consensus but people don't have time to work on it.
> >
> > Florent
> >
> > On Wed, Apr 28, 2010 at 9:57 PM, Stephan Klevenz <[email protected]> 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
> >>>
> >>
> >>
> >
> >
> >
> > --
> > Florent Guillaume, Director of R&D, Nuxeo
> > Open Source, Java EE based, Enterprise Content Management (ECM)
> > http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87
> >
> 
> 
> 
> -- 
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87




Jeremias Maerki

Reply via email to