Hi Wolfram,
Wolfram Rittmeyer wrote:
> 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.
Oups....sorry about that. Yes you are absolutely right. I wrote the
example and forgot to test :-)
>
> 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?
Yes it does. Once flushed, it ignore all other request to addHeader.
Have you tried turning the log level to FINE? You should have seen an
exception. Are you?
>
>> 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.
I see...the only solution you have right now is to use -D properties.
Far from perfect :-(
>
>
> 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?
Yes.
Or
> is there another reason for this?
Just didn't have time to port them to Grizzly :-)
Thanks
-- Jeanfrancois
>
>
>
> Regards,
>
> Wolfram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>