On 02/23/2012 05:12 PM, Tom Mueller wrote:
>
>
> On 2/22/2012 7:39 PM, 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
>>
>> On Thursday 23 February 2012 12:39 AM, Ancoron Luciferis wrote:
>>> Hi devs,
>>>
>>> I'm currently implementing some asadmin sub-commands and need some
>>> help with issues that I face:
>>>
>>> 1.) I the add-on developer guide I read that I should put the HK2 jar
>>> under .../glassfish/modules/. Well, I violated this and instead put
>>> it under .../autodeploy/bundles/ and it still works. Nice so far. Now
>>> comes the issue: my commands need some OSGi services that I provide
>>> dynamically (or not) and depending on availability the commands do
>>> different things or just don't. What I started with was the HK2
>>> @Inject annotation as it seemed to inject my OSGi services just fine.
>>> However, if I update one of those other services I get something like
>>> this:
>>>
>>> ClassCastException: $Proxy489 cannot be cast to <interface>
>>>
>>> As far as I understand the use of HK2 in GlassFish I though that it
>>> would build on top of OSGi or am I wrong here?
>>>
>>> Anyway, is there a way to fix this (my implementations are always
>>> marked as @PerLookup - assuming it does injection also at every
>>> instance creation). Also I assumed that the habitat would get updated
>>> with new OSGi services.
>>>
>>>
>>> 2.) I also observed that I cannot "update" such an HK2-jar. The OSGi
>>> part seems to get updated but not the HK2 part. How can I trigger this?
>>>
>>>
>>> 3.) One of my sub-commands trigger something on another OSGi service
>>> asynchronously and I implemented a callbackhandler-like
>>> infrastructure (using OSGi-events) to get notified of the work being
>>> done. Now this might take quite some time and I wanted to output
>>> those notifications back to the console. This part, however doesn't
>>> seem to work as I always get all output at the very end in one big
>>> batch. Also, I sometimes run into the timeout that grizzly seems to
>>> apply for the internal HTTP requests. So, is it possible to "stream"
>>> the output?
> Incremental output from a command is not currently supported by the
> GlassFish admin command framework.
> We are working on a progress status feature, but even that will not
> support incremental content output.
>
> Tom
>
Thank you for that info. So, I thought about this a bit more and I think
it makes much more sense then to either use JAX-RS or even a bare
servlet for this purpose.
Thanx,
Ancoron
>>>
>>> That's what I did back in the good old Servlet days.
>>>
>>>
>>> Thanx for any pointers and help,
>>>
>>> Ancoron
>>