Stuart, David, thanks for the quick response.
I've already had a look at Declarative Services but I don't like the
idea of configuring my application with XML-files. I've been working
for some time with Spring thus I have seen the XML-hell. It took me
about 3 hours to get a simple example run with Declarative Services (I
hope there will be a better IDE support for DS in the near future).
But what looks really interesting ist the Apache Felix Dependency
Manager. Thanks a lot!
Regards,
Eugen
Am Apr 15, 2009 um 13:48 schrieb Stuart McCulloch:
2009/4/15 Eugen Reiswich <[email protected]>
Hi folks,
I'm developing applications which are based on OSGi. In 80%-90% of
my time I don't use the hot plugging ability of OSGi but rather the
component and service based development possibilities. Even though I
don't need the hot plugging ability I need to use the cumbersomely
SerivceTracker to retrieve my services. It was a pain to write a
ServiceTracker with addingService() and removedService() methods
for each service even though each ServiceTracker is almost doing
the same stuff.
So I decided to look for a better solution. From my point of view
the Spring Dynamic Modules approach is just to heavy weighted and to
handle all those XML-files is a different pain. Afterwards I found
an approach called "Peaberry" but this approach depends on
annotations which have other disadvantages.
yes, both XML and annotations have their pros and cons - actually
with Guice / peaberry
you can use XML to configure bindings (by scraping the XML and
calling the builder API
directly) but you'd still need to annotate your injection points...
although I should mention the Guice build shipped with peaberry 1.1
can support injection
listeners, which means you can implement other injection strategies
like EJB @Resource:
http://code.google.com/p/google-guice/issues/detail?id=258#c42
http://code.google.com/p/guiceyfruit (example use of listeners)
but this feature still needs to be documented on the Guice wiki and
must be used carefully :)
At the end of the day I wrote my own Dependency-Injection approach
which is based on OSGi. I would like to ask you whether there is
something similar to this so I don't need to reinvent the wheel again.
there are a few other service injection approaches with low overhead:
Declarative Services - OSGi standard, several implementations,
uses XML to configure
http://www.eclipsezone.com/eclipse/forums/t96740.html (good
introduction)
Apache Felix iPOJO - supports both XML and annotations,
flexible, uses bytecode manipulation
http://felix.apache.org/site/apache-felix-ipojo.html
Apache Felix Dependency Manager - Java builder API, a bit similar
to your current approach
http://felix.apache.org/site/apache-felix-dependency-manager.html
HTH - hopefully there's something out there that matches your needs
Here's the code how I do inject a service.
private ServiceTracker _tracker;
private AccountManagerImpl _accountManager;
public void start(BundleContext context) throws Exception {
_accountManager = new AccountManagerImpl();
/*
* This does create a ServiceTracker for the given service. When
addingService(...) or removedService(...) methods are called, the
appropriate bindXYZService(...) and unbindXYZService(...) methods
are called on the given object (_accountManager).
*/
_tracker = bindService(IAccountService.class,
context).toObject(_accountManager);
_tracker.open();
}
// The serviceTracker is closed within the stop-Method
public void stop(BundleContext context) throws Exception {
_tracker.close();
}
I expect the _accountManager to have a "bind"-Method with
IAccountService as a parameter:
public void bindAccountService(IAccountService accountService) {
_accountService = accountService;
}
I would really appreciate if someone could help me to solve my
problem.
Cheers,
Eugen
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Cheers, Stuart
_______________________________________________
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
