forwarding discussion about Router filter for Grizzly 2.0 to the
dev_at_grizzly mailing list, so community can provide feedback on it.
WBR,
Alexey.
> From: "Gauny, Ronnie" <Ronnie.Gauny_at_sabre-holdings.com>
> Date: December 3, 2008 3:03:05 AM GMT+01:00
> To: Oleksiy.Stashok_at_Sun.COM
> Subject: RE: FilterChain Execution
>
> Hi Aelexy,
>
> This sounds great! I really like the idea of implementing it into
> the filter and retaining the current API, better solution all around.
>
> Thanks,
> Ronnie
>
> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> Sent: Tuesday, December 02, 2008 4:11 PM
> To: Gauny, Ronnie
> Subject: Re: FilterChain Execution
>
> Hi,
>
>>
>> Ok, I see what you mean here. In Grizzly 1.x we called this port
>> unification. When single network listener could process several
>> protocols. Like: HTTP, FTP, IIOP etc...
>> Currently with Grizzly 2.0 it is possible to set just next Filter.
>> Probably the feature you're looking is to set a list of filters,
>> not just one, right?
>>
>> Exactly!! In orange below is what would change on the NextAction
>> class…..then the manager when executing the “NextFilter” would
>> iterate through the list and execute each Filter in the list,
> Ok.
>
>> public class NextAction {
>> private org.glassfish.grizzly.filterchain.NextAction.Action
>> action;
>> private org.glassfish.grizzly.filterchain.Filter nextFilter;
>> would change to a List of Filters
>> private java.lang.Throwable exception;
>>
>> public NextAction() { /* compiled code */ }
>>
>> public
>> NextAction(org.glassfish.grizzly.filterchain.NextAction.Action
>> action) { /* compiled code */ }
>>
>> public void reset() { /* compiled code */ }
>>
>> public void
>> add(org.glassfish.grizzly.filterchain.NextAction.Action action,
>> org.glassfish.grizzly.filterchain.Filter filter) { /* compiled code
>> */ }
>>
>> public org.glassfish.grizzly.filterchain.NextAction.Action
>> getAction() { /* compiled code */ }
>>
>> public void
>> setAction(org.glassfish.grizzly.filterchain.NextAction.Action
>> action) { /* compiled code */ }
>>
>> public List getNextFilters() { /* compiled code */ }
>>
>> public void setNextFilters(List filter) { /* compiled code */ }
>>
>> public void
>> addNextFilter(org.glassfish.grizzly.filterchain.Filter filter) { /*
>> compiled code */ }
>>
>> public java.lang.Throwable getException() { /* compiled code */ }
>>
>> public void setException(java.lang.Throwable throwable) { /*
>> compiled code */ }
>> public static final enum Action {
>> public static final INVOKE, public static final RETURN,
>> public static final SUSPEND, public static final THROW;
>>
>> public static
>> org.glassfish.grizzly.filterchain.NextAction.Action[] values() { /*
>> compiled code */ }
>>
>> public static
>> org.glassfish.grizzly.filterchain.NextAction.Action
>> valueOf(java.lang.String s) { /* compiled code */ }
>>
>> private Action() { /* compiled code */ }
>> }
>> }
> NextAction API was recently changed a little, but anyway it's clear,
> what has to be changed.
>
>
>
> ProcessMap, you proposing could be implemented as Filter, so, IMHO,
> there is no need to introduce separate API?
> Hmm….not sure if I understand this…..this is the old way to enter
> the transports filter chain:
>>
>> ransport.getFilterChain().add(new TransportFilter());
>> transport.getFilterChain().add(new ByteStreamFilter());
>> /transport.getFilterChain().add(new HSSPProtocolFilter());
>>
>> transport.getFilterChain().add(srouter.createRoutingFilterAdapter());
>>
>> The new way would be for every filter u give a list of recipient
>> filters: I just stored this into a HashMap cause it made sense to
>> me….can be stored how ever but I would think the add would change
>> This way the FilterChainProcessor looks up the NextAction(s) list
>> by using the HashMap.
>>
>> FilterAdapter inpoint = new InpointFilterAdapter();
>> FilterAdapter processor = new ProcessorFilterAdapter();
>> FilterAdapter outpoint = new OutPointFilterAdapter();
>> FilterAdapter monitor = new MonitorFilterAdapter();
>> Map processorMap = new HashMap();
>> List inpointRecipients = new ArrayList();
>> inpointRecipients.add(processor);
>> processMap.put(inpoint, inpointRecipients);
>> List processorRecipients = new ArrayList();
>> processorRecipients.add(outpoint);
>> processorRecipients.add(monitor);
>> processMap.put(processor, processorRecipients);
>>
>> transport.getFilterChain()..setProcessMap(processMap);
>
> I see the idea, what I want to propose is avoiding this:
>>
>> transport.getFilterChain()..setProcessMap(processMap);
>
> but implement ProcessorMap as Filter, so finally we will have
> something like this:
> FilterAdapter inpoint = new InpointFilterAdapter();
> FilterAdapter processor = new ProcessorFilterAdapter();
> FilterAdapter outpoint = new OutPointFilterAdapter();
> FilterAdapter monitor = new MonitorFilterAdapter();
> ProcessorMapFilter processorMap = new ProcessorMapFilter();
> List inpointRecipients = new ArrayList();
> inpointRecipients.add(processor);
> processMap.put(inpoint, inpointRecipients);
> List processorRecipients = new ArrayList();
> processorRecipients.add(outpoint);
> processorRecipients.add(monitor);
> processMap.put(processor, processorRecipients);
> transport.getFilterChain().add(processMap);
>
> This way we will reuse existing API without making any changes,
> except NextAction.
> BTW, when you call processMap.put(key, value);, where key is Filter
> and value is list of Filters.... What should the key Filter be
> responsible for?
> I think it should be responsible for recognition, if incoming
> message is targeted to its filter list. But may be you have
> something different in mind?
>
> Also, just small API change propose.
> processMap(Filter, List<Filter>) could be changed to
> processMap(Filter, FilterChain);
>
> think it will look better. What do you think?
>
>>
>> I think this may be confusing because of symantics…….what I am
>> doing is actually creating a “FilterChain” not a “ProcessMap”
>> externally. This can also be accomplished internally with an add
>> method this way:
>>
>> transport.getFilterChain().add( inFilter, recipientsFilters);
> I'd like to avoid creating new API if it's possible.
>
> Thank you!
> And pls. if you don't mind, can we move just this discussion to
> mailing list? I think it could be interested for guys, who are
> working on project with us.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>
> so from the above line of code, after processing the inFilter’s
> handleRead the NextFilters to be executed will be all the filters in
> the reciepientsFilters List.
>
> Can you pls. also elaborate ProcessorMap.put(key, value)... key
> object is used to distinguish if this is message, which could be
> processed by correspondent Filter list? Or...?
>
> The key is a filter, and the value is a list of recipient filters,
> this makes it easy to look up what filters we need to process next.
>
> In any case, I think idea is very good! We need something like that
> for sure. Let's just discuss the best possible solution, ok?
>
> Let me know if the above makes sense. I think this would be great
> and very flexible!
>
> Thanks,
> Ronnie
>
> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> Sent: Tuesday, December 02, 2008 11:46 AM
> To: Gauny, Ronnie
> Subject: Re: FilterChain Execution
>
> Hi Ronnie,
>
>>
>> I was looking at creating a filter chain a bit more. My
>> suggestion would be to have the NextAction actually be a List for
>> Filters this would provide parallel processing of the filterchain
>> and maximum flexibility.
>>
> Can you pls. elaborate here. Not sure I understand part with
> parallel processing :)
>
>
>
> For exampl
>
> FilterAdapter inpoint = new InpointFilterAdapter();
>
> FilterAdapter processor = new ProcessorFilterAdapter();
>
> FilterAdapter outpoint = new OutPointFilterAdapter();
>
> FilterAdapter monitor = new MonitorFilterAdapter();
>
> Map processorMap = new HashMap();
>
> List inpointRecipients = new ArrayList();
>
> inpointRecipients.add(processor);
>
> processMap.put(inpoint, inpointRecipients);
>
> List processorRecipients = new ArrayList();
>
> processorRecipients.add(outpoint);
>
> processorRecipients.add(monitor);
>
> processMap.put(processor, processorRecipients);
>
> transport.getFilterChain()..setProcessMap(processMap);
>
> Ok, I see what you mean here. In Grizzly 1.x we called this port
> unification. When single network listener could process several
> protocols. Like: HTTP, FTP, IIOP etc...
> Currently with Grizzly 2.0 it is possible to set just next Filter.
> Probably the feature you're looking is to set a list of filters, not
> just one, right?
>
> ProcessMap, you proposing could be implemented as Filter, so, IMHO,
> there is no need to introduce separate API?
> Can you pls. also elaborate ProcessorMap.put(key, value)... key
> object is used to distinguish if this is message, which could be
> processed by correspondent Filter list? Or...?
>
> In any case, I think idea is very good! We need something like that
> for sure. Let's just discuss the best possible solution, ok?
>
> Thank you.
>
> WBR,
> Alexey.
>
> PS: Once we don't discuss here any proprietary code, can we move
> this to mailing list?
>
>
>
>
> There are a number of possibilities this can be used for. What do
> you think?
>
> Thanks,
>
> Ronnie
>
>
>
>
>
>