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
>