I'm saying there are a handful of properties you can set on http-service
that get applied at what is the logical listener level. That is, the
constructs that are created using the configurations found in the
listener elements are affected by properties set on http-service. And
yes, those properties apply to all listeners whether you want them to or
not.
June.Parks_at_Sun.COM wrote:
> On 07/02/09 11:18, Justin Lee wrote:
>>
>>
>> June.Parks_at_Sun.COM wrote:
>>> 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.
>> Agreed.
>>>
>>> It used to be that these properties could be set for all listeners
>>> on http-service and for a particular listener on http-listener.
>> What properties are supported on http-service to get pushed down to
>> the listener (essentially) so this still works mostly as it did.
> Um, no. What you seem to say next is that you CAN'T set these
> properties both globally and individually.
>>> Are these properties settable on network-listener elements now?
>> network-listener, http, protocol, etc don't support any <property>
>> elements. Everything that's supported for these elements has an
>> attribute explicitly defined.
> So what you're saying is that the only way to set these properties is
> on http-service, and that they apply to ALL network-listener elements
> whether you want them to or not.
>
> June
>>> 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
>