Yeah, that's what I have been working on for ServiceMix 4.0. The core module contains the implementation of the api module. Both are not tied to OSGi at all. The OSGi bits and wiring bits are all done using spring-osgi in the nmr nodule. That way, ServiceMix core container is independant of both OSGi and Spring and can be easily enbedded. This works because I have introduced internal registries in ServiceMix api, which are automatically populated from the OSGi registry using spring service trackers. So using it in a non OSGi environment basically means that you have to register the services using ServiceMix api instead of registering them in the OSGi registry, but everything else should work the same.
On 10/5/07, Chris Custine <[EMAIL PROTECTED]> wrote: > On 10/4/07, Bruce Snyder <[EMAIL PROTECTED]> wrote: > > > > On 10/4/07, Chris Custine <[EMAIL PROTECTED]> wrote: > > > I agree that eventually you will have certain components that have their > > own > > > release cycles seperate from the core components. I think it will take > > > several releases of all components as an entire system before you will > > be > > > comfortable splitting things into seperate sub-projects, but as the core > > > components mature and stabilize I think it will be a natural desire to > > have > > > more frequent releases of the optional components. > > > > Agreed. > > > > > The dependency management issues mentioned by Bruce and Kit are valid, > > but > > > don't forget that the bundles are able to specify required version > > > information for their own dependencies. So the dependency management > > issue > > > is more about shipping a properly working default configuration with the > > > main ServiceMix distribution than about the seperate releases of > > components. > > > > That's a good point and something I forgot about. I guess we'll need > > to relax any static version requirements once the core stablizes so > > that we can allow a wider range of acceptable versions of various > > components. > > > > > I like Guillaume's idea of offering a basic image that is capable of > > > provisioning itself from a managed OBR repository. This could also > > allow a > > > user to configure their own customized provisioning configuration > > similar to > > > kickstart files for Linux distributions. I think you will also want to > > > offer a fully loaded and self contained image that already has all of > > the > > > components available, but the auto-provisioned basic image will be very > > > useful for a lot of users I would think. > > > > I think this is a good paradigm as well. However, a question arose > > today about continuing to allow ServiceMix to be embedded in any old > > Java app. Some folks may want an OSGi container to be started when > > embedding ServiceMix, and some may not. All I'm saying is that we need > > to keep this in mind as a requirement because there are a fair amount > > of users who are embedding ServiceMix today. > > > I have had to think about this same issue with Apache Directory Server. > ApacheDS has many users that embed as well as many users of the standalone > server and this will be an issue for us as we move the server to an OSGi > container as well. It may be different for ServiceMix, but for ApacheDS I > want to be able to offer the ability to embed without using OSGi or Spring > at all. > > I haven't worked out all the details yet, but I am thinking about a > component that contains all of the OSGi specific code and manages the server > components which are just library bundles with OSGi Manifest headers so that > they can also be used as simple jar files outside of OSGi. If you wanted to > embed, then the OSGi component is not used, and instead you could have a > facade that basically does what the standalone server does today (use Spring > to load app context and wire components), or just wire the components up > directly in the user's own code (ADS has people doing this as well). So > this basically exposes 3 distinct use cases with progressively lower levels > of integration. Now the trick is to accomplish this without introducing a > maintenance nightmare. :-) > > Thanks, > Chris > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
