Jeanfrancois Arcand wrote:
> Salut,
>
>> 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?
>
> No works since v2. Mainly, you just have to do something like:
>
>> 10 package your.package;
>> 11 12 import
>> com.sun.enterprise.web.connector.grizzly.SelectorThread;
>> 13 import
>> com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask;
>> 14 15 public class ExpireHeaderSelectorThread extends
>> SelectorThread {
>> 16 /**
>> 17 * Create <code>ProcessorTask</code> objects and configure
>> it to be ready
>> 18 * to proceed request.
>> 19 */
>> 20 @Override
>> 21 protected ProcessorTask newProcessorTask(boolean initialize){
>> 22 DefaultProcessorTask task =
>> 23 new DefaultProcessorTask(initialize,
>> bufferResponse){
>> 24 /**
>> 25 * When committing the response, we have to
>> validate the set of headers, as
>> 26 * well as setup the response filters.
>> 27 */
>> 28 @Override
>> 29 protected void prepareResponse() {
>> 30 super.prepareResponse();
>> 31 // Add date header
>> 32 if (!response.containsHeader("expire-headers")){
>> 33 response.addHeader("expire-headers", "your
>> expire header");
>> 34 }
>> 35 }
>> 36 };
>> 37 return configureProcessorTask(task);
>> 38 }
>> 39 }
>
Hi Jeanfrancois,
your above code caused me some trouble ;-) Though the reason why it
didn't work as described was pretty simple. Since prepareResponse() of
DefaultProcessorTask calls outputBuffer.sendHeader() for each header and
outputBuffer.endHeaders() afterwards, I get an exception when I try to
set another header afterwards. Putting the call to
super.prepareResponse() at the end of the overwritten method of course
solved this problem.
Strangely enough I did't see any stack traces in the logs. I still do
not know why. Would have been quite helpful ;-) Also I got a 500
response. Why that? Doesn't outputBuffer.sendHeader() actually flush the
headers?
> To tell Grizzly to use your SelectorThread, just add the following
> property under the http-listener:
>
> <property name="selectorThreadImpl"
> value="your.package.ExpireHeaderSelectorThread"/>
>
> Now all requests to that listener will be executed by your Selector.
>
> Hope that help.
>
Well the problem with the SelectorThread approach is of course the same
as the one with the Valve approach: I need to be able to configure them.
Another thing - just out of curiosity: Since you've written that
SelectorThreads perform better than Valves: Why then does GF use Valves
for AccessLogging and RequestDumping? Because of the Tomcat heritage? Or
is there another reason for this?
Regards,
Wolfram