Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 12 Nov 2009 11:41:24 +0100
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: general@xmlgraphics.apache.org
Subject: Re: Running XML Graphics products on OSGi
In-Reply-To: <4AFBDF72.1030704@berger.name>
References: <20091103165741.F1B6.60BA733C@jeremias-maerki.ch>
 <4AFBDF72.1030704@berger.name>
Message-Id: <20091112112933.DA06.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Max

On 12.11.2009 11:12:02 Max Berger wrote:
> Jeremias,
>=20
> a late reply, but hopefully still valid:
>=20
> - If you use OSGi, you will either need to implement a simplified
> version for detecting plug-ins, or introduce additional dependencies
> (apache felix). Both would increase the size of xmlgraphics-commons, so
> should be carefully considered.

Yes, there will be an increase of classes necessary to handle this (-1
Services.java in XGC, and 1+ JAR of 28KB (15 classes)), but no, there
won't be a dependency on Apache Felix or any other OSGi specific class
in XGC. That's what my abstraction layer is all about: shielding
FOP/Batik from OSGi-specifics but enabling them to run in an OSGi
environment.

> - at least until fop 1.0 plug-ins written using the service approach
> should still be loaded.

My abstraction layer is designed to be a complete replacement of the
Services class but in terms of plug-in handling almost nothing changes.
The META-INF/service is still used as before. Instead of getting an
iterator with all plug-in classes you set up a simple listener which
gets notified if a plug-in becomes available or goes away. I don't
propose to suddenly use OSGi services at all. This whole thing will
still work completely without a single OSGi or Felix class in the
classpath for the big majority of users who still don't use OSGi.

> - I like the OSGi approach as it is currently widely used.

Not as widely as you might think. Otherwise, people would have come
screaming for OSGi metadata in FOP a long time ago. But yeah, OSGi is
very cool and adoption is spreading fast.

> As an idea: If you submit your code to apache felix maybe they could
> produce some kind of "felix lite" version, which would be the minimal
> osgi environment needed to replace the current "Service" class? This
> would remove my first point above

I think with my above comments I've already addressed that, but without
the need for a "Felix lite".

> Max
>=20
>=20
> Jeremias Maerki schrieb:
> > Over the past few months, I've started to get FOP, Batik and Commons
> > running in an OSGi environment. The first easy step is to just add the
> > necessary metadata to the manifest. However, that is not enough in the
> > case here. The problem: we're using the JAR Service Provider mechanism
> > from the JAR specification (META-INF/services directory in the JARs).
> >=20
> > OSGi doesn't have a hierarchical class loader setup like traditional
> > Java applications which is why FOP, for example, may not see all
> > available plug-ins anymore if they are not compiled together into a
> > monster-JAR.
> >=20
> > The solution was to build an abstraction layer above the direct access
> > to the META-INF/services files. In an OSGi-environment, a special
> > component (a so-called extender) will watch all available bundles (=3DJ=
ARs)
> > in the application. If it finds plug-ins it make them available despite
> > the class loader isolation. Well, that's simply the executive summary.
> > In the end, this is a replacement for the "Services" class in XML
> > Graphics Commons which we use today.
> >=20
> > Anyway, I've published today an initial version of that abstraction
> > layer on my website [1]. I've started locally to change XML Graphics
> > Commons, so Commons can see the ImageConverter plug-ins provided by FOP
> > in an OSGi environment. With that alone I've already been able to run
> > FOP & Batik in OSGi. I'll have to do more of the same for all other
> > extension points. That means changes to all three products (including
> > Batik). Also, extension authors will have to make their plug-ins
> > OSGi-capable if they want their extensions to work in an OSGi
> > environment.
> >=20
> > I'm going to wait a bit before proposing any patches. I first want to
> > get some feedback on the abstraction layer from the Felix community
> > where I've also posted the link. Felix might be one possible location
> > where this thing could be maintained. Since it also works completely
> > without OSGi, Apache Commons could be another option. That should be
> > sorted out in the following weeks. I just wanted to let everyone know
> > that this is something I would like to address in the near future.
> >=20
> > If you want to know what OSGi is, take a quick look on the Wikipedia
> > page [2]. If you're an Eclipse user, you're already working on OSGi,
> > even though you may not even know.
> >=20
> > [1] http://www.jeremias-maerki.ch/development/osgi/jar-services.html
> > [2] http://en.wikipedia.org/wiki/OSGi
> >=20
> >=20
> >=20
> > Jeremias Maerki
>=20
>=20
>=20
> --=20
> http://max.berger.name/
> OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700
>=20


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org