Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: A better life: quick webapp deploy
From: Peter Kriens <peter.kriens@aqute.biz>
In-Reply-To: 
 <1726621934.142537.1305044784792.JavaMail.root@sz0116a.westchester.pa.mail.comcast.net>
Date: Fri, 13 May 2011 17:41:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B350BEE9-BCE7-4D7B-871C-873A7E525E72@aQute.biz>
References: 
 <1726621934.142537.1305044784792.JavaMail.root@sz0116a.westchester.pa.mail.comcast.net>
To: users@felix.apache.org

right ... that is the way to go ... modularize and share via the service =
registry.

Kind regards,

	Peter Kriens

On 10 mei 2011, at 18:26, mvangeertruy@comcast.net wrote:

>=20
>=20
> Danielle,=20
>=20
>=20
>=20
> What you are trying to do is best accomplished by using services.  In =
my application, we have a database connection and JMS connections that =
are used by multiple bundles.  So, for my database connection (since =
that's what we're talking about), I created my bundle, and then in the =
context file that uses the osgi and osgix namespaces, I simple attached =
the bundle to the service registry.  Then any other bundle that needed =
to consume the database connection was able to grab a reference to the =
database service from the service registry, and then inject it via the =
database connections interface.=20
>=20
>=20
>=20
> v/r,=20
>=20
>=20
>=20
> Mike Van=20
>=20
>=20
> ----- Original Message -----=20
> From: "Daniele Dellafiore" <daniele@dellafiore.net>=20
> To: users@felix.apache.org=20
> Sent: Tuesday, May 10, 2011 11:37:22 AM=20
> Subject: Re: A better life: quick webapp deploy=20
>=20
> On Tue, May 10, 2011 at 3:17 PM, Peter Kriens =
<peter.kriens@aqute.biz>wrote:=20
>=20
>> In OSGi the idea is that you get a bunch of bundles that collaborate=20=

>> through services. The bundle is a module and is therefore supposed to =
be=20
>> impenetrable. Just like a class has private fields so does a bundle =
have=20
>> private classes and resources. It would not be very modular if you =
could use=20
>> the XML from other bundles, this Spring XML is supposed to be an=20
>> implementation detail of the bundle. As long as you do the =
collaboration=20
>> with services you can use many different techniques: Spring, DS, =
iPOJO,=20
>> dependency manager, etc.=20
>>=20
>=20
> Another way to say is that I use the XML from other bundles as I use a =
class=20
> from another bundle, I do not see any violation here.=20
> A spring xml is an implementation detail? For me is like a class, =
nothing=20
> more, I load it using <import> like instantiate a class with a new.=20
>=20
> Example.=20
> If I've defined some beans that manage storage and search in a bundle =
A and=20
> want to load them in a bundle B changing just some properties =
(database=20
> connections and some search tuning), the only way I know now, in OSGI, =
is to=20
> copy-paste the spring XML into bundle A, cause import classpath*: does =
not=20
> work.=20
> Copy paste is always bad so I figure out that alternatives are:=20
>=20
> 1. importing beans from bundle A in the  context of B, using a sort of=20=

> osgi:classpath=20
> 2. exporing those beans as osgi services, but as long that properties =
are=20
> chosen by bundle B, I need something more sophisticated like=20
> ManagedServiceFactory to get a new instance with the actual =
parameters. I've=20
> never dig into that but it seems to be the case. This solution, that I =
do=20
> not find easy, is OSGI specific while I'd like to stay on spring and =
avoid=20
> to couple with OSGI mechanism=20
> 3. i can raise the level of abstraction. If I need a DatabaseTemplate=20=

> configured with some property that definese database connection, i can=20=

> export as osgi service a DatabaseTemplateFactory from bundle B and ask =
the=20
> template to the factory from A. But here I loose advantages of spring =
IOC:=20
> in my classes I will have an instance of the factory, and I've to ask =
for a=20
> new class everytime and who keeps the control that the new template =
instance=20
> is a singleton now?=20
> 4. bundle A do the persistence and that's it. I export a =
DatabaseTemplate=20
> that can write on different databases, and I tell which one using a=20
> parameter or some more sophisticated mechanism (ThreadLocal? wonder =
how it=20
> works on OSGI).=20
>=20
> Maybe is not that important but sometime it happens I have a bundle =
that=20
> offer some classes. In a typical app that use that bundle, one or more=20=

> classes are candidate to become spring beans, in every app that will =
use the=20
> classes. So I provide a ready to use spring xml so that you do not =
need to=20
> copy-paste the spring definition but you can just import the file as a=20=

> resource.=20


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org