On Sep 23, 2009, at 3:35 AM, Rick McGuire wrote:
David Jencks wrote:
On Sep 22, 2009, at 10:50 PM, Ivan wrote:
After reading some code changes of the geronimo-kenel in the
sanbox, I found that we keep the Geronimo kenel as an OSGI
service, and each Configuration ( or a bundle) will search it and
start the configuration as we do in the past while starting.
There's a difference in lifecycles between osgi bundles and
geronimo configurations.
OSGI:
bundles can be installed, in which case the classes are not
available, or started, in which case the classes are all available
and the bundle activator has been started. AFAICT there is no
other built in "no-really-start-it" state beyond "started". There
might be more less-started states I'm not aware of.
The extender model sort or introduces an additional state (or at
least the Blueprint extender does). After STARTED state, the
extender kicks in and processes metadata in the bundle and performs
additional actions. The completion point is when the
BlueprintContainer service is published to the service registry. At
that point, the bundle state is "complete". Something similar might
make sense for a configuration, where a "ConfigurationContainer"
service is published to the registry that would allow additional
configuration operations to be performed.
I think people have outlined two options here. I don't know if either
of them would actually work well in practice:
1. map the "resolved" bundle state to "classes available + gbean
metadata available", and the "started" bundle state to "all the gbeans
started". I _think_ a bundle listener is notified when a bundle is
resolved, we could write a bundle listener to look up and register the
gbean metadata in the kernel. This is now done in the
ConfigurationActivator. The ConfigurationActivator start would then
start all the gbeans. Alternatively we could use a bundle listener to
start all the gbeans.
2. map the "started" bundle state to "classes available and gbean
metadata available, but gbeans not started" and have a further state
of "gbeans started" under the control of something else, perhaps
similar to the blueprint extender. This is closer to what I've
implemented so far.
The real reason we have these two configuration staties is that we
generally need access to the gbean metadata in order to deploy javaee
applications to make sure the gbean references will be satisfied at
runtime (there's also some further use for j2ca connector metadata,
but we miight be able to find an alternate way to deal with this). We
don't want to force you to start up a whole server with opening all
the server ports just to build a plugin for a web app.
So far I think this is a useful capability so I'd like to try to find
a way to implement it in osgi. Alternatively we could abandon the
idea of building plugins for javaee apps that are "predeployed apps"
that should just work and go to more of a "find the problems at
runtime" model.
We won't be able to tell how well this stuff works until we get to
making the deployers work in osgi. The stuff in framework doesn't
really have enough contact with the outside world through server ports
to show up problems with any of these approaches.
thanks
david jencks
Geronimo:
A Configuration is a gbean. You can't get much usefaul data out of
it until its started. Once it is started the classes are available
and you can find out what services (gbeans) are in the
configuration and look at their attributes. There's a further
state of "all gbeans started". The configuration manager treats
these states as "loaded" and "started"
Again, this maps fairly well to the model used by Blueprint
extender. The Configuration gbean could be published to the
registry once it reaches the "all gbeans started" state.
So far it seems to work to do something similar in the osgi
environment but it doesn't really fit very well yet. I'm not sure
where we will end up with this.
I have a feeling that, if we do that, Geronimo is still a part of
OSGI env, could we make the Geronimo is an OSGI env?
I don't understand what you are asking here. In the sandbox,
geronimo plugins are running in an osgi enviroment, and all the
classes are loaded from osgi bundles. Could you explain more what
you are asking about?
Could we publish GBeans as OSGI service via a
ConfigurationActivator, or though a GBean-OSGI adapter ?
I'm pretty sure we could, but I'd like to get more stuff working
before we decide if its a good idea. IIUC blueprint doesn't
publish every blueprint bean as an osgi service, but only ones you
configure to be published. I suspect we may want to, similarly,
only publish some gbeans as osgi services.
Your understanding is correct. Only the explicitly identified beans
are published as services. I suspect this would likely make sense
within a configuration context as well.
My current approach is to try to modify the existing geronimo
architecture relatively little where possible to get it to run in
osgi, respecting osgi architecture. So, I am trying to get stuff
working with the kernel as an osgi service, get the deployers
working, etc etc. I think after we have done this we will have a
much better idea what other work we want to try. For instance, we
might not need a kernel at all: possibly gbeans can just be osgi
services with a few extra attributes.
thanks
david jencks
Thanks !
2009/9/22 Rex Wang <rwo...@gmail.com <mailto:rwo...@gmail.com>>
Yes! hope for detail sharing :-)
-Rex
2009/9/22 Jack Cai <greensi...@gmail.com
<mailto:greensi...@gmail.com>>
David, that's exciting work!
It'll be great if you can share some more details. There are
a few puzzles that flow around my mind -
* Are we just taking OSGi framework in as another plug-in to
let it host OSGi applications? Or, vice-versa, we are
converting Geronimo into an OSGi application?
* If the latter case, will GBean go away?
* If yes, how much code changes are required? I'd say a
lot ...
-Jack
On Tue, Sep 22, 2009 at 8:25 AM, David Jencks
<david_jen...@yahoo.com <mailto:david_jen...@yahoo.com>>
wrote:
Over the weekend I got my sandbox osgi framework to build
and generate all the plugins as osgi bundles. This
involves running some of the geronimo server on
osgi/felix inside maven. The dependency management
system seems to work OK at least for starting bundles. I
also started doing a little bit of code cleanup.
I think the next step will be to get the framework server
running in standalone karaf or felix. Hopefully this
will be no harder than getting it running in embedded
felix in maven.
thanks
david jencks
--
Ivan
