Ah! I'd been using Dom.unwrap(). I should've thought of looking at
ConfigBean since listener is a ConfigBeanProxy...
Jerome Dochez wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>