dev@glassfish.java.net

Re: [how-to] Dynamic asadmin sub-commands - was: Custom asadmin sub-command questions

From: Sahoo <sanjeeb.sahoo_at_oracle.com>
Date: Thu, 28 Jun 2012 09:13:07 +0530

Good work. I have a slight disagreement with your analysis of
ClassCastException. It may just be the way you have put it down rather
than how you have analysed it in your mind.

It didn't occur /"because the class-loader for the execution of the
AdminCommand have not been updated and still point to the old ones,"/
but because the HK2 service registry (so called Habitat) still had the
old HK2 Service type corresponding to OSGiServiceCommand. The old class
obviously referenced an earlier version of SomeService.class and used it
to cast the new ServiceImpl that it received from OSGi service registry.
When you updated the bundle, yet another service got registered under
the same name, but since the names matched, Habitat used the old
OSGiServiceCommand.class. It should be possible to improve the
housekeeping of the Habitat to remove service entries for a removed
bundle and that would meet a number of simple use cases including the
one you are demonstrating. File a bug.

Thanks,
Sahoo

On Thursday 28 June 2012 07:20 AM, Ancoron Luciferis wrote:
> Hi Sahoo, hi devs,
>
> just wanted to let you know that I've found some time again to finally
> finish this little thing.
>
> Now it's easier than ever to get an AdminCommand online and behaving
> like some OSGi service:
>
> https://github.com/ancoron/gf-samples/wiki/Dynamic-GlassFish-asadmin-sub-commands
>
>
>
> Cheers,
>
> Ancoron
>
>
> On 02/23/2012 09:52 AM, Sahoo wrote:
>> On Thursday 23 February 2012 02:11 PM, Ancoron Luciferis wrote:
>>> On 02/23/2012 09:18 AM, Sahoo wrote:
>>>> On Thursday 23 February 2012 01:31 PM, Ancoron Luciferis wrote:
>>>>> On 02/23/2012 02:39 AM, Sahoo wrote:
>>>>>> No, HK2 does not handle bundle removal or updation very well. It can
>>>>>> handle new bundles getting installed at runtime. So, don't update
>>>>>> your
>>>>>> hk2-jar at runtime; instead shutdown the system and restart. It's
>>>>>> not a
>>>>>> bug in HK2/OSGi bridge. I doubt we are going to address this - it
>>>>>> requires deep changes in HK2 to refresh its internal objects when
>>>>>> bundles get removed/updated.
>>>>>>
>>>>>> I don't know about the streaming to the console part. That seems
>>>>>> like a
>>>>>> question for admin folks.
>>>>>>
>>>>>> Sahoo
>>>>>
>>>>> Hi Sahoo,
>>>>>
>>>>> thank you for the insight.
>>>>>
>>>>> As a workaround, would it be possible to (un-)register HK2
>>>>> services in
>>>>> a programmatic way from OSGi bundles, e.g. using an activator or an
>>>>> extender?
>>>>>
>>>> You have two choices:
>>>> a) You can use Habitat object to unregister/register yourself HK2
>>>> service.
>>>> b) You could also expose your service as OSGi service with a
>>>> component.name service property (set this to the name that you use
>>>> while
>>>> using looking up the HK2 service) and let it be automatically
>>>> added/removed to/from the HK2 service registry as a named HK2 service.
>>>>
>>>> Sahoo
>>>
>>> Ah, thanx again. That's what I was hoping for. :)
>>>
>>> Btw. what's the best way to retrieve the habitat?
>>>
>> @Inject Habitat or look it up in OSGi Service registry.
>>
>> Sahoo
>