Does that mean I can delete those properties from the ProperitesDesc[]
in HttpService and remove all references to them? Or do they just
disappear from the documentation. With Tim's tool (and one I'm working
on) these properties descriptions will likely show up in the generated
documentation.
Jeanfrancois Arcand wrote:
> Salut,
>
> Justin Lee wrote:
>> Jeanfrancois or Jan Luehe can better answer that one.
>>
>> June.Parks_at_Sun.COM wrote:
>>> So what do they DO? The selectorThreadImpl property appears to take
>>> a class name as its value, but what is this class supposed to
>>> implement? What is a selector thread? What are reader selectors,
>>> and why would a user want to specify them?
>
> Both of them needs to be deprecated. They were added before Grizzly
> becomes its own project, and used to extend (mainly JRuby in v2). But
> they were never published so we should ignore them.
>
> A+
>
> -- Jeanfrancois
>
>
>>>
>>> June
>>>
>>> On 07/02/09 11:21, Justin Lee wrote:
>>>> There are no defaults, per se. Not in the sense of the attributes
>>>> having default values at least. If they're not present then the
>>>> underlying engines do their normal thing.
>>>>
>>>> June.Parks_at_Sun.COM wrote:
>>>>> What do they do? What are their defaults?
>>>>>
>>>>> June
>>>>>
>>>>> On 07/02/09 11:04, Justin Lee wrote:
>>>>>> Those were the http-listener forms of those properties. Sadly,
>>>>>> they're still on http-service. I'd like to remove them all but
>>>>>> that has a rather wide impact.
>>>>>>
>>>>>> June.Parks_at_Sun.COM wrote:
>>>>>>> The authPassthroughEnabled, traceEnabled, and tcpNoDelay
>>>>>>> properties have been converted to attributes in the new network
>>>>>>> configuration, so it seems I can ignore those.
>>>>>>>
>>>>>>> I would like verification that the remaining properties, listed
>>>>>>> below, are for virtual servers. If they are for listeners, they
>>>>>>> don't belong under http-service anymore.
>>>>>> These all eventually get applied to the connector essentially
>>>>>> overriding settings on the listeners. Personally, I'd prefer to
>>>>>> remove PropertyBag support from all the network related
>>>>>> interfaces at least and promote the properties we're actually
>>>>>> using to attributes. It makes it so much easier to document
>>>>>> what's supported and with what values. And it makes breaks
>>>>>> easier to track since the compiler will let us know when we screw
>>>>>> up in many cases. But anyway. This is what we have now.
>>>>>>>
>>>>>>> connectionTimeout
>>>>>>> proxyHandler
>>>>>>> ssl-cache-entries
>>>>>>> ssl-session-timeout
>>>>>>> ssl3-session-timeout
>>>>>>> reader-selectors
>>>>>>> selectorThreadImpl
>>>>>>>
>>>>>>> I've never heard of reader-selectors or selectorThreadImpl.
>>>>>>> What do they do? What are their defaults?
>>>>>>>
>>>>>>> June
>>>>>>>
>>>>>>> On 07/02/09 08:16, Justin Lee wrote:
>>>>>>>> These are the http-service properties I'm finding that are
>>>>>>>> still referenced in v3:
>>>>>>>>
>>>>>>>> authPassthroughEnabled
>>>>>>>> connectionTimeout
>>>>>>>> proxyHandler
>>>>>>>> reader-selectors
>>>>>>>> selectorThreadImpl
>>>>>>>> ssl-cache-entries
>>>>>>>> ssl-session-timeout
>>>>>>>> ssl3-session-timeout
>>>>>>>> tcpNoDelay
>>>>>>>> traceEnabled
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> June.Parks_at_Sun.COM wrote:
>>>>>>>>> On 07/01/09 14:17, Justin Lee wrote:
>>>>>>>>>> Is this related?
>>>>>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6935
>>>>>>>>>>
>>>>>>>>>> For the record, properties on http-service are still
>>>>>>>>>> supported but not on any of the interfaces in grizzly-config
>>>>>>>>>> because depending on any glassfish related to bring in
>>>>>>>>>> PropertyBag would break the build.
>>>>>>>>> Okay, then I need to know SPECIFICALLY which properties of
>>>>>>>>> http-service are still supported. A whole bunch of them have
>>>>>>>>> been converted to attributes in the new Grizzly
>>>>>>>>> configuration. The following have not been converted. Which
>>>>>>>>> of these still work, given that they can only apply to virtual
>>>>>>>>> servers and not to listeners?
>>>>>>>>>
>>>>>>>>> use-nio-direct-bytebuffer
>>>>>>>>> rcmSupport
>>>>>>>>> proxyHandler
>>>>>>>>> proxiedProtocols
>>>>>>>>> recycle-objects
>>>>>>>>> reader-threads
>>>>>>>>> acceptor-queue-length
>>>>>>>>> reader-queue-length
>>>>>>>>> connectionTimeout
>>>>>>>>> monitoring-cache-enabled
>>>>>>>>> monitoring-cache-refresh-in-millis
>>>>>>>>> ssl-cache-entries
>>>>>>>>> ssl-session-timeout
>>>>>>>>> ssl3-session-timeout
>>>>>>>>>
>>>>>>>>> June
>>>>>>>>>>
>>>>>>>>>> Jan Luehe wrote:
>>>>>>>>>>> On 07/ 1/09 12:03 PM, June.Parks_at_Sun.COM wrote:
>>>>>>>>>>>> The Grizzly team told me that the proxy-related properties
>>>>>>>>>>>> of http-listener/http-service to which you refer are not
>>>>>>>>>>>> supported in the v3 network-service.
>>>>>>>>>>>
>>>>>>>>>>> I think that decision needs to be revisited.
>>>>>>>>>>>
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> June
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/01/09 11:52, Jan Luehe wrote:
>>>>>>>>>>>>> I'm trying to fix a package regression of an exposed
>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Earlier versions of GlassFish started exposing the
>>>>>>>>>>>>> com.sun.appserv.ProxyHandler interface, which is useful
>>>>>>>>>>>>> for when
>>>>>>>>>>>>> GlassFish is front-ended by an SSL-offloading
>>>>>>>>>>>>> load-balancer. Its
>>>>>>>>>>>>> default implementation (which works with Sun's
>>>>>>>>>>>>> load-balancer plug-in) is
>>>>>>>>>>>>> given by com.sun.enterprise.web.ProxyHandlerImpl, and
>>>>>>>>>>>>> alternative
>>>>>>>>>>>>> implementations may be specified (as
>>>>>>>>>>>>> http-listener/http-service
>>>>>>>>>>>>> properties, using their FQCN) in domain.xml.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since this has been an exposed interface, it must be
>>>>>>>>>>>>> preserved for
>>>>>>>>>>>>> backward compatibility reasons.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In GlassFish v3, the ProxyHandler interface was moved from
>>>>>>>>>>>>> "com.sun.appserv" to "com.sun.appserv.security.provider".
>>>>>>>>>>>>>
>>>>>>>>>>>>> It needs to be moved back to its original package. In
>>>>>>>>>>>>> order to avoid any
>>>>>>>>>>>>> split-packages, that would mean moving ProxyHandler.java to
>>>>>>>>>>>>>
>>>>>>>>>>>>> common/common-util/src/main/java/com/sun/appserv
>>>>>>>>>>>>>
>>>>>>>>>>>>> which already contains BytecodePreprocessor.java and
>>>>>>>>>>>>> ClassLoaderUtil.java
>>>>>>>>>>>>> and therefore "owns" the com.sun.appserv package.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ProxyHandler.java imports
>>>>>>>>>>>>> javax.servlet.http.HttpServletRequest, so if we
>>>>>>>>>>>>> moved it to "common/common-util", then we would also have
>>>>>>>>>>>>> to move
>>>>>>>>>>>>> "web/javax.servlet" to "javaee-api/javax.servlet", since
>>>>>>>>>>>>> "common" builds after
>>>>>>>>>>>>> "javaee-api", and to avoid any circular dependencies
>>>>>>>>>>>>> between "common" and "web".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does anybody see any issues with moving
>>>>>>>>>>>>> "web/javax.servlet" to
>>>>>>>>>>>>> "javaee-api/javax.servlet"?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>