View Poll Results: Do you use spring to handle your events?

Voters
5. You may not vote on this poll
  • Yes

    1 20.00%
  • No

    3 60.00%
  • I don't have events.

    1 20.00%
Page 1 of 2 12 LastLast
Results 1 to 10 of 22

Thread: Springs Event framework...

Hybrid View

  1. #1

    Lightbulb Springs Event framework...

    I have seen plenty of post saying that the buit-in event framework
    is not ideal, is not robust enough... I have found it to be everything
    that I need. Here is what I have used:

    I have created one class to delegate events by the type
    of class the event is, this helper has a map of ApplicationListener(s).

    Code:
    public class ApplicationEventHandler implements ApplicationListener
    {
       private HashMap applicationListeners = new HashMap(2);
    
       public void addApplicationListener(Class klass, ApplicationListener applicationListener)
       {
          applicationListeners.put(klass, applicationListener);
       }
    
       public void addAsynchronousApplicationListener(Class klass, ApplicationListener applicationListener)
       {
          applicationListeners.put(klass, new AsynchronousApplicationListener(applicationListener));
       }
    
       /**
        * @see org.springframework.context.ApplicationListener#onApplicationEvent(org.springframework.context.ApplicationEvent)
        */
       public synchronized void onApplicationEvent(ApplicationEvent event)
       {
          ApplicationListener applicationListener = (ApplicationListener) applicationListeners.get(event.getClass());
          if (applicationListener != null)
          {
             applicationListener.onApplicationEvent(event);
          }
       }
    }
    Then in a MyAbstractView that extends AbstractView I initialize an instance of the above class and call it in the onApplicationEvent method.
    Code:
    public void onApplicationEvent(ApplicationEvent event)
       {
          applicationEventHandler.onApplicationEvent(event);
       }
    Then in my view class which extends MyAbstractView I implement ApplicationListener, which registers this class in the spring event
    framework. I then add a listener to handle the OnDeckEvent.
    Code:
    public class DraftStatusView extends MyAbstractView implements ApplicationListener I can register a listener to the OnDeckEvent.
    {
      ...
       public void initActionCommandExecutor()
       {
          getApplicationEventHandler().addApplicationListener(OnDeckEvent.class, new ApplicationListener()
          {
             public void onApplicationEvent(ApplicationEvent _event)
             {
                OnDeckEvent event = (OnDeckEvent) _event;
                pick.setText(event.getSelection().getCoach().getName());
                secondsLeft = 180;
                if (!timer.isRunning())
                {
                   timer.start();
                }
             }
          });
       }
    I have found this to meet all my needs. Am I missing out on something by using this simple solution?

  2. #2
    Join Date
    Aug 2004
    Location
    San Francisco
    Posts
    423

    Default

    I'm one of the people who've mentioned that I don't use the spring event mechanism, instead I'm using the event listener framework at https://elf.dev.java.net/

    I ended up using ELF when my initial use of the spring event mechanism was getting messy. I realised I'd have to come up a better solution and I found this project and haven't looked back really. Are you missing out on something? Hard to say, your solution is pretty elegant and it you're happy with it I'd continue using it unless you have a good reason not to.

    I'll list some things I've found I like about using ELF that isn't there in the solution you mentioned.

    First, it allows you to define concrete event classes, each with their own listener and it takes care of the routing for you. So, looking at which listeners interfaces your classes implement it's obvious which events they are responding to. In addition, it allows each event to have types and enables each type to be handled by a specific method within the listener. This mirrors the swing events, like MouseEvent, in which each listener method reflects a specific type of mouse event. I find way of defining events, listeners and event types allows for easy symantic grouping of events making code responding to multiple, similar events easy to understand. On the other hand, not all events fall into categories that are easy to group symatically.

    Another feature that I've just come across the need for is what the author calls foldable events which means multiple instances of the same event happening rapidly can be "folded" into one (or a smaller number) to save having to process irrelevent events. This is going to be really useful for a use case that came up this week.

    hope that was useful,

    Jonny

  3. #3
    Join Date
    Oct 2005
    Posts
    29

    Default

    Quote Originally Posted by jwray
    I'm one of the people who've mentioned that I don't use the spring event mechanism, instead I'm using the event listener framework at https://elf.dev.java.net/

    Jonny
    Do you use ELF with spring-rcp?

  4. #4

    Default jwray does, I have yet to need the extra depend and complexity.

    jwray does, I have yet to need the extra depend and complexity.

  5. #5
    Join Date
    Oct 2005
    Posts
    29

    Default

    I am lost. I am still new to spring-rcp. When you say "spring event mechanism", you mean event mechanism of spring core? It seems that spring-rcp doesn't define its own event mechanism.
    And if we use elf or other swing event frameworks, will they conflict which spring's?

  6. #6

    Default EventBus

    FYI, I'm the author of the EventBus (http://eventbus.dev.java.net) another event alternative. I'm just starting to look into where the EventBus (and ELF and similar) fit in to Spring Rich. I've been watching Spring Rich for a while, but only now have gotten a chance to play with it. I'll see if I can find the limitations mentioned in the discussion groups and issues.

    Michael

  7. #7

    Default conflict

    Quote Originally Posted by siberian
    I am lost. I am still new to spring-rcp. When you say "spring event mechanism", you mean event mechanism of spring core? It seems that spring-rcp doesn't define its own event mechanism.
    And if we use elf or other swing event frameworks, will they conflict which spring's?
    Conflict is not the right word, redundant would be better. I chose to use spring because it fit my needs, and I have yet to investigate the alts. I would use springs as a starting point, then move to elf or eventbus if you have specfic needs to be met. As long as you are using one you will be fine.

  8. #8
    Join Date
    Aug 2004
    Location
    San Francisco
    Posts
    423

    Default

    To answer the question above, yes, I'm using ELF with Spring RCP.

    You are correct, Spring RCP does not define it's own event mechanism, we're refering to the mechanism within spring core.

    ELF and Spring's event mechanism do not conflict. They overlap in functionality. You could use both within one application, although I don't know why you'd want to. I'd tend to agree with mlavwilson2. Use Spring's event mechanism until you find a reason not to. I went to ELF when I realized my event handling code was getting too messy and I realized ELF fit my needs.


    Quote Originally Posted by siberian
    I am lost. I am still new to spring-rcp. When you say "spring event mechanism", you mean event mechanism of spring core? It seems that spring-rcp doesn't define its own event mechanism.
    And if we use elf or other swing event frameworks, will they conflict which spring's?

  9. #9
    Join Date
    Aug 2004
    Posts
    229

    Default

    Spring-rich should take the same approach in this regard as Spring does. Take ORM, for example. Spring does not provide an ORM implementation at all. Instead, what Spring does is make it very easy for you to integrate with other 3rd party ORMs. So, I have easy ways to use JDBC directly, easy ways to use Hibernate, TopLink, etc. Transaction management in Spring is another example, and goes even further in that Spring provides a simple interface (facade) for the transaction management needed in most business apps, but, again, Spring itself does not provide a transaction manager implementation. It simply allows you to plug into other 3rd party transaction managers: JBoss, JOTM, Geronimo, BEA, etc.
    Why shouldn't Spring-rich take the same approach? Provide easy ways to integrate event needs with 3rd party event libraries. It could take either the Spring ORM style approach (where it provides utility and helper classes to integrate with ELF, eventbus, Spring app events, etc), or the Spring TransactionManager approach where it provides an event abstraction and adapters to plug in 3rd party event libraries.
    Maybe we need a 4th option on the vote: support for 3rd party implementations

  10. #10
    Join Date
    Oct 2005
    Posts
    29

    Default

    what about JMS? It seems to me that JMS can do stuffs these "event bus" are doing?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •