Well BND is from my point of view not much better than configuring XML
files - it's also error prone. Maven is a quite powerful tool but the
problem of Declarative Services and XML will be just shifted from one
XML file to an other. The Service Activator Toolkit looks really nice
but it's demanding to much configuration at different parts of my
application (wizards, code etc.). I fear it will slow down our
development.
The situation is comparable with EasyMock and Mockito. EasyMock was an
already powerful mock framework but Mockito has spread pretty fast as
it is much easier to use. So far the Apache Felix Dependency Manager
seems to be most promising to me even if I don't like the idea of
extending a specific class in my BundleActivator. The dependency
configuration ist also not self describing and improveable. Hmm, maybe
I'm demanding too much but I really like the concepts of Mockito and I
think there can be something similar done with OSGi and dynamic
services - easy to use with less overhead and no XML or annotations.
Regards,
Eugen
Am Apr 15, 2009 um 15:05 schrieb Felix Meschberger:
Hi Eugen,
Eugen Reiswich schrieb:
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!
Yes, XML is like hell ;-)
For this reason, we have a Maven 2 plugin [1] (if you happen to use
maven), which allows you to convert JavaDoc tags (not annotations
(yet))
into the correct DS descriptors. Quite nice. The advantage is, that
you
have the declaration and the code in the same place and don't need to
maintain two separate files/locations.
Another option would be to use Peter Kriens' BND tool [2]. This jar
file
contains an ant task and also an Eclipse plugin and it allows to
specify
the DS descriptors in a bnd descriptor which is not XML (but has its
own
format).
HTH
Regards
Felix
[1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
[2] http://www.aqute.biz/Code/Bnd
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
