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
>