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
>