You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2009/09/22 02:25:00 UTC
OSGI progress
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
Re: OSGI progress
Posted by Jarek Gawor <jg...@gmail.com>.
I was just looking at David's framework code and it looks like there
is already a way to inject a bundle or bundleContext into a gbean. It
works just like injecting the kernel or classLoader attributes. I'm
just looking at the code at this point so I don't really know if it
works right or not.
Jarek
On Wed, Sep 30, 2009 at 1:47 PM, Rick McGuire <ri...@gmail.com> wrote:
> I've been looking into how to create an RFC 66 implementation that can
> deploy to whatever the Geronimo-hosted web container happens to be. One
> issue that seems to keep popping up is crossing the bridge between GBeans
> and OSGi. A lot (ok, all really) that deal with the server runtime and
> configuration are GBean instances. Some of these GBeans will occasionally
> need a BundleContext to perform OSGi operations. It would appear that we'd
> need to have an mechanism to allow a GBean to be injected with a Bundle
> and/or BundleContext for its hosting configuration.
> Rick
>
Re: OSGI progress
Posted by David Jencks <da...@yahoo.com>.
On Sep 30, 2009, at 10:47 AM, Rick McGuire wrote:
> I've been looking into how to create an RFC 66 implementation that
> can deploy to whatever the Geronimo-hosted web container happens to
> be. One issue that seems to keep popping up is crossing the bridge
> between GBeans and OSGi. A lot (ok, all really) that deal with the
> server runtime and configuration are GBean instances. Some of these
> GBeans will occasionally need a BundleContext to perform OSGi
> operations. It would appear that we'd need to have an mechanism to
> allow a GBean to be injected with a Bundle and/or BundleContext for
> its hosting configuration.
That's implemented and appears to be working in my osgi sandbox. One
of the tasks I envision once the g. framework actually boots up inside
karaf is converting all the gbeans that use the magic classloader
attribute to use bundle context instead.
Currently I'm fighting with a classcast exception deep in plexus that
I managed to avoid a couple weeks ago but its popped up again. There
are a lot of jars that need to be bundleized and a bunch of problems
in the servicemix bundleizations.... I may be making some progress
however.
thanks
david jencks
> Rick
>
> 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.
>>
>> 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"
>>
>> 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.
>>
>> 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 <rwonly@gmail.com <ma...@gmail.com>>
>>>
>>> Yes! hope for detail sharing :-)
>>> -Rex
>>>
>>> 2009/9/22 Jack Cai <greensight@gmail.com
>>> <ma...@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_jencks@yahoo.com <ma...@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
>>
>
Re: OSGI progress
Posted by Rick McGuire <ri...@gmail.com>.
I've been looking into how to create an RFC 66 implementation that can
deploy to whatever the Geronimo-hosted web container happens to be. One
issue that seems to keep popping up is crossing the bridge between
GBeans and OSGi. A lot (ok, all really) that deal with the server
runtime and configuration are GBean instances. Some of these GBeans
will occasionally need a BundleContext to perform OSGi operations. It
would appear that we'd need to have an mechanism to allow a GBean to be
injected with a Bundle and/or BundleContext for its hosting configuration.
Rick
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.
>
> 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"
>
> 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.
>
> 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 <rwonly@gmail.com <ma...@gmail.com>>
>>
>> Yes! hope for detail sharing :-)
>> -Rex
>>
>> 2009/9/22 Jack Cai <greensight@gmail.com
>> <ma...@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_jencks@yahoo.com <ma...@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
>
Re: OSGI progress
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Sep 23, 2009 at 08:25, David Jencks <da...@yahoo.com> 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.
OSGi has the following states for bundles:
* Installed
* Resolved
* Started
Resolved means the classes are available and Started means the
activator has been started. Of course, we have Started > Resolved.
But Resolved might be what you were looking for.
> 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"
> 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.
> 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 <rw...@gmail.com>
>>
>> Yes! hope for detail sharing :-)
>> -Rex
>>
>> 2009/9/22 Jack Cai <gr...@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 <da...@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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGI progress
Posted by Rex Wang <rw...@gmail.com>.
2009/9/23 Quintin Beukes <qu...@skywalk.co.za>
> >>
> >>
> >> What I mean is that, currently, Geronimo kernel is running in the
> OSGI
> >> environment, and all those GBeans are running in the kernel. I would
> like
> >> to see that the OSGI is Geronimo kernel. As you said in the comments
> below,
> >> we might not need a kernel at all :-)
> >>
> > Yes. I hope so.
> >
>
> I'm trying to follow what you guys are saying, because it sounds very
> interesting. I might be misunderstanding what the Geronimo Kernel is
> exactly. If I understand this correctly, ie. the kernel provides
> services, won't it make it difficult to then "replace" the kernel? If
> the kernel is a bundle, it can be uninstalled/reinstalled, and provide
> it's services? Similar to other OSGi environments, ex. Eclipse IDE.
> The OSGi environment loads the IDE core as a bundle. Eclipse IDE core
> isn't the OSGi. The actual "OSGi" in OSGi implementations is merely
> the engine for managing/loading/activating bundles and services, and
> if you keep to the spec should be nothing more than this?
>
> AFAIK, Eclipse only using OSGi framework to do the classloading, however
that is only one of the feature OSGi can provide. (Maybe there are some
improves in the new eclipse release.)
>From my point of view, ideally, Future Geronimo will be a bunch of extenders
of OSGi framework(such as web container extender, blueprint extender..).
Deploying a war is actually to deploy a web bundle into OSGi framework. If
we have enough extenders on our hand, which implement the whole Java EE
features, then we can claim that geronimo comply the Java EE spec.
However, currently, OSGi EEG is still busy on making RFCs and RIs, so there
is not enough parts to assemble a Java EE server for us. Then that might be
the stuffs we are working on, that is, we are try to build an
appliation(geronimo kernel) based on OSGi framework which can provide a
pipeline to the external world, such as openejb....
*Above is just my personal view*
-Rex
Q
>
Re: OSGI progress
Posted by Quintin Beukes <qu...@skywalk.co.za>.
>>
>>
>> What I mean is that, currently, Geronimo kernel is running in the OSGI
>> environment, and all those GBeans are running in the kernel. I would like
>> to see that the OSGI is Geronimo kernel. As you said in the comments below,
>> we might not need a kernel at all :-)
>>
> Yes. I hope so.
>
I'm trying to follow what you guys are saying, because it sounds very
interesting. I might be misunderstanding what the Geronimo Kernel is
exactly. If I understand this correctly, ie. the kernel provides
services, won't it make it difficult to then "replace" the kernel? If
the kernel is a bundle, it can be uninstalled/reinstalled, and provide
it's services? Similar to other OSGi environments, ex. Eclipse IDE.
The OSGi environment loads the IDE core as a bundle. Eclipse IDE core
isn't the OSGi. The actual "OSGi" in OSGi implementations is merely
the engine for managing/loading/activating bundles and services, and
if you keep to the spec should be nothing more than this?
Q
Re: OSGI progress
Posted by Ivan <xh...@gmail.com>.
2009/9/23 Rex Wang <rw...@gmail.com>
>
>
> 2009/9/23 Ivan <xh...@gmail.com>
>
>>
>>
>> 2009/9/23 David Jencks <da...@yahoo.com>
>>
>>>
>>> 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.
>>>
>>> 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"
>>>
>>> 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 not considered the detailed implmentation, by intuition, the
>> Configuration in the old Geronimo Arch is a bundle in OSGI, while starting
>> the bundle, the bundleActivator will start all the gbean defintions it has.
>> I know that Configuration is only a gbean, even if it is in running state,
>> it does not mean that all the sub gbeans are in the running state, maybe, as
>> Guillanume said, we could think that the resolved state means that the
>> Configuration GBean itself has been successfully in the running state.
>>
>>>
>>>
>> The "Installed/Resolved/Started" is the states of a bundle, not a specific
> java bean. You can not re-define what "resolved" mean in your design.
>
I do not mean to redefine the resolved status, as David said, Geronimo and
OSGI's lifecycle have a slight difference, we may need to do some mapping
between them
Just releaize that the resolve is an internal process of the OSGI
framework, no way to do a Configuration GBean start :-(
> 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?
>>>
>>>
>>
>> What I mean is that, currently, Geronimo kernel is running in the OSGI
>> environment, and all those GBeans are running in the kernel. I would like
>> to see that the OSGI is Geronimo kernel. As you said in the comments below,
>> we might not need a kernel at all :-)
>>
>> Yes. I hope so.
>
> -Rex
>
>> 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.
>>>
>>> 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 <rw...@gmail.com>
>>>
>>>> Yes! hope for detail sharing :-)
>>>> -Rex
>>>>
>>>> 2009/9/22 Jack Cai <gr...@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 <da...@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
>>>
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
--
Ivan
Re: OSGI progress
Posted by Rex Wang <rw...@gmail.com>.
2009/9/23 Ivan <xh...@gmail.com>
>
>
> 2009/9/23 David Jencks <da...@yahoo.com>
>
>>
>> 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.
>>
>> 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"
>>
>> 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 not considered the detailed implmentation, by intuition, the
> Configuration in the old Geronimo Arch is a bundle in OSGI, while starting
> the bundle, the bundleActivator will start all the gbean defintions it has.
> I know that Configuration is only a gbean, even if it is in running state,
> it does not mean that all the sub gbeans are in the running state, maybe, as
> Guillanume said, we could think that the resolved state means that the
> Configuration GBean itself has been successfully in the running state.
>
>>
>>
> The "Installed/Resolved/Started" is the states of a bundle, not a specific
java bean. You can not re-define what "resolved" mean in your design.
> 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?
>>
>>
>
> What I mean is that, currently, Geronimo kernel is running in the OSGI
> environment, and all those GBeans are running in the kernel. I would like
> to see that the OSGI is Geronimo kernel. As you said in the comments below,
> we might not need a kernel at all :-)
>
> Yes. I hope so.
-Rex
> 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.
>>
>> 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 <rw...@gmail.com>
>>
>>> Yes! hope for detail sharing :-)
>>> -Rex
>>>
>>> 2009/9/22 Jack Cai <gr...@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 <da...@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
>>
>>
>>
>
>
> --
> Ivan
>
Re: OSGI progress
Posted by Ivan <xh...@gmail.com>.
2009/9/23 David Jencks <da...@yahoo.com>
>
> 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.
>
> 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"
>
> 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 not considered the detailed implmentation, by intuition, the
Configuration in the old Geronimo Arch is a bundle in OSGI, while starting
the bundle, the bundleActivator will start all the gbean defintions it has.
I know that Configuration is only a gbean, even if it is in running state,
it does not mean that all the sub gbeans are in the running state, maybe, as
Guillanume said, we could think that the resolved state means that the
Configuration GBean itself has been successfully in the running state.
>
>
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?
>
>
What I mean is that, currently, Geronimo kernel is running in the OSGI
environment, and all those GBeans are running in the kernel. I would like
to see that the OSGI is Geronimo kernel. As you said in the comments below,
we might not need a kernel at all :-)
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.
>
> 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 <rw...@gmail.com>
>
>> Yes! hope for detail sharing :-)
>> -Rex
>>
>> 2009/9/22 Jack Cai <gr...@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 <da...@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
>
>
>
--
Ivan
Re: OSGI progress
Posted by David Jencks <da...@yahoo.com>.
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 <rwonly@gmail.com <ma...@gmail.com>>
>>>
>>> Yes! hope for detail sharing :-)
>>> -Rex
>>>
>>> 2009/9/22 Jack Cai <greensight@gmail.com
>>> <ma...@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_jencks@yahoo.com <ma...@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
>>
>
Re: OSGI progress
Posted by Rick McGuire <ri...@gmail.com>.
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.
>
> 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 <rwonly@gmail.com <ma...@gmail.com>>
>>
>> Yes! hope for detail sharing :-)
>> -Rex
>>
>> 2009/9/22 Jack Cai <greensight@gmail.com
>> <ma...@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_jencks@yahoo.com <ma...@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
>
Re: OSGI progress
Posted by David Jencks <da...@yahoo.com>.
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.
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"
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.
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 <rw...@gmail.com>
> Yes! hope for detail sharing :-)
> -Rex
>
> 2009/9/22 Jack Cai <gr...@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
> <da...@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
Re: OSGI progress
Posted by Ivan <xh...@gmail.com>.
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. 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? Could we
publish GBeans as OSGI service via a ConfigurationActivator, or though a
GBean-OSGI adapter ?
Thanks !
2009/9/22 Rex Wang <rw...@gmail.com>
> Yes! hope for detail sharing :-)
> -Rex
>
> 2009/9/22 Jack Cai <gr...@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 <da...@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
Re: OSGI progress
Posted by Rex Wang <rw...@gmail.com>.
Yes! hope for detail sharing :-)
-Rex
2009/9/22 Jack Cai <gr...@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 <da...@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
>>
>>
>
Re: OSGI progress
Posted by Jack Cai <gr...@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 <da...@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
>
>
Re: OSGI progress
Posted by Quintin Beukes <qu...@skywalk.co.za>.
I learned OSGi while implementing Felix. Was a good place to start.
The Felix docs wasn't that good in introducing OSGi (at the time at
least) and consisted mostly of example tutorials on implementing the
basic OSGi models, though a little bit of logical thought with them
got me into starting an OSGi based application in little under an
hour.
Further, try reading the docs on the OSGi alliance web site. IIRC
there were some OSGi introductions that weren't as involved as the
spec itself, which helped clear up some questions I had during this
development.
You could give these a try.
Quintin Beukes
On Wed, Sep 23, 2009 at 11:39 PM, Jay D. McHugh <ja...@gmail.com> wrote:
> So it sounds like I can't put off learning OSGi anymore :)
>
> Does anyone have suggested resources (books, websites, or tutorials)
> that they found useful?
>
> Thanks in advance,
>
> Jay
>
> David Jencks 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
>>
>
Re: OSGI progress
Posted by "Jay D. McHugh" <ja...@gmail.com>.
So it sounds like I can't put off learning OSGi anymore :)
Does anyone have suggested resources (books, websites, or tutorials)
that they found useful?
Thanks in advance,
Jay
David Jencks 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
>