from the "this" object, you can unwrap the ConfigBean instance and the
habitat from there, so
public static ThreadPool findThreadPool(final NetworkListener
listener) {
ConfigBean bean = Configbean.unwrap(listener);
Habitat habitat = bean.getHabitat();
...
}
jerome
On Apr 23, 2009, at 1:32 PM, Justin Lee wrote:
> So is there a nice way to get at the Habitat inside that duck typed
> method? I could pass it in from the caller I suppose but I dislike
> passing stuff like that around. The only other choice I can see
> involves reflection which I like even less. Is there a nice hk2
> approach I'm missing or should I just pass in the Habitat?
>
> Jerome Dochez wrote:
>>
>> On Apr 23, 2009, at 11:39 AM, Justin Lee wrote:
>>
>>> I think I might already have a duck typed method for fetching
>>> those from a NetworkListener. That should help from the outside,
>>> but tracking down where those live might still be tricky.
>>>
>> right I just saw that method findThreadPool().
>>
>> I think your idea seems worth trying, get the habitat and do a
>> getAllByType and then iterate until your find the right name...
>>
>>> Is this a milestone 2 issue? or should it wait until the build is
>>> blessed?
>> you can wait until the build is blessed but considering the
>> AdminGui will not be capable of handling threadpools under network-
>> config, we should fix it for J1
>>>
>>> Jerome Dochez wrote:
>>>> a few duck typed methods might help you there, grizzly should
>>>> only go through the duck typed methods to retrieve the threadpool
>>>> information. The duckType method would do the necessary lookups...
>>>>
>>>> On Apr 23, 2009, at 11:18 AM, Justin Lee wrote:
>>>>
>>>>> Given that the same code would be used at runtime in glassfish
>>>>> as is used in grizzly to process those ThreadPool objects, that
>>>>> could get messy. I'll see what I can do with things like
>>>>> @Inject or getByContractType to help hide the structural
>>>>> differences. A little disappointing to have to support
>>>>> disparate schemas like that. I'll see what I can do, though.
>>>>> Is this required for the milestone 2 build?
>>>>>
>>>>> Jerome Dochez wrote:
>>>>>> So I interacted this morning with a few people and it seems we
>>>>>> are getting towards the consensus that we should leave the
>>>>>> threadpool where they used to be.
>>>>>>
>>>>>> The ThreadPool.java can stay in the grizzly-config module, the
>>>>>> thread-pool element under network config should be used in the
>>>>>> grizzly standalone use case.
>>>>>>
>>>>>> We should have an upgrade service that moves any threadpool
>>>>>> definition from network-config to the config element so that if
>>>>>> people just copy/paste the grizzly config from a standalone
>>>>>> config to a glassfish installation, we will still recognize
>>>>>> those entries and upgrade them accordingly.
>>>>>>
>>>>>> GlassFish runtime should only use threadpool under config like
>>>>>> in previous releases.
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> On Apr 22, 2009, at 9:28 PM, Jerome Dochez wrote:
>>>>>>
>>>>>>> Kedar Mhaswade wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Jerome Dochez wrote:
>>>>>>>>>
>>>>>>>>> On Apr 22, 2009, at 3:52 PM, Kedar Mhaswade wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jerome Dochez wrote:
>>>>>>>>>>> I understand that part. I am confused why it can't be in
>>>>>>>>>>> both places (under network-config for grizzly) and under
>>>>>>>>>>> config for the rest)
>>>>>>>>>>
>>>>>>>>>> Won't we then need additional qualification for create/
>>>>>>>>>> delete/list
>>>>>>>>>> thread-pool commands so they can disambiguate between the
>>>>>>>>>> thread-pool
>>>>>>>>>> under <config> against <network-config>?
>>>>>>>>> by that, you mean different admin commands ? yes they would
>>>>>>>>> need that although I suppose a parameter on the existing
>>>>>>>>> admin command could suffice to disambiguate.
>>>>>>>>
>>>>>>>> Right. We would need that, although it might be rather clumsy
>>>>>>>> and would
>>>>>>>> relate the "structure" of domain.xml which we want to avoid
>>>>>>>> from getting
>>>>>>>> exposed to asadmin. Would you say something like:
>>>>>>>>
>>>>>>>> asadmin create-thread-pool --traffic [iiop/http/tcp ...] my-
>>>>>>>> uber-thread-pool?
>>>>>>> something like that if we feel it is becoming necessary
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Or are you saying that their
>>>>>>>>>> ID's must be unique across elements?
>>>>>>>>> depends what the referencing elements expect. I suppose we
>>>>>>>>> could enforce that uniqueness across elements.
>>>>>>>>
>>>>>>>> Not sure.
>>>>>>>> <config>
>>>>>>>> <thread-pools>
>>>>>>>> <thread-pool id="id1" .../>
>>>>>>>> </thread-pools>
>>>>>>>> ...
>>>>>>>> <network-config>
>>>>>>>> <thread-pool id="id2" .../>
>>>>>>>> </network-config>
>>>>>>>> </config>
>>>>>>>>
>>>>>>>> It would be rather awkward to say that /config/thread-pools/
>>>>>>>> thread-pool[i]@id
>>>>>>>> and /config/network-config/thread-pool[i]@id need to be unique.
>>>>>>> yeah but then the referencing would need to be change to
>>>>>>> indicated which threadpool type is being referenced.
>>>>>>>
>>>>>>> another possibility is that thread-pool under network config
>>>>>>> would only be used in glassfish standalone while we would only
>>>>>>> use thread-pool under config.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> at the end, I find it a bit strange that in the normal
>>>>>>>>> appserver case, we would define our threadpools under
>>>>>>>>> network config. I understand this is needed for standalone
>>>>>>>>> grizzly but should that have ripple effects in glassfish is
>>>>>>>>> undesirable imo.
>>>>>>>>
>>>>>>>> I agree. But isn't the plan that all listeners and thread-
>>>>>>>> pools move under
>>>>>>>> network-config? That's the reason I thought we should move
>>>>>>>> iiop-listener
>>>>>>>> too under network-config. Since the http-listeners have
>>>>>>>> already moved under
>>>>>>>> <network-config> maybe iiop-listeners should move too.
>>>>>>> I am not sure that was a decision, certainly I would like to
>>>>>>> get Siva's opinion on that matter. I suppose that for the time
>>>>>>> being, we can leave it under network-config and revisit it
>>>>>>> with the right quorum.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> jerome
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -Kedar
>>>>>>>>>>
>>>>>>>>>>> On Apr 22, 2009, at 3:33 PM, Justin Lee wrote:
>>>>>>>>>>>> We just filed this https://grizzly.dev.java.net/issues/show_bug.cgi?id=557
>>>>>>>>>>>> to make a little more semantic sense. ThreadPool
>>>>>>>>>>>> elements have to live somewhere under NetworkConfig at a
>>>>>>>>>>>> minimum for grizzly-config to be usable in grizzly
>>>>>>>>>>>> standalone.
>>>>>>>>>>>>
>>>>>>>>>>>> Jerome Dochez wrote:
>>>>>>>>>>>>> I am a bit confused as well. I understand the ThreadPool
>>>>>>>>>>>>> configured interface went into the grizzly-config
>>>>>>>>>>>>> module, however I don't understand why there would be a
>>>>>>>>>>>>> reference from iiop-listeners to threadpools defined in
>>>>>>>>>>>>> network-listeners.
>>>>>>>>>>>>>
>>>>>>>>>>>>> jerome
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 22, 2009, at 1:37 PM, Justin Lee wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> No other questions/complaints? Can I commit this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Justin Lee wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kedar Mhaswade wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK. Thanks.
>>>>>>>>>>>>>>>> So the plan is iiop-listeners stay wherever they are,
>>>>>>>>>>>>>>>> but will reference
>>>>>>>>>>>>>>>> thread-pools from under network-listeners?
>>>>>>>>>>>>>>> Correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Does it make more sense then to make ORB initialize
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> convenient network-listeners and deprecate the iiop-
>>>>>>>>>>>>>>>> listener(s) element(s)?
>>>>>>>>>>>>>>> I could go either way on this one. As I understand
>>>>>>>>>>>>>>> it, though, the ORB code needs a much different thread
>>>>>>>>>>>>>>> pool than, say, HTTP processing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I guess we will need a blanket compatibility waiver
>>>>>>>>>>>>>>>> for affected dotted names.
>>>>>>>>>>>>>>> There's a request for this in already, actually.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Kedar
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Kedar
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Justin Lee wrote:
>>>>>>>>>>>>>>>>>>> Attached are the diffs for integrating the new
>>>>>>>>>>>>>>>>>>> version of grizzly-config that should hopefully
>>>>>>>>>>>>>>>>>>> fix the open issues against it. There is also a
>>>>>>>>>>>>>>>>>>> fix for a test that broke from the grizzly-config
>>>>>>>>>>>>>>>>>>> merge last week.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-
>>>>>>>>>> unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>