Hi Wolfram,
sorry for the delay
w.rittmeyer wrote:
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> For GlassFish[1], it will work at the virtual-server and web-module
>> level (only the Engine level is not supported...but if you really
>> needs it, I can certainly look how to do it).
>>
>
> Hi Jeanfrancois,
>
> I had a look at your blog posting but I nevertheless wonder how to pass
> values to the Valves setter methods.
>
> Well I guess you do /not/ want to change the domains.xml-DTD but /I/
> think s.th. along the lines of the following would be nice:
>
> <virtual-server hosts="${com.sun.aas.hostName}" ...>
> <property name="docroot" value="${com.sun.aas.instanceRoot}/docroot"/>
> <!-- ... more properties for virtual-server -->
> <valve name="someValve" classname="x.y.z.ExpiresHeaderValve">
> <property name="contentTypes" value="text/plain,text/css" />
> <property name="addOnYears" value="1" />
> <!-- ... more properties for valve -->
> </valve>
> </virtual-server>
>
> And of course for web-modules as well.
Agree. Can you file an RFE here once you have a chance:
https://glassfish.dev.java.net/servlets/ProjectIssues
>
> And corresponding asadmin-commands like
>
> asadmin create-valve --class xyz --parent-type virtual-server
> --parent-id server --target server somevalve
>
> (where in the case of a web-module the id would actually be a name) and
>
> asadmin set
> server.http-service.virtual-server.somevalve.property.contentType=text/html,text/css
>
>
> for setting the properties of the valve.
>
> In general: If there is one thing I think that is not that nice in GF
> than it is that it's not as easily configurable. Take the access-logger
> for example. If I am not mistaken it is not possible to use different
> strategies (e.g. for rolling files) for different virtual servers. No
> bummer but not that nice either.
>
Can you file another RFE? We can certainly evaluate that one for v3.
>
>>>
>>> Considering this I think using a Valve would be more fine-grained
>>> than the default-web.xml while still coarser than a filter for each
>>> web-app.
>>>
>>>
>>> But I will give it some more thoughts.
>>
>> Let us know which solution you picked :-)
>>
>
> I still would like to go down the Valve route but right now I think it
> might not be so good an idea with GF. Though of course I hope you can
> prove me wrong ;-)
No Valve is a good solution for what you want. An alternative would
consist of extending Grizzly directly and inject your header at the
bytes level, before the response is sent. That alternative will perform
faster than a Valve. What exact information do you need to have to
decide when to inject the new header?
In Grizzly, you can inject your header by having your own ProcessorTask
(the class responsible for manipuating the request/response).
A+
-- Jeanfrancois
>
>
> Regards,
>
> Wolfram Rittmeyer
>
>> A+
>>
>> -- Jeanfrancois
>>
>> [1]
>> http://weblogs.java.net/blog/jfarcand/archive/2006/09/extending_glass.html
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>