felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniele Dellafiore <dani...@dellafiore.net>
Subject Re: A better life: quick webapp deploy
Date Tue, 10 May 2011 15:37:22 GMT
On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <peter.kriens@aqute.biz>wrote:

> In OSGi the idea is that you get a bunch of bundles that collaborate
> through services. The bundle is a module and is therefore supposed to be
> impenetrable. Just like a class has private fields so does a bundle have
> private classes and resources. It would not be very modular if you could use
> the XML from other bundles, this Spring XML is supposed to be an
> implementation detail of the bundle. As long as you do the collaboration
> with services you can use many different techniques: Spring, DS, iPOJO,
> dependency manager, etc.
>

Another way to say is that I use the XML from other bundles as I use a class
from another bundle, I do not see any violation here.
A spring xml is an implementation detail? For me is like a class, nothing
more, I load it using <import> like instantiate a class with a new.

Example.
If I've defined some beans that manage storage and search in a bundle A and
want to load them in a bundle B changing just some properties (database
connections and some search tuning), the only way I know now, in OSGI, is to
copy-paste the spring XML into bundle A, cause import classpath*: does not
work.
Copy paste is always bad so I figure out that alternatives are:

1. importing beans from bundle A in the  context of B, using a sort of
osgi:classpath
2. exporing those beans as osgi services, but as long that properties are
chosen by bundle B, I need something more sophisticated like
ManagedServiceFactory to get a new instance with the actual parameters. I've
never dig into that but it seems to be the case. This solution, that I do
not find easy, is OSGI specific while I'd like to stay on spring and avoid
to couple with OSGI mechanism
3. i can raise the level of abstraction. If I need a DatabaseTemplate
configured with some property that definese database connection, i can
export as osgi service a DatabaseTemplateFactory from bundle B and ask the
template to the factory from A. But here I loose advantages of spring IOC:
in my classes I will have an instance of the factory, and I've to ask for a
new class everytime and who keeps the control that the new template instance
is a singleton now?
4. bundle A do the persistence and that's it. I export a DatabaseTemplate
that can write on different databases, and I tell which one using a
parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
works on OSGI).

Maybe is not that important but sometime it happens I have a bundle that
offer some classes. In a typical app that use that bundle, one or more
classes are candidate to become spring beans, in every app that will use the
classes. So I provide a ready to use spring xml so that you do not need to
copy-paste the spring definition but you can just import the file as a
resource.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message