On Mar 12, 2009, at 10:02 AM, David Jencks wrote:
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way of comparing stuff which is pretty much limited to:
1. understand what the requirements are.
2. understand how the technologies support these requirements. I
do not need all the bells and whistles that a technology offers
to fulfill the requirements. Moreover comparing stuff based on
technology differentiators not clearly linked to the requirements
is pointless.
3. assess best way forward based on above scoring.
Key steps are 1 and 2 where stuff offering all the bells and
whistles may well be scored as good as other stuff (I clearly do
not support over-bloated stuff...).
Obviously, I am keen to be proven wrong and adjust accordingly.
So far, I am still saying that the main challenge is to properly
tune export/import of dependency declarations. For me, the
technology is not the core issue and switching is not going to
resolve problems.
I agree. I doubt Guillaume has seen your additions to
classloading in trunk which allow you to not export packages from
a classloader. I haven't tried to prove it mathematically but I
think that with this feature the classloading models for geronimo
and osgi are equivalent in that you can express the same ability
to access classes with either of them. Of course, the notation
you use to express this and the specific information included in
the configuration is different.
I think I probably have the most experience with classloading
problems in geronimo and the only real problem that arises is
loading a jar in two different classloaders. This can be solved
by a classloader-per-jar model which offers no theoretical
problems to set up in geronimo but practically would take a lot of
work (and maven projects to build a plugin per jar). So I think
we'll have to see what kind of problems we get with trying to
actually use OSGI.
Hi,
Thinking more about this, I believe we can expedite the
implementation of a classloader-per-jar model. Under the hood of a
MultiParentClassLoader we can replace the current implementation of
find class and resources contracts by an implementation which
delegates to a bunch of URLClassLoaders (one per jar). These bunch
of URLClassLoaders are global classloaders, i.e. shared across all
the configs/MultiParentClassLoaders. The core challenge is to
create them in a hierarchy respecting the maven dependency
declarations. So, we could install the pom of the dependencies in
the repo and lazily parse them when MultiParentClassLoader are
created to build this global and share tree of URLClassLoaders.
IMO the danger here is that the maven pom may not exist or may be
wrong. OSGI has the same problem in that the vast majority of
released jars don't have osgi manifests. I think I saw a rumor that
spring spent a lot of effort osgi-ifying a lot of commonly used jars
to try to solve this problem.
I also don't know if there are situations in which a small number of
closely related jars need to be loaded in a single classloader,
perhaps because one of the jars is "optional" but if present the
"main" jar needs access to its classes. I think there was an osgi
feature that looked sort of like this.
I just started to work on it and I will post back my findings (i
should be able to complete this over the week-end). Even if we
switch to an OSGi kernel, part of this work may hopefully still be
useful.
Unless you are pretty sure we won't have the kind of problems with
bad community metadata suggested above it might be a good idea to do
this in a sandbox branch?
Thinking about this more I really expect the code will be easy
compared to straightening out the dependencies :-(
As a concrete example, the JACC spec needs the servlet and ejb specs
but in our maven poms we've excluded them as dependencies so as to
make it easier to upgrade the jars independently. While (especially
with maven 3) we can probably put in the dependencies with version
ranges, they aren't there now. Getting the server to work again may
be time consuming. I really hope I'm wrong :-D
thanks
david jencks
thanks
david jencks
Thanks,
Gianny
One thing I'd really like actual user data on is how people
actually specify osgi classloading info in real life. I'm very
aware that in theory you are supposed to specify the package
imports and exports for your bundle but I've been told that in
real life everyone with a serious osgi project actually specifies
the jar dependencies they want using require-bundle.
thanks
david jencks
Thanks,
Gianny
On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote:
On Wed, Mar 11, 2009 at 08:57, Gianny Damour <[email protected]
> wrote:
Hi,
FWIW, I believe that improving the configuration style to
simplify the means of creating a bunch of objects in the kernel
has more benefits than swapping the classloading infra. On paper
OSGi may appear as superior from a classloading isolation
perspective; however, I believe the current CLing design is
nearly up to par with the OSGi one and that the main challenge
is to properly tune export/import dependency declarations.
I have to disagree with that. The CLing mechanism is very
different in Geronimo (from what I recall) and OSGi. Geronimo
uses a multi-parent classloader style with some nice features to
be able to hide / never override + parent or self-first
delegation.
OSGi CLind is very different: the first one is that you don't
really have parent classloaders: the classloader for a given
OSGi bundle is calculated wrt to the constraints expressed in
the OSGi manifest using imported packages or required bundles.
Let's take an example:
bundle A needs api packages from bundles B and C
implementation classes from bundle B and C needs something from
bundle D but with different versions
OSGi will be able to handle that because of non tree-like CLind
mechanism: if bundle A is wired to bundle B, it does not have to
see all the requirements from bundle B, and same for C.
Therefore, bundle A can be wired to both B and C without
problems because it will not see bundle D at all (so there's no
conflicts between the two versions of bundle D).
OSGi has a much more powerful CLing mechanism where you can
express lots of different constraints. The drawback is that
establishing the classloader can take a bit of time, so going to
OSGi most certainly leads to a big slowdown at startup while
creating the classloaders.
Also, OSGi does not really play nicely with the usual JEE way to
discover implementations through the MANIFEST/services entries.
That's kinda what we've tried to solve in servicemix specs,
though I'm not sure if that really applies everywhere because I
would imagine the classloaders for EARs are not really OSGi
classloaders ...
I certainly don't want to say OSGi is not the way to go, just
want to make the point that there are benefits but also drawbacks.
The JAXB approach to turn xml plans to a bunch of objects is
certainly interesting. I believe it is still a technology
limiting decision whereby a lot of custom code will have to be
implemented to support various style (factory methods or beans
et cetera) of configurations. I have been bouncing around this
idea a while back and here it is again. Why do we want to define
a XML language to create a bunch of objects when scripting can
do that for us?
I believe that xbean-spring is still unnecessary noisy when
compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder
).
If there is an interest in a scripting approach, then I can
investigate further.
Thoughts?
Thanks,
Gianny
On 11/03/2009, at 6:54 AM, David Jencks wrote:
So as mentioned below I'm starting to look into the osgi
classloading bit, sort of "from the bottom".
Another approach to many of these issues is perhaps "from the
top", from the point of view of going from a presumably xml plan
to a bunch of objects.
I've long thought that it must be possible to leverage jaxb to
do most of the heavy lifting here. In particular sxc is some
code we can presumably actually extend to do stuff like
constructor dependency injection. So another avenue that could
perhaps be approached in parallel would be to investigate sxc,
jaxb, xbean-spring, xbean-reflect, the blueprint service schema,
and jsr299 requirements and see what we can come up with.
For instance, it might be possible to have a large part of the
blueprint service functionality in jaxb-enabled objects that
jaxb instantiates from the xml. The "init" method could deal
with feeding the metadata into the blueprint service core.
Maybe we can get sxc to use xbean-reflect to create the objects.
So far this is more or less wild speculation in my head... but
I think it would be a lot of fun to investigate.
thanks
david jencks
On Mar 4, 2009, at 4:56 PM, David Jencks wrote:
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
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
