ah in grizzly standalone it does yes...
ok I need to move the API to Dom then...
jerome
On Apr 23, 2009, at 4:45 PM, Justin Lee wrote:
> I spoke too soon. ConfigBean.unwrap(listener) returns a Dom.
> Anything else I should try?
>
> java.lang.ClassCastException: org.jvnet.hk2.config.Dom cannot be
> cast to org.jvnet.hk2.config.ConfigBean
> at com.sun.grizzly.config.dom.NetworkListener
> $Duck.findThreadPool(NetworkListener.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:817)
> at org.jvnet.hk2.config.Dom.invoke(Dom.java:775)
> at $Proxy11.findThreadPool(Unknown Source)
> at
> com
> .sun
> .grizzly
> .config.GrizzlyEmbeddedHttp.configure(GrizzlyEmbeddedHttp.java:259)
> at
> com
> .sun
> .grizzly
> .config
> .GrizzlyServiceListener
> .initializeListener(GrizzlyServiceListener.java:91)
> at
> com
> .sun
> .grizzly
> .config.GrizzlyServiceListener.configure(GrizzlyServiceListener.java:
> 77)
> at
> com.sun.grizzly.config.GrizzlyConfig.setupNetwork(GrizzlyConfig.java:
> 80)
> at
> com
> .sun
> .grizzly
> .config.GrizzlyConfigTest.processConfig(GrizzlyConfigTest.java:29)
>
>
> Justin Lee wrote:
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>