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: domain of berger.max@gmail.com designates
 209.85.220.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:x-enigmail-version:openpgp:content-type;
        b=aJaxXoqZxCk++F5LisbW+CIvkVucfNvn1f6dKcm1D/4a5iFK9T9lJU9tzaw70R/XUB
         7v9THwPkx2tpikROh/oY9Q8mlcVWIjkxc57+mIgibxLdKs62FZVdNipMuFz2wazGgQat
         yU4REZneJSWTvnaYkyoNo7XyribUnSh9Oy6aI=
Sender: Max Berger <berger.max@gmail.com>
Message-ID: <4AFBDF72.1030704@berger.name>
Date: Thu, 12 Nov 2009 11:12:02 +0100
From: Max Berger <max@berger.name>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: general@xmlgraphics.apache.org
Subject: Re: Running XML Graphics products on OSGi
References: <20091103165741.F1B6.60BA733C@jeremias-maerki.ch>
In-Reply-To: <20091103165741.F1B6.60BA733C@jeremias-maerki.ch>
OpenPGP: id=C93C5700
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig079AE068EBA73ECBC3A6D617"

--------------enig079AE068EBA73ECBC3A6D617
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Jeremias,

a late reply, but hopefully still valid:

- 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.

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

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

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

Max


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
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700


--------------enig079AE068EBA73ECBC3A6D617
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr733UACgkQHr98CTDagb8wnACfd1uPCzcLuEkZhwihs4/9rzm6
iYUAn2I7zzCCKMSpGq9XsYd9V2KImvTS
=fGl0
-----END PGP SIGNATURE-----

--------------enig079AE068EBA73ECBC3A6D617--