Well if you can't move them you can't, but please pity the poor tech
writer who has to explain to users this confusing state of things.
Although I hope to reduce the confusion for users, I can't completely
because this just isn't optimal design.
It used to be that these properties could be set for all listeners on
http-service and for a particular listener on http-listener. Are these
properties settable on network-listener elements now?
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
>