On 12/03/2009, at 5:26 AM, David Jencks wrote:
On Mar 11, 2009, at 12:57 AM, Gianny Damour 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.
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).
That looks nice, but is there any syntax validation possible? I'm
pretty much unwilling to use groovy for anything at this point due
to my bad experiences with lack of pre-runtime syntax validation
and unclear error messages writing some simple gshell commands.
xml is really horrible but most editors do support validation
against a schema.
This is the weakness but also the power of the approach whereby users
can mix arbitrary code and declarations. Syntax validation is pretty
much addressed by IDEs; however, only testing the script will prove
that it does what it is supposed to do. I do understand your
reticence thought and I will not insist.
On the other hand, I think we could come up with something even
shorter, clearer, and to the point, with syntax validation, using
scala.
This is an interesting idea. I am keen to see something more
streamlined and efficient than yet another XML approach to configure
a bunch of services in the kernel!
Thanks,
Gianny
thanks
david jencks
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
