Hi Ronnie,
I've completed FilterChain API changes, we discussed.
So now you can continue implementing the Router filter. Pls. let me
know if you'll have any other suggestions.
Thanks.
WBR,
Alexey.
On Dec 3, 2008, at 10:37 , Oleksiy Stashok wrote:
> 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
>>
>>
>>
>>
>>
>>
>