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 xhhsld@gmail.com designates
 209.85.198.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Na9+8MToOPmn97wufaGxvTVkzylUw792Ba1f6lm4BvIQtGiHynl8KuWvco+tXswDDt
         Lxm6W0JXNhDmOPI2DNtqP/rU0FiDTH/aUp2nuU+wbw9zVel4bWlwWGs0F+W3yBIfFHNC
         eT9bGCTYAIVQ2byrIMKSMO96akDVVrMzMoSnw=
MIME-Version: 1.0
In-Reply-To: <ED9C8D11-4250-41EF-ACFA-426F0D1B176E@yahoo.com>
References: <ED9C8D11-4250-41EF-ACFA-426F0D1B176E@yahoo.com>
Date: Thu, 5 Mar 2009 15:21:17 +0800
Message-ID: <45f744e40903042321g34d6c21dx882e404f56d98a23@mail.gmail.com>
Subject: Re: Whence the geronimo kernel?
From: Ivan <xhhsld@gmail.com>
To: dev@geronimo.apache.org
Content-Type: multipart/alternative; boundary=000e0cd214d29ea6d804645a03ab

--000e0cd214d29ea6d804645a03ab
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It is a good idea.
I encounter some similar issues about the multiparent classloader. From the
pom.xml, currently, it is hard to know which jar is in the classpath. The
dependies between the configurations are also too complex, I notice that the
restart/reload codes in the configurationManager is very very ...
Maybe we could replace all the codes in the configurationManager, and just
delegate it to the OSGI module/lifecycle layer.
Thanks !


2009/3/5 David Jencks <david_jencks@yahoo.com>

> Geronimo has been around for a while and despite the many good features
> gbeans and the geronimo kernel are not catching on big time.  I think we
> want to consider taking action now to avoid ending up being dragged down by
> supporting a dead container.  Here are a few thoughts.
>
> Actual problems with geronimo:
> - gbeans are too restrictive.  It's too hard to instantiate other peoples
> components as gbeans.  GBeans don't support common patterns like factory
> methods, factory beans, etc etc, and require the component to be
> instantiated directly by the gbean framework.
> - it's too hard to get the classloaders to work.  The most common problem
> is a class cast exception due to loading the same jar in two plugins.
>  NoClassDefFound errors from an optional jar in a child classloader are also
> really annoying.
>
> Really good things about geronimo I haven't seen elsewhere (at least in one
> place):
> - gbean dependencies work across plugins.  Dependencies are a unified
> system, not per-plugin.
> - gbean dependencies are resolved in the ancestors of a plugin, not server
> wide.  This means that you can't make a partially specified dependency
> ambiguous by deploying additional plugins.  I consider this an extremely
> important feature for predictability.
> - plugin dependencies allow assembly of a server from the explicit
> dependencies which are normally the same as the maven dependencies.
>
> Other projects and specs that have stuff we should look into:
> maven.  Maven has a lot better infrastructure for dealing with dependency
> resolution from partial transitive dependency specification than we do.  We
> should look into using more of their infrastructure.
> osgi. osgi has a lot of similarities to geronimo. The osgi classloading
> model is getting a lot of people excited.  The import-bundle idea is pretty
> much the same as our classloader model where every jar is a plugin.  I don't
> know if people are really using the allegedly recommended method of
> specifying imports and exports and letting the osgi runtime figure out where
> they come from; this seems worth investigating to me. Also, we get periodic
> inquiries about when we are going to support osgi and the was ce folks get
> even more.
> osgi blueprint service (rfc 124) This appears to be a simple wiring
> framework for a single plugin.  IIUC it uses the osgi service registry for
> component dependencies between bundles.
> xbean-spring.  I'd be reluctant to try to implement a blueprint service
> that didn't provide the xbean-spring capabilities really well
> ee6 dependency injection.  EE6 is going to have a pretty sophisticated
> dependency injection service which we'll need to support anyway.  We should
> try to figure out how much of the core we can assemble using it.
>
> Other great stuff we have:
> xbean-reflect, xbean-finder, xbean-spring
>
>
> These ideas have been floating around in my head for a long time and I've
> chatted with various people about them occasionally.   While more discussion
> is certainly needed on everything here I need to do some implementation to
> understand much more.  So, what I'm planning to do:
>
> Dave's crazy work plan...
> - Try to use the osgi classloader.  I think this involves putting the
> classloader creation in Configuration into a service.  Configurations will
> turn into osgi bundles.  I'll put the Kernel in the osgi ServiceRegistry so
> the Configuration bundle activator should be able to use it to resolve
> cross-plugin dependencies.
> - try to figure out how maven dependency resolution fits into osgi.
> - see if eclipse p2 is relevant for provisioning geronimo repositories
>
> at this point I think geronimo would be running on osgi, still using
> gbeans.
>
> - look into relaxing the gbean framework so it is more plugin-at-a-time
> rather than gbean-at-a-time
> - see how that differs from the blueprint service, ee DI, and xbean-spring.
>  Try to support all of these at once.
>
> Thoughts? Counter proposals?  Anyone interested?
>
> many thanks
> david jencks
>
>


