Re: Which OSGi?
Noel J. Bergman wrote: Stefano Bagnara wrote: IMHO OSGi specifications themselves are too low-level for James needs. We probably need an abstraction layer (avalon-osgi bridge or avalon-somelayer bridge) to simplify this move. Well ... :-) XBeans will apparently provide a bridge to OSGi, and IIRC, there is support for Avalon interfaces in XBeans. Alan? Did Dain ever get that work stable? I haven't heard anything about Avalon interfaces in XBeans. I read something about avalon-osgi bridge in the cocoon-dev mailing list: they seem to have a test osgified-cocoon in the whiteboard. Worth looking into. PS: as a footnote, IMHO an OSGi bundle is less "POJO" than an Avalon block. As I said, I think that it is worth doing the business logic POJOs for our classes, and then providing the container adapter. I agree w/ this statement. Regards, Alan
RE: Which OSGi?
>Steve Brewin wrote: > > Serge Knystautas wrote: > > > For my part, I'm planning to knock up some OSGi examples to > understand the > correlation between what OSGi provides and what we need. > Some initial results (restating the obvious for you OSGi aficionados out there). OSGi could provide us with a set of useful basic functionality and a way of exposing James' functionality to the rest of the world in a standards based manner. Each of the OSGi layers - Security, Module, Life Cycle and Service - could potentially be of benefit. However, OSGi alone is not a solution. The OSGi Module layer essentially defines a packaging system for components called bundles and how bundles can be assembled together. What it does not do is define how the class instances of a bundle are assembled; when and how class instances within a bundle obtain instances of the classes they require. This is totally open. Each bundle is free to use its own strategy. It might be some form of DI (dependency injection), use service lookup or a mishmash of many techniques. As has been suggested by myself and others, if we want to consisently use a chosen strategy, such as some form of IOC, an extra layer must be exposed for the use of each bundle that implements this strategy. The OSGi Life Cycle layer similarly defines a set of life cycle states - INSTALLED, RESOLVED, STARTING, ACTIVE, STOPPING, UNINSTALLED - operative at the bundle level. It does not define the part class instances of a bundle play in the life cycle. Again, the solution would be to expose an extra layer for the use of each bundle that implements our chosen life cycle strategy. These extra layers sound awfully like the kind of behaviours offered by lightweight containers such as Pico container or Spring's container kernel. So a solution might be OSGi plus a lightweight container. This is kind of ironic as I headed into this stage of the discussion hoping to shed some light on the choice between OSGi OR Pico OR Spring OR 'container of the month'. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
Here are a few related links that I'd like to "archive" with this thread: - Xenotron Service Manager [http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:xenotron] is a Dependency Manager bundle for osgi and I understand it is now part of felix. It seem really simpler than direct OSGi dependency management. - OSGi Plugin for Maven 2.0 [http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+2.0] is also an addon to felix and a good idea if we'll adopt maven2/osgi too. - OSGi support for Spring [http://opensource.atlassian.com/projects/spring/browse/SPR-1802]: maybe this is related to XBean. About Cocoon I found some OSGi related code in the whiteboard but unfortunatly it seems unrelated to Avalon. About the Geronimo and Directory projects from a quick overview I feel we should try to follow the directory project choices: they host the Daemon and Mina projects that could be an option for James 3, they use Maven2 and Felix and have the best repository and the best installer/win32 wrapper I saw in this apache projects. I'm going to dedicate more time to understand how they structured the components to have a better overview on the pro/cons of their choices. Last thing: I found this interesting page [http://wiki.apache.org/directory/IdeHome] about the use of Eclipse 3.1 to work with their maven2 repository. Stefano Noel J. Bergman wrote: Stefano Bagnara wrote: IMHO we should wait and look at geronimo/directory/cocoon moves. Directory is very active with Felix. Not sure what is happening with Cocoon. Geronimo is also looking at Felix, as I understand it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Steve Brewin wrote: > This raises the question of which OSGi release should James depend on? > I would say the level JSR 291 is based on which is r4. +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Stefano Bagnara wrote: > IMHO OSGi specifications themselves are too low-level for James needs. > We probably need an abstraction layer (avalon-osgi bridge or > avalon-somelayer bridge) to simplify this move. Well ... :-) XBeans will apparently provide a bridge to OSGi, and IIRC, there is support for Avalon interfaces in XBeans. Alan? Did Dain ever get that work stable? > I read something about avalon-osgi bridge in the cocoon-dev mailing > list: they seem to have a test osgified-cocoon in the whiteboard. Worth looking into. > PS: as a footnote, IMHO an OSGi bundle is less "POJO" than an Avalon block. As I said, I think that it is worth doing the business logic POJOs for our classes, and then providing the container adapter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Stefano Bagnara wrote: > IMHO we should wait and look at geronimo/directory/cocoon moves. Directory is very active with Felix. Not sure what is happening with Cocoon. Geronimo is also looking at Felix, as I understand it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
Steve Brewin wrote: Does anyone have any OSGi implementation preferences? I forgot to say that IMHO we should wait and look at geronimo/directory/cocoon moves. They have much more active committers and I think we should try to stick to one of their "application stack". Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
Noel J. Bergman wrote, On 4/13/2006 2:22 PM: Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). +1 Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
Steve Brewin wrote, On 4/13/2006 1:32 PM: IF we decide to go with the OSGi/JSR 291 container specification we also need to decide on an implementation. The one we test against and deliver in the distribution. Does anyone have any OSGi implementation preferences? I'm minded towards http://www.eclipse.org/equinox. If others know of superior alternatives please shout. Is everyone cool with packaging Eclipse components in our distribution? Is this within Apache's rules? I am not aware of any issues. XBean can use OSGi. You can check out its Maven POM to explore the minimum dependencies needed to run a server w/out the IDE. Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Serge Knystautas wrote: > On 4/13/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). > > Can there be more of a technical discussion on this? I still have > Avalon-aftertaste. :) Hopefully much more! And hopefully based on more concrete experience and examples. For my part, I'm planning to knock up some OSGi examples to understand the correlation between what OSGi provides and what we need. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
Steve Brewin wrote: Does anyone have any OSGi implementation preferences? IMHO OSGi specifications themselves are too low-level for James needs. We probably need an abstraction layer (avalon-osgi bridge or avalon-somelayer bridge) to simplify this move. (as a note Spring is supporting springbeans-OSGi bridge: http://opensource.atlassian.com/projects/spring/browse/SPR-1802 . I don't know how this is related to XBean-OSGi) Most OSGi implementations provides their own services (bundles) to simplify dependency management for services. I read something about avalon-osgi bridge in the cocoon-dev mailing list: they seem to have a test osgified-cocoon in the whiteboard. Furthermore to replace phoenix we need a Configuration service, possibly having a management GUI. If we don't want to create OSGi bundles for each cornerstone/excalibur service we probably need to find replacements for this service. Stefano PS: as a footnote, IMHO an OSGi bundle is less "POJO" than an Avalon block. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Serge Knystautas wrote: > Noel J. Bergman wrote: > > Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). > Can there be more of a technical discussion on this? More? LOTS MORE would be my expectation. I am also hoping that we can get a good group of folks together at ApacheCon in Dublin, and try to kickstart our efforts. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which OSGi?
On 4/13/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). Can there be more of a technical discussion on this? I still have Avalon-aftertaste. :) -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Noel J. Bergman wrote: > > > Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). > Fair point. Though the last ObjectWeb release was OSGi r3 compliant and Felix is targeting r4 but yet to be blessed as r4 compliant or a fully fledged Apache project (a post a moment ago said why we should be looking at r4. r4 == JSR 291). One to watch rather than base any immediate development on? -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
Eat our own dogfood: http://incubator.apache.org/felix (nee Oscar). --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which OSGi?
No direct experience myself but Knopflerfish comes highly recommended. Steve > -Original Message- > From: Steve Brewin [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 1:33 PM > To: 'James Developers List' > Subject: Which OSGi? > > IF we decide to go with the OSGi/JSR 291 container > specification we also need to decide on an implementation. > The one we test against and deliver in the distribution. > > Does anyone have any OSGi implementation preferences? > > I'm minded towards http://www.eclipse.org/equinox. If others > know of superior alternatives please shout. > > Is everyone cool with packaging Eclipse components in our > distribution? Is this within Apache's rules? I am not aware > of any issues. > > Cheers, > > -- Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
