The additional dependency on the OSGi API in core (even though it is minor), and the ripple of this across the Restlet ecosystem, were what made this a non-starter before. I really think using the new conditional compilation support (editions) is the way to go.
Dave, if you're still listening, don't you have a more OSGi-friendly Restlet custom build already? If Jerome is OK with that direction, maybe we can pool our resources and submit a patch. On Mon, Aug 10, 2009 at 6:35 PM, Robin Hayman <robin...@aol.com> wrote: > Isn't the solution to making things work under OSGi to use the tools that > OSGi provides? > > When a new extension bundle comes on line it implements RestletExtension > then registers: > bc.registerService( RestletExtension.class.getName(),null,null); > > When something wants to find it, it uses: > (something like): > servRefs = bc.getServiceReferences( RestletExtension.class.getName(),null); > which finds all RestletExtensions, or, it can be specific, or use a filter. > > Such code does not take up much room because all it needs is the osgi api. > It can be mixed in with existing code with: > if(osgi-framework-present) do-it-this-way, if not do-it-the-other-way. > > Or use conditional compilation directives if we're counting bytes. > > It probably needs to be a bit more complicated to avoid start-up order > dependencies and get into ServiceTrackers. > > It is hard to be OSGi without using OSGi conventions. It is hard to do > things right if the only tool available is a jar manifest tweak. > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382231 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382459
