If you use BND to generate your bundles you can let BND generate the DS
files. For example, this line in the bnd file
Service-Component: \
com.acme.MyComponent;otherService=\
com.acme.other.OtherService
will generate this XML file:
<?xml version='1.0' encoding='utf-8'?>
<component name='com.acme.MyComponent'>
<implementation class='com.acme.MyComponent'/>
<reference name='otherService'
interface='com.acme.other.OtherService'
bind='setOtherService' unbind='unsetOtherService'
/>
</component>
BND will reference the created XML correctly from the manifest
(Service-Component header).
Docs: http://www.aqute.biz/Code/Bnd
HTH,
Roman
Eugen Reiswich wrote:
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]
<mailto:[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] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Cheers, Stuart
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[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