-- 
Ivan

--000e0cd214d29ea6d804645a03ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is a good idea.<br>I encounter some similar issues about the multiparent=
 classloader. From the pom.xml, currently, it is hard to know which jar is =
in the classpath. The dependies between the configurations are also too com=
plex, I notice that the restart/reload codes in the configurationManager is=
 very very ...<br>
Maybe we could replace all the codes in the configurationManager, and just =
delegate it to the OSGI module/lifecycle layer.<br>Thanks ! <br><br><br><di=
v class=3D"gmail_quote">2009/3/5 David Jencks <span dir=3D"ltr">&lt;<a href=
=3D"mailto:david_jencks@yahoo.com">david_jencks@yahoo.com</a>&gt;</span><br=
>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Geronimo has been=
 around for a while and despite the many good features gbeans and the geron=
imo kernel are not catching on big time. =A0I think we want to consider tak=
ing action now to avoid ending up being dragged down by supporting a dead c=
ontainer. =A0Here are a few thoughts.<br>

<br>
Actual problems with geronimo:<br>
- gbeans are too restrictive. =A0It&#39;s too hard to instantiate other peo=
ples components as gbeans. =A0GBeans don&#39;t support common patterns like=
 factory methods, factory beans, etc etc, and require the component to be i=
nstantiated directly by the gbean framework.<br>

- it&#39;s too hard to get the classloaders to work. =A0The most common pro=
blem is a class cast exception due to loading the same jar in two plugins. =
=A0NoClassDefFound errors from an optional jar in a child classloader are a=
lso really annoying.<br>

<br>
Really good things about geronimo I haven&#39;t seen elsewhere (at least in=
 one place):<br>
- gbean dependencies work across plugins. =A0Dependencies are a unified sys=
tem, not per-plugin.<br>
- gbean dependencies are resolved in the ancestors of a plugin, not server =
wide. =A0This means that you can&#39;t make a partially specified dependenc=
y ambiguous by deploying additional plugins. =A0I consider this an extremel=
y important feature for predictability.<br>

- plugin dependencies allow assembly of a server from the explicit dependen=
cies which are normally the same as the maven dependencies.<br>
<br>
Other projects and specs that have stuff we should look into:<br>
maven. =A0Maven has a lot better infrastructure for dealing with dependency=
 resolution from partial transitive dependency specification than we do. =
=A0We should look into using more of their infrastructure.<br>
osgi. osgi has a lot of similarities to geronimo. The osgi classloading mod=
el is getting a lot of people excited. =A0The import-bundle idea is pretty =
much the same as our classloader model where every jar is a plugin. =A0I do=
n&#39;t know if people are really using the allegedly recommended method of=
 specifying imports and exports and letting the osgi runtime figure out whe=
re they come from; this seems worth investigating to me. Also, we get perio=
dic inquiries about when we are going to support osgi and the was ce folks =
get even more.<br>

osgi blueprint service (rfc 124) This appears to be a simple wiring framewo=
rk for a single plugin. =A0IIUC it uses the osgi service registry for compo=
nent dependencies between bundles.<br>
xbean-spring. =A0I&#39;d be reluctant to try to implement a blueprint servi=
ce that didn&#39;t provide the xbean-spring capabilities really well<br>
ee6 dependency injection. =A0EE6 is going to have a pretty sophisticated de=
pendency injection service which we&#39;ll need to support anyway. =A0We sh=
ould try to figure out how much of the core we can assemble using it.<br>
<br>
Other great stuff we have:<br>
xbean-reflect, xbean-finder, xbean-spring<br>
<br>
<br>
These ideas have been floating around in my head for a long time and I&#39;=
ve chatted with various people about them occasionally. =A0 While more disc=
ussion is certainly needed on everything here I need to do some implementat=
ion to understand much more. =A0So, what I&#39;m planning to do:<br>

<br>
Dave&#39;s crazy work plan...<br>
- Try to use the osgi classloader. =A0I think this involves putting the cla=
ssloader creation in Configuration into a service. =A0Configurations will t=
urn into osgi bundles. =A0I&#39;ll put the Kernel in the osgi ServiceRegist=
ry so the Configuration bundle activator should be able to use it to resolv=
e cross-plugin dependencies.<br>

- try to figure out how maven dependency resolution fits into osgi.<br>
- see if eclipse p2 is relevant for provisioning geronimo repositories<br>
<br>
at this point I think geronimo would be running on osgi, still using gbeans=
.<br>
<br>
- look into relaxing the gbean framework so it is more plugin-at-a-time rat=
her than gbean-at-a-time<br>
- see how that differs from the blueprint service, ee DI, and xbean-spring.=
 =A0Try to support all of these at once.<br>
<br>
Thoughts? Counter proposals? =A0Anyone interested?<br>
<br>
many thanks<br><font color=3D"#888888">
david jencks<br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Ivan<br>

--000e0cd214d29ea6d804645a03ab--