geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: OSGI progress
Date Wed, 23 Sep 2009 09:02:36 GMT
2009/9/23 Rex Wang <rwonly@gmail.com>

>
>
> 2009/9/23 Ivan <xhhsld@gmail.com>
>
>>
>>
>> 2009/9/23 David Jencks <david_jencks@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 <rwonly@gmail.com>
>>>
>>>> Yes! hope for detail sharing :-)
>>>> -Rex
>>>>
>>>> 2009/9/22 Jack Cai <greensight@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>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

Mime
View raw message