On Thu, Apr 30, 2009 at 4:00 PM, Eugen Reiswich <[email protected]> wrote: > 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.
Actually, you can put as many <component> elements in one file as you like. They don't even have to be at the top level -- you can embed them as deep as you like in some other XML, for example the Eclipse plugin.xml if you like. I don't know if the DS tooling supports this ability yet, however. I tend to use a straightforward XML editor currently because the DS tooling is rather immature (I will certainly take another look at it in M7 though). > 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. Right. Or you could even define your own custom header in the manifest. In regard to Shailendra's suggestion of using start levels, I strongly recommend that you DON'T do this. Introducing start-order dependencies into your application very quickly leads to extreme fragility, and eventually a circular ordering problem that you can't solve! As an approach it can seem very appealing but it just does not scale. Regards, Neil > > 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
