On Jan 8, 2010, at 9:55 AM, Jarek Gawor wrote:
David,
Just a thought. We could "extend" the WAB manifest but generating and
attaching a fragment bundle to the it with the additional imports,
etc.
I guess this would work, but it seems ugly.
Anyway, is the reference you were thinking of a symbolic name or
bundle id or something else that gets resolved via service registry?
This wasn't clear to me from your description but we could add some
kind of namespace or id into the gbean data and use that to find a
service in the service registry that can handle that gbean. And at
this point this is pretty much the same as what Blueprint does with
the namespace handlers.
So effectively, module builders work would map to generating Blueprint
XML and instantiating the gbeans to Blueprint extender work with the
right set of namespace handlers.
What I have so far, and appears to be working, is to add a new field
to GBeanData
private Artifact classSource
If this is set, then GBeanInstance uses it to find the Configuration
gbean, gets the Bundle from it, and uses it to load the gbean class.
IIUC the blueprint feature you are talking about is setRuntimeClass on
BeanMetadata (or one of its subclasses). While there are definite
lifecycle differences between what I have and the blueprint feature
the idea is pretty much identical.
What I have is definitely geronimo-centric and is restricted to
"depending on" plugins rather than arbitrary bundles, however this
seems more or less reasonable to me considering that we are using
gbeans.
thanks
david jencks
Jarek
On Thu, Jan 7, 2010 at 1:50 PM, David Jencks
<[email protected]> wrote:
There's been some back channel discussion about what might be
needed to
support stuff like osgi rfc 66 web bundles in geronimo. One
problem that
appears with our current idea of setting up gbeans to "be" the web
app is
that for a WAB we can't modify the manifest to import the gbean
classes.
Also, our current scheme makes the framework classes (jetty or
tomcat
implementation classes) visible to the app.
One possible solution is to add another GBeanData field which is a
reference
to the plugin that has the gbean's class. Then the web (or other)
deployer
can add all its gbeans with this field set to the appropriate
runtime plugin
whose bundle can load the gbean class, and the web app bundle won't
need to
import the classes itself.
It looks pretty easy to modify GBeanData and GBeanInstance to do
this. It
should be easy but time consuming to modify the module builders as
well.
With this approach to gbeans, we might be able to support a web
extender
that, when given a WAB, checked for an existing config.ser-like
file and if
missing ran the geronimo module builder to create it.
I'll start looking into this..... comments would be extremely
welcome.
thanks
david jencks
