I agree with you on your points. In general, annotations always have higher degrees of code complexity but can play a useful role for simplifying user code.
The code has one intent--making message listening registration easier. Annotate a method with @MessageListener and it is automatically registered with the application context for listening. The trade-off is that you have to call the annotation processor yourself or arrange to have it called elsewhere so the annotation is discovered. Just as the serializer scans for @WTKX annotations, someone has to scan. I think simplicity is a key to success but if its too simple, you are actually shifting complexity and cost to the client of your library which may or may not be the right thing. I'm not claiming that this is the case for @MessageListener, but a general thought similar to yours. If it doesn't fit, I'm okay with that. But if its not proposed, you don't have an opportunity to stake out the position of pivot. I've written this type of code before since this is a common feature, so my effort was actually very small, about 30 min for the three classes. If it took a bigger effort I would probably never propose it as part of pivot because I would never get around to writing it and seeing if it potentially fits into pivot. I'll add some more to the documentation but the intent above is the short version. -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Sunday, June 20, 2010 10:55 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 I want to add that I appreciate the effort you have put into this code. You are clearly investing a significant amount of time in PivotPad, and I'm looking forward to seeing the result (if you are willing to share it). The thing I am struggling with is what, to me, seems like a relatively high level of complexity. Pivot features are meant to be as easy to understand and use as possible. That means that they should also be easy to describe, so that developers can readily grasp the details and become productive quickly. So far, I haven't found that to be the case with some of the approaches you have suggested - I don't immediately "get it". We don't want developers to have to struggle to understand a concept. It is possible that I'm just being unusually dense, or that you may be able to describe the features in simpler terms such that they are more easily digested. Or, these features may simply be too complex for inclusion in the framework. I definitely do not want to discourage you from continuing to submit code, patches, etc. but just want to suggest that simplicity is key in Pivot. Any changes made to the platform should have a clear benefit and should fit in cleanly with the existing structures and APIs. If that's not the case, it doesn't necessarily mean that the code isn't useful or valuable - it just means that it probably doesn't belong in the platform. Thanks again. Hope this helps. Greg On Jun 20, 2010, at 10:38 AM, Greg Brown wrote: > Need to see usage examples. It is difficult to understand what these classes are meant to do without seeing how they are supposed to be applied. The "design doc" will probably help here. > > Either way, I don't think we'd want to include support for weak references, and I'm not sure we need to do anything special to increase the granularity of the topic subscriptions. A topic is just a class - it is up to the app to decide how coarsely or finely to define those classes to meet the needs of the application. > > On Jun 20, 2010, at 10:08 AM, aappddeevv wrote: > >> Here's the code that I am using. Not all the corner cases have tested out >> yet, but this is the general idea. >> >> The one thing that could become a concern about the messaging in the >> application context is how to filter messages efficiently on more than just >> class type-which is large grained filtering. But its not a problem now so >> fine-grained filtering can be in a message listener subclass or in the >> annotated method itself. >> >> >> >> -----Original Message----- >> From: Greg Brown (JIRA) [mailto:j...@apache.org] >> Sent: Sunday, June 20, 2010 9:45 AM >> To: dev@pivot.apache.org >> Subject: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation and >> an annotation processor for application context message listener >> >> >> [ >> https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plug >> in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880636#action_1 >> 2880636 ] >> >> Greg Brown commented on PIVOT-535: >> ---------------------------------- >> >> Agreed re: weak listeners - not a good idea. >> >> Appddevv, >> >> Can you provide a description of how these new features would work, >> including code examples? I'd also like to understand how the annotation >> processing would work and where it would live (basically, I am looking for a >> mini "design spec" for what you are proposing). >> >> Thanks, >> Greg >> >> >> >>> Add a @MessageListener annotation and an annotation processor for >> application context message listener >>> >> ---------------------------------------------------------------------------- >> -------------------------- >>> >>> Key: PIVOT-535 >>> URL: https://issues.apache.org/jira/browse/PIVOT-535 >>> Project: Pivot >>> Issue Type: Improvement >>> Reporter: Appddevvv >>> >>> Add a message listener annotation and a static method for annotation >> processing to automatically enroll instance/methods in application message >> handling. >>> I have the classes that I can submit as a starting point. They allow weak >> and strong references as well as optional request-reply semantics. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> <message-listener.zip> >
