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
>