Hi Clement,
this is almost it! I guess it will be difficult to use strings like
"myFoo" and "start" in larger applications as methods are renamed
pretty often (even if you check the box "Update textual
occurrences..." while renaming). So there is some effort needed to
keep the strings and methods in sync. I have contacted the Apache
Felix DM guys to discuss this issue further.
Regards,
Eugen
Am Apr 15, 2009 um 16:48 schrieb Clement Escoffier:
Hi,
As mentioned by Stuart, iPOJO proposes you several way to configure
your components:
- XML (ok, it seems that it's not really what you want)
- Annotations [http://felix.apache.org/site/how-to-use-ipojo-annotations.html
]
- API (close to the dependency manager one) [http://felix.apache.org/site/apache-felix-ipojo-api.html
]
If you're interested by the API, here is a small example of a
service consumer:
Your class is quite simple, nothing else is required:
public class MyComponentImpl {
private Foo myFoo; // This is a service dependency
public void start() {
myFoo.doSomething(); // You use the service
}
}
And here is the definition of the component:
new PrimitiveComponentType()
.setBundleContext(context)
.setClassName(MyComponentImpl.class.getName())
.addDependency(new Dependency().setField("myFoo"))
.setValidateMethod("start")
.createInstance();
This latter snipper can be used in your bundle activator or anywhere
(as soon as you have the Bundle Context).
Regards,
Clement
On 15.04.2009, at 16:35, Eugen Reiswich wrote:
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
_______________________________________________
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
