Jeanfrancois Arcand wrote:
>> 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
>
Hi Jeanfrancois,
I've done just that:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4006
>>
>> And corresponding asadmin-commands like
>>
>> asadmin create-valve --class xyz --parent-type virtual-server
>> --parent-id server --target server somevalve
(...)
>>
>
> Can you file another RFE? We can certainly evaluate that one for v3.
>
And for this one it is
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4007
>
>>
>>>>
>>>> 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?
>
I would need to have access to the content-type header as it should be
possible to limit this for certain types only (like "image/png" or
"text/css"). Furthermore I would have to check whether the expires
header is already set. In this case it would have to be left unchanged.
And I'd like to be able to configure for which content-types the header
shall be set and how many years shall be added to the current timestamp.
> In Grizzly, you can inject your header by having your own ProcessorTask
> (the class responsible for manipuating the request/response).
>
Irrespective of the current task at hand I very much hope that the above
changes/RFEs will be implemented for any future requirements.
I do not know enough about the Grizzly-Glassfish integration. How can I
use my own ProcessorTask for Grizzly in GF? Would this be possible with
v2_UR1 or with v3 only?
Regards,
Wolfram
> A+
>
> -- Jeanfrancois
>