I think that's fair to do. -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Monday, June 21, 2010 2:11 PM To: dev@pivot.apache.org Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation and an annotation processor for application context message listener
It doesn't necessarily need to be used by other parts of the framework to go in pivot-core. It just needs to be generally useful and not have any dependencies on the other libraries. I'm not sure what else, if anything, I would want it to do - it is really only meant to provide simple intra-application messaging services without a lot of overhead or the need for an external library. One advantage to moving it to org.apache.pivot.util is that listener implementations would not require so much typing (MessageBusListener is shorter than ApplicationContextMessageListener). Also, since (like WTKXSerializer) it isn't strictly dependent on WTK, it probably does not belong there. G On Jun 21, 2010, at 11:53 AM, aappddeevv wrote: > Yes. But I would leave it there for now. For simple messaging it is > sufficient. More thought is needed. My current thinking is that unless it > used by pivot internally, and hence drives need & evolution, it could be > better to use something else. > > > -----Original Message----- > From: Greg Brown [mailto:gkbr...@mac.com] > Sent: Monday, June 21, 2010 9:52 AM > To: dev@pivot.apache.org > Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation > and an annotation processor for application context message listener > >> One thing I am finding is for annotations and auto-registering, that the >> machinery dominates the actual messaging code in ApplicationContext. > > ApplicationContext is large, but the message handling code itself is pretty > small - it is just a few methods: > > subscribe() > unsubscribe() > sendMessage() > queueMessage() > > I have actually been wondering if it might make sense to move it to a core > class, such as org.apache.pivot.util.MessageBus so that non-UI applications > can also use it. The only thing specific to WTK is queueMessage(), but that > could either remain in ApplicationContext and be implemented in terms of > MessageBus, or it could potentially be eliminated - the code in that method > could easily be implemented at the application level. >
