Hi Sahoo,
thanx for the feedback and of course, you are correct. I fixed the
description of the reason for the ClassCastException.
It was about 04:00 AM in the night when I wrote that page. :)
Also, I was happy to file this improvement:
http://java.net/jira/browse/GLASSFISH-18854
Cheers,
Ancoron
On 06/28/2012 05:43 AM, Sahoo wrote:
> 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
>>
>