You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/10/23 04:11:58 UTC
A few comments on statemachine module.
Hi,
A few random comments...:
1) org.apache.mina.statemachine.mina.Events could be replaced with
org.apache.mina.common.IoEventType.
2) WDYT about renaming MinaStateContextLookup to
IoSessionStateContextLookup and move it up to
org.apache.mina.statemachine?
3) We could mark mina-core dependency 'optional' because statemachine
module can work without mina-core.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: A few comments on statemachine module.
Posted by Niklas Therning <ni...@trillian.se>.
Niklas Therning wrote:
> Trustin Lee wrote:
>> On 10/29/07, Niklas Therning <ni...@trillian.se> wrote:
>>
>>>> Any new idea on event types? :)
>>>>
>>>>
>>> I've been thinking about how one could use the IoEventType enum. One
>>> idea is to change the @Handler annotation into a meta annotation. Other
>>> annotations which have been annotated with @Handler can be used by the
>>> statemachine module to build the StateMachine. Maybe something like:
>>>
>>> @Handler(IoEnumType.class, useNullForWildcard = true)
>>> public interface @MinaHandler {
>>> IoEnumType on() default null
>>> String next()
>>> String in()
>>> }
>>>
>>> The @MinaHandler annotation must have the on, in, next parameters or
>>> StateMachineFactory will complain. StateMachineFactory will have to
>>> look
>>> at all annotations in the handler objects and see if they have been
>>> annotated with @Handler.
>>>
>>
>> Uh... It sounds too complex?
>>
> Yes, I agree, it sounds rather complex. :-)
>>
>>> Alternatively StateMachineFactory takes MinaHandler.class as a
>>> parameter. Maybe that's a better idea?
>>>
>>
>> Could you provide me some example code if StateMachineFactory takes
>> MinaHandler.class as a parameter? Isn't MinaHandler a method
>> annotation? How can I specify an annotation as a parameter?
>>
>>
> I'm not talking about generics, rather a constructor parameter. It
> should be possible to specify MinaHandler.class
> as a constructor argument. An annotation is compiled into a .class
> just like any other class or interface.
>
> It would be cool if one could use a custom @Handler annotation because
> that would make it possible to use enums not only for the events but
> possibly also for the states instead of strings. I'll see if I can
> come up with an example.
>
> /Niklas
>
I've added a new create() method in StateMachineFactory which one can
use to specify alternatives to the Handler and Handlers annotations. The
custom annotations must have the same parameters as the default except
that the on() parameter in the alternative to Handler can use an enum
instead of strings. I haven't yet had the time to make an example which
uses this feature. I'll see if I can find some time later this week.
--
Niklas Therning
www.spamdrain.net
Re: A few comments on statemachine module.
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> On 10/29/07, Niklas Therning <ni...@trillian.se> wrote:
>
>>> Any new idea on event types? :)
>>>
>>>
>> I've been thinking about how one could use the IoEventType enum. One
>> idea is to change the @Handler annotation into a meta annotation. Other
>> annotations which have been annotated with @Handler can be used by the
>> statemachine module to build the StateMachine. Maybe something like:
>>
>> @Handler(IoEnumType.class, useNullForWildcard = true)
>> public interface @MinaHandler {
>> IoEnumType on() default null
>> String next()
>> String in()
>> }
>>
>> The @MinaHandler annotation must have the on, in, next parameters or
>> StateMachineFactory will complain. StateMachineFactory will have to look
>> at all annotations in the handler objects and see if they have been
>> annotated with @Handler.
>>
>
> Uh... It sounds too complex?
>
Yes, I agree, it sounds rather complex. :-)
>
>> Alternatively StateMachineFactory takes MinaHandler.class as a
>> parameter. Maybe that's a better idea?
>>
>
> Could you provide me some example code if StateMachineFactory takes
> MinaHandler.class as a parameter? Isn't MinaHandler a method
> annotation? How can I specify an annotation as a parameter?
>
>
I'm not talking about generics, rather a constructor parameter. It
should be possible to specify MinaHandler.class
as a constructor argument. An annotation is compiled into a .class just
like any other class or interface.
It would be cool if one could use a custom @Handler annotation because
that would make it possible to use enums not only for the events but
possibly also for the states instead of strings. I'll see if I can come
up with an example.
/Niklas
Re: A few comments on statemachine module.
Posted by Trustin Lee <tr...@gmail.com>.
On 10/29/07, Niklas Therning <ni...@trillian.se> wrote:
> >
> > Any new idea on event types? :)
> >
>
> I've been thinking about how one could use the IoEventType enum. One
> idea is to change the @Handler annotation into a meta annotation. Other
> annotations which have been annotated with @Handler can be used by the
> statemachine module to build the StateMachine. Maybe something like:
>
> @Handler(IoEnumType.class, useNullForWildcard = true)
> public interface @MinaHandler {
> IoEnumType on() default null
> String next()
> String in()
> }
>
> The @MinaHandler annotation must have the on, in, next parameters or
> StateMachineFactory will complain. StateMachineFactory will have to look
> at all annotations in the handler objects and see if they have been
> annotated with @Handler.
Uh... It sounds too complex?
> Alternatively StateMachineFactory takes MinaHandler.class as a
> parameter. Maybe that's a better idea?
Could you provide me some example code if StateMachineFactory takes
MinaHandler.class as a parameter? Isn't MinaHandler a method
annotation? How can I specify an annotation as a parameter?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: A few comments on statemachine module.
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> On 10/23/07, Trustin Lee <tr...@gmail.com> wrote:
> <snip/>
>
>
>> 2) WDYT about renaming MinaStateContextLookup to
>> IoSessionStateContextLookup and move it up to
>> org.apache.mina.statemachine?
>>
>> 3) We could mark mina-core dependency 'optional' because statemachine
>> module can work without mina-core.
>>
>
> Done in the following revision:
>
> http://svn.apache.org/viewvc?view=rev&revision=589477
>
> Any new idea on event types? :)
>
> Cheers,
> Trustin
>
Thanks for taking care of that!
I've been thinking about how one could use the IoEventType enum. One
idea is to change the @Handler annotation into a meta annotation. Other
annotations which have been annotated with @Handler can be used by the
statemachine module to build the StateMachine. Maybe something like:
@Handler(IoEnumType.class, useNullForWildcard = true)
public interface @MinaHandler {
IoEnumType on() default null
String next()
String in()
}
The @MinaHandler annotation must have the on, in, next parameters or
StateMachineFactory will complain. StateMachineFactory will have to look
at all annotations in the handler objects and see if they have been
annotated with @Handler.
Alternatively StateMachineFactory takes MinaHandler.class as a
parameter. Maybe that's a better idea?
WDYT? Could something like this work?
/Niklas
Re: A few comments on statemachine module.
Posted by Trustin Lee <tr...@gmail.com>.
On 10/23/07, Trustin Lee <tr...@gmail.com> wrote:
<snip/>
> 2) WDYT about renaming MinaStateContextLookup to
> IoSessionStateContextLookup and move it up to
> org.apache.mina.statemachine?
>
> 3) We could mark mina-core dependency 'optional' because statemachine
> module can work without mina-core.
Done in the following revision:
http://svn.apache.org/viewvc?view=rev&revision=589477
Any new idea on event types? :)
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: A few comments on statemachine module.
Posted by Trustin Lee <tr...@gmail.com>.
On 10/23/07, Niklas Therning <ni...@trillian.se> wrote:
> Trustin Lee wrote:
> > On 10/23/07, Niklas Therning <ni...@trillian.se> wrote:
> >
> >> Trustin Lee wrote:
> >>
> >>> Hi,
> >>>
> >>> A few random comments...:
> >>>
> >>> 1) org.apache.mina.statemachine.mina.Events could be replaced with
> >>> org.apache.mina.common.IoEventType.
> >>>
> >
> > <snip/>
> >
> >
> >> #1 I'm not sure about though. IoEventType has some events that will
> >> never be generated for an IoHandler (WRITE and CLOSE). In statemachine
> >> we also have the wildcard event "*" which matches any event. And then
> >> there is the problem of having the Handler annotation use an enum class
> >> instead of Strings for the events. That would restrict statemachine to
> >> only be able to work with the events in that enum. However, I certainly
> >> think that using an enum for the possible events would be so much nicer
> >> than using Strings. I'll see if I can come up with something which
> >> allows the use of events in an enum without restricting the code to a
> >> particular set of events.
> >>
> >
> > Hmm, you are right. What do you think about using Object for the
> > events? Then we could use both String and enums, that means a user
> > can use both "*" and IoEventType.
> >
> I would love that! Sadly I don't think you can do that with annotations.
> Primitive types, enums and strings are the only types you can use for
> annotation parameters IIRC. Maybe we could provide an IoHandler specific
> annotation which uses IoEventType and uses null for wildcard events.
> I'll see what I can come up with.
Doh! I didn't know that. :-(
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: A few comments on statemachine module.
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> On 10/23/07, Niklas Therning <ni...@trillian.se> wrote:
>
>> Trustin Lee wrote:
>>
>>> Hi,
>>>
>>> A few random comments...:
>>>
>>> 1) org.apache.mina.statemachine.mina.Events could be replaced with
>>> org.apache.mina.common.IoEventType.
>>>
>
> <snip/>
>
>
>> #1 I'm not sure about though. IoEventType has some events that will
>> never be generated for an IoHandler (WRITE and CLOSE). In statemachine
>> we also have the wildcard event "*" which matches any event. And then
>> there is the problem of having the Handler annotation use an enum class
>> instead of Strings for the events. That would restrict statemachine to
>> only be able to work with the events in that enum. However, I certainly
>> think that using an enum for the possible events would be so much nicer
>> than using Strings. I'll see if I can come up with something which
>> allows the use of events in an enum without restricting the code to a
>> particular set of events.
>>
>
> Hmm, you are right. What do you think about using Object for the
> events? Then we could use both String and enums, that means a user
> can use both "*" and IoEventType.
>
I would love that! Sadly I don't think you can do that with annotations.
Primitive types, enums and strings are the only types you can use for
annotation parameters IIRC. Maybe we could provide an IoHandler specific
annotation which uses IoEventType and uses null for wildcard events.
I'll see what I can come up with.
/Niklas
Re: A few comments on statemachine module.
Posted by Trustin Lee <tr...@gmail.com>.
On 10/23/07, Niklas Therning <ni...@trillian.se> wrote:
> Trustin Lee wrote:
> > Hi,
> >
> > A few random comments...:
> >
> > 1) org.apache.mina.statemachine.mina.Events could be replaced with
> > org.apache.mina.common.IoEventType.
<snip/>
> #1 I'm not sure about though. IoEventType has some events that will
> never be generated for an IoHandler (WRITE and CLOSE). In statemachine
> we also have the wildcard event "*" which matches any event. And then
> there is the problem of having the Handler annotation use an enum class
> instead of Strings for the events. That would restrict statemachine to
> only be able to work with the events in that enum. However, I certainly
> think that using an enum for the possible events would be so much nicer
> than using Strings. I'll see if I can come up with something which
> allows the use of events in an enum without restricting the code to a
> particular set of events.
Hmm, you are right. What do you think about using Object for the
events? Then we could use both String and enums, that means a user
can use both "*" and IoEventType.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: A few comments on statemachine module.
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> Hi,
>
> A few random comments...:
>
> 1) org.apache.mina.statemachine.mina.Events could be replaced with
> org.apache.mina.common.IoEventType.
>
> 2) WDYT about renaming MinaStateContextLookup to
> IoSessionStateContextLookup and move it up to
> org.apache.mina.statemachine?
>
> 3) We could mark mina-core dependency 'optional' because statemachine
> module can work without mina-core.
>
> Cheers,
> Trustin
>
Thanks for the comments! I think #2 and #3 are very good suggestions.
#1 I'm not sure about though. IoEventType has some events that will
never be generated for an IoHandler (WRITE and CLOSE). In statemachine
we also have the wildcard event "*" which matches any event. And then
there is the problem of having the Handler annotation use an enum class
instead of Strings for the events. That would restrict statemachine to
only be able to work with the events in that enum. However, I certainly
think that using an enum for the possible events would be so much nicer
than using Strings. I'll see if I can come up with something which
allows the use of events in an enum without restricting the code to a
particular set of events.
/Niklas