I suppose that in grizzly standalone you don't really care about
transactional access, read only proxies and listener events. If so you
can stay with you current solution.
I am in the process of promoting a new hk2, which will give you access
to the habitat from the Dom instance.
jerome
On Apr 23, 2009, at 5:07 PM, Justin Lee wrote:
> Should I be creating the Habitat differently? I tried making it
> exactly like what glassfish does but I guess I'm missing something.
> If it's something *I'm* doing wrong I'd rather fix that so that the
> two environments are as similar as possible.
>
> Jerome Dochez wrote:
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>