[jira] Resolved: (DIRMINA-463) Find the best way to specify both MINA and non-MINA events.

["Niklas Therning (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Niklas Therning resolved DIRMINA-463.
-------------------------------------

    Resolution: Fixed

I've introduced IoHandlerEvents and IoFilterEvents which enumerate the possible events for the IoHandler and IoFilter interfaces. I've also added IoHandlerTransition and IoFilterTransition annotations. When used the events for the on annotation parameter aren't strings but instead come from either IoHandlerEvents or IoFilterEvents. StateMachine.createForIoHandler() should be used to create a StateMachine which uses the IoHandlerTransition annotation. See the TapeDeck example for a demonstration.

PS: Annotations in Java are extremely limited. For example you cannot have null as a default value for a parameter. This is why I found it impossible to use IoEventType from mina-core and had to introduce IoHandlerEvents (my first idea was to use null for the wildcard event). Furthermore enums cannot be extended which is why IoFilterEvents redefines all the events which are also in IoHandlerEvents. In don't like code duplication but I didn't have a choice this time. :-(

> Find the best way to specify both MINA and non-MINA events.
> -----------------------------------------------------------
>
>                 Key: DIRMINA-463
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-463
>             Project: MINA
>          Issue Type: Task
>          Components: Statemachine
>            Reporter: Trustin Lee
>            Assignee: Niklas Therning
>            Priority: Minor
>             Fix For: 2.0.0-M1
>
>
> As discussed here: http://tinyurl.com/2omrl9
> For now, we use String to identify event types, which is somewhat unsafe.  Using an enum might be useful, but there are a few disadvantages:
> * Wildcard event type cannot be used, which could be extended further (e.g. "message*" or "session(Opened|Closed)")
> Probably sticking to String might be the best solution? :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.