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
>