Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of kevan.miller@gmail.com
 designates 209.85.210.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:mime-version:content-type:subject:date:in-reply-to:to
         :references:message-id:x-mailer;
        b=xeEdVJRvkxqRMxwkxL8ZGH2U+myJqDiwgK8MkzEfIAMGTf23dZGm4B6ymIlvb9XnMF
         x0IFbZl3zguQcPNpHrDyz3Qj2JEfqmAEU4BpQlD08q4/FM3sKVodpQ+CdzalKg/f07/h
         Xr1iZyp2jtBVumkic568Jy7FtQNtFt1zbM7l0=
From: Kevan Miller <kevan.miller@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-418--886868715
Subject: Re: shared lib in Geronimo 3.0
Date: Wed, 24 Mar 2010 20:48:27 -0400
In-Reply-To: <606EB8DF-FD79-4DB1-8AE7-97EDB7C22B8E@yahoo.com>
To: dev@geronimo.apache.org
References: <99d1baac1003240920h28d98d56mdc3e1dd8d351eb63@mail.gmail.com>
  <D2D8E56C-96A3-4AE3-978D-CC2BC390CE77@yahoo.com>
 <99d1baac1003241258n4a62ad50p18ce1de66ef32384@mail.gmail.com>
 <2B745234-9739-4806-9F5C-197D3B59989D@yahoo.com>
 <BB95690C-87E8-4A59-8C8B-6F05AEE8796A@gmail.com>
 <606EB8DF-FD79-4DB1-8AE7-97EDB7C22B8E@yahoo.com>
Message-Id: <7254CF4F-E288-4400-987B-D441388A5F37@gmail.com>


--Apple-Mail-418--886868715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Mar 24, 2010, at 5:30 PM, David Jencks wrote:

>=20
> While I always thought shared lib was a bad idea, at least pre-osgi =
the concept of a classloader that you could just toss things in made =
sense.  I don't think it makes any sense in osgi.  There is no =
dynamic-export header so whatever implementation you came up with would =
have to know exactly what packages to export... making the idea of =
adding more stuff to it useless.  If you just make sure your jar is =
bundleized so the packages you want to use are exported, and install the =
bundle in the osgi framework, the osgi wiring mechanism will take care =
of making it available to your app, in a simpler, uniform way that is =
much more flexible than shared lib was.
>=20
> In other words, plain vanilla osgi all by itself does what shared lib =
was for much much better.  The only inconvenience is that you have to =
make your libraries into bundles somehow.  We can certainly talk about =
how to help people do that, but that will be generally useful and/or =
impossible to do well.

Understood. And I'm not claiming that we'd end up with the same runtime =
efficiencies of a common shared lib ClassLoader, in previous versions of =
Geronimo. However, we're processing WARs and EARs with packaged jar =
files. And we'd better be pretty good at that. And we're certainly not =
going to require users to convert these jars into bundles. So, is =
extending this capability to a sharedlib dirctory (outside of the =
archive) such a big stretch? It might not be as runtime efficient as it =
could be, but a class of users might well appreciate its simplicity.

We also want to be making it easy for users to bundleize jars and =
incorporate them into Geronimo. However, I'm not convinced that users =
should always be required to bundlize their jars...

--kevan


--Apple-Mail-418--886868715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Mar 24, 2010, at 5:30 PM, David Jencks =
wrote:</div><br><blockquote type=3D"cite"><div><br>While I always =
thought shared lib was a bad idea, at least pre-osgi the concept of a =
classloader that you could just toss things in made sense. &nbsp;I don't =
think it makes any sense in osgi. &nbsp;There is no dynamic-export =
header so whatever implementation you came up with would have to know =
exactly what packages to export... making the idea of adding more stuff =
to it useless. &nbsp;If you just make sure your jar is bundleized so the =
packages you want to use are exported, and install the bundle in the =
osgi framework, the osgi wiring mechanism will take care of making it =
available to your app, in a simpler, uniform way that is much more =
flexible than shared lib was.<br><br>In other words, plain vanilla osgi =
all by itself does what shared lib was for much much better. &nbsp;The =
only inconvenience is that you have to make your libraries into bundles =
somehow. &nbsp;We can certainly talk about how to help people do that, =
but that will be generally useful and/or impossible to do well.<font =
class=3D"Apple-style-span" color=3D"#006312"><font =
class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></font></div></blockquote><br></div><div>Unde=
rstood. And I'm not claiming that we'd end up with the same runtime =
efficiencies of a common shared lib ClassLoader, in previous versions of =
Geronimo. However, we're processing WARs and EARs with packaged jar =
files. And we'd better be pretty good at that. And we're certainly not =
going to require users to convert these jars into bundles. So, is =
extending this capability to a sharedlib dirctory (outside of the =
archive) such a big stretch? It might not be as runtime efficient as it =
could be, but a class of users might well appreciate its =
simplicity.</div><div><br></div><div>We also want to be making it easy =
for users to bundleize jars and incorporate them into Geronimo. However, =
I'm not convinced that users should always be required to bundlize their =
jars...</div><div><br></div><div>--kevan</div><br></body></html>=

--Apple-Mail-418--886868715--