> So I have now two, in my opinion oppositional statements. Does DS activate > my serviceimpl bundle or does it not?
The statements are not in opposition. As BJ said, DS does NOT activate your serviceimpl bundle. However as Tom said, your serviceimpl bundle WILL be activated by a management agent bundle that is part of Eclipse (it's somewhere in P2 I believe). If that management agent did not exist in Eclipse, or you were using OSGi without the Eclipse runtime bundles, then your serviceimpl bundle would not start and you would need to write a simple agent yourself. > There was a question why we do split > service and service implementation in two bundles. We do it in order to > deploy the service bundle client side AND server side but serviceimpl only > server side. We do not want the server logic to reside client side. The problem is that as soon as you introduce the reverse dependency from the service bundle onto the serviceimpl bundle you have negated all the benefits of this separation. > So if my service interface is in service-bundle and the service > implementation with DS stuff in serviceimpl-bundle, will the serviceimpl > bundle be started? Yes, it will be started by the Eclipse management agent bundle if you set "Bundle-ActivationPolicy: lazy". > As the service-bundle has no dependencies to serviceimpl > lazy activation won't work in my opinion, or does DS handle this somehow? Please remember that dependencies have nothing to do with activation. You cannot start a bundle merely by depending on it, even when lazy activation is used. Regards Neil > Eugen > BJ Hargrave wrote: > > Note: This still requires that someone has called > Bundle.start(START_ACTIVATION_POLICY) on the bundle containing the DS > components. This only needs to be done once since the start state is > persistently recorded. > > DS will always ignore bundles in the RESOLVED state. > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [email protected] > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > From: Thomas Watson/Austin/i...@ibmus > To: OSGi Developer Mail List <[email protected]> > Date: 2009/04/30 11:40 > Subject: Re: [osgi-dev] Certain service registration > Sent by: [email protected] > > ________________________________ > > > Another option is to use Declarative Services and lazy activation. The DS > implementation in Equinox supports lazy activated bundles. A lazy activated > bundle can provide a service component while it is in the STARTING (waiting > for first class load) state. Once the service component is used the DS > runtime will load your service impl class and cause your bundle to move to > the ACTIVE state. > > Tom > > > > <mime-attachment.gif>BJ Hargrave---04/30/2009 10:32:02 AM---I don't know why > you have 2 bundles: service and serviceimpl. Normally one does that to > decouple the bundle exporting the servi > <mime-attachment.gif> > From: <mime-attachment.gif> > BJ Hargrave/Austin/i...@ibmus > <mime-attachment.gif> > To: <mime-attachment.gif> > OSGi Developer Mail List <[email protected]> > <mime-attachment.gif> > Date: <mime-attachment.gif> > 04/30/2009 10:32 AM > <mime-attachment.gif> > Subject: <mime-attachment.gif> > Re: [osgi-dev] Certain service registration > ________________________________ > > > I don't know why you have 2 bundles: service and serviceimpl. Normally one > does that to decouple the bundle exporting the service interfaces from the > bundle implementing the service. But you do that and then couple the service > bundle to the serviceimpl bundle by having the service bundle start the > serviceimpl bundle! > > The simplest solution here seems to be: combine into one bundle and make > that bundle use lazy activation. Then the first time one of the service > interface classes is loaded, your activator will run and will register the > service. > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [email protected] > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > From: Eugen Reiswich <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 2009/04/30 11:07 > Subject: Re: [osgi-dev] Certain service registration > Sent by: [email protected] > > ________________________________ > > > Hi Neil, > > you have exactly pointed out my problem with OSGi in RCP applications! > >> I believe the solution is to use Declarative Services. In DS, services >> can be registered in the service registry before the actual >> implementation object for the service is instantiated -- in fact, this >> is the default behaviour. A bundle offering services via DS still need >> to be activated, but now the activation is "free" because a >> classloader does not need to be created for the bundle until the >> service is actually used. > > Is DS really the only way? I have downloaded Eclipse M6 and tested the > DS-Editor. Well, how do I say it polite? If I have 2, 3 or even more > components in one bundle that require OSGi services I have to create > (if I got it right) 2, 3 or even more XML files with service-component- > descriptions. This sounds like XML-hell. > >> To make this work in an Eclipse RCP environment, there are two >> possible approaches. First, explicitly name the bundles offering >> services in config.ini, and add the @start modifier. If you do not >> know in advance the names of the bundles then you could have an >> extender bundle which automatically starts any bundle with a >> Service-Component header. > > I can't use the config.ini as I really don't know the names of the > bundles in advance. That's why we start each serviceimpl bundle in the > corresponding service bundle. But in case I do not want to use DS our > second solution was to start all bundles whose names end with > xxxx.serviceimpl in a dedicated startUp-bundle. > > Kind regards, > Eugen > > > Am Apr 30, 2009 um 16:23 schrieb Neil Bartlett: > >> While I agree with Peter and Hal, I think the heart of your problem is >> the mismatch between the preferred lifecycles of bundles in Eclipse >> environment vs the services-based approach. >> >> In Eclipse (both the SDK and RCP apps), activation of bundles is done >> as late as possible. Lazy activation helps to ensure that Eclipse >> starts quickly, and code implementing things like views and buttons is >> only loaded when the user actually shows an interest in those things, >> e.g. by clicking the button. The whole Eclipse extension registry is >> set up to enable this by examining bundles when they are in the >> RESOLVED state. >> >> Services traditionally have a different lifecycle: they are offered up >> by a bundle before it knows whether any other component (or the user) >> actually wants them! So the bundle needs to be "eagerly" activated... >> but Eclipse strongly discourages this practice because bundle >> activation has an up-front cost. >> >> I believe the solution is to use Declarative Services. In DS, services >> can be registered in the service registry before the actual >> implementation object for the service is instantiated -- in fact, this >> is the default behaviour. A bundle offering services via DS still need >> to be activated, but now the activation is "free" because a >> classloader does not need to be created for the bundle until the >> service is actually used. >> >> To make this work in an Eclipse RCP environment, there are two >> possible approaches. First, explicitly name the bundles offering >> services in config.ini, and add the @start modifier. If you do not >> know in advance the names of the bundles then you could have an >> extender bundle which automatically starts any bundle with a >> Service-Component header. >> >> Regards, >> Neil >> >> >> >> On Thu, Apr 30, 2009 at 8:46 AM, Eugen Reiswich >> <[email protected]> wrote: >>> Hi OSGi-devs, >>> I have the following problem with osgi services. We develop basically >>> applications where dynamic is not an issue. So what I would like to >>> make >>> sure in my application is that all services are registred properly >>> at start >>> up - if not, the application will be shut down. In addition to that >>> I want >>> to reuse my bundles in RCP applications so any concept must also be >>> applicable for RCP applications. >>> Say I have two bundles: >>> 1. org.mycompany.service (contains a service interface) >>> 2. org.mycompany.serviceimpl (contains the service implementation and >>> registers withing his activator an osgi-service) >>> What we do within the service bundle is this: >>> public void start(BundleContext context) throws Exception { >>> Bundle[] bundles = context.getBundles(); >>> // find the implementation for the service bundle >>> for (Bundle bundle : bundles) { >>> if ("org.mycompany.serviceimpl".equals(bundle.getSymbolicName())) { >>> // service impl found >>> if (bundle.getState() != Bundle.ACTIVE) { >>> bundle.start(); >>> } >>> } >>> } >>> // check if servicimpl has registred service properly >>> ServiceReference serviceReference = context >>> .getServiceReference(IMyService.class.getName()); >>> if (serviceReference == null) { >>> // shut down application >>> } >>> ... >>> >>> >>> From my point of view this is pretty error prone and difficult to >>> maintain. >>> Is there a best practice approach how I can make sure that all >>> services are >>> registered properly at start up of my application? How can I start my >>> serviceimpl bundles in RCP application as no one depends on this >>> bundle >>> which is why the are never started? >>> We have spend now a lot of time to find solutions for this problem >>> but they >>> all seem to be improvable. >>> Regards, >>> Eugen >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
