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.
> 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.
> 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
>