Agreed on your points which are very thoughtful. Strong references do not automatically lead to bloat, but like weak references, issues arise if things are done un-thoughtfully. Let me play around with it. I am not advocating using weak references when using the message API at all. Its possible that it is useful in some internal book-keeping but lets not dwell on it until the revision is done. I agree that if clients use it without thinking, there are these issues to deal with.
One thing I am finding is for annotations and auto-registering, that the machinery dominates the actual messaging code in ApplicationContext. If the real usage patterns need to be something more robust for an application and require so much external machinery (even if added to pivot) its easier to use EventBus (3rd party) and allow messages to flow from pivot using an adapter. I've stop coding on it until I think this through. Since pivot is observer-listener dominated, and the usage of messaging is not a dominate communication approach, then all of this may be best handled differently. -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Monday, June 21, 2010 8:57 AM To: [email protected] Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation and an annotation processor for application context message listener There are a number of issues with weak references that, IMO, make them unsuitable for event registration. As Noel noted, they can easily disappear, causing developer confusion. This is true even for non-anonymous listener classes: something.addListener(new ConcreteListener()); If the registering class itself implements the listener interface, this may not be as much of a problem (assuming that another reference to this is maintained elsewhere): something.addListener(this); However, the down side to this approach is that the listener methods are now exposed in the class's public API. This breaks encapsulation and pollutes the API. Inner classes allow the listener to call private handlers in the outer class, which preserves encapsulation. However, they are prone to the issue mentioned in Noel's original email. I don't think it is accurate to say that "strong references lead to memory bloat". Developers simply need to be cognizant that, if a listener is added, it must also be removed. In most cases, this isn't a problem, because the lifetime of the listener parallels the lifetime of the event-firing object. Because the other cases are more rare, manually removing references should be easily manageable. G On Jun 20, 2010, at 7:12 PM, aappddeevv wrote: > Sandro, > > Thanks. BTW, I think that anytime you touch annotations, it always seems to > involve larger, more complex code and I understand the concern. Just on > those grounds is sufficient reason to not include it. > > With regard to weak listeners, I believe that we are talking about two > different areas of registration of message listeners. Under the proposal, > its not an anonymous class that is being weakly referenced but just the > target instance that has the annotated method. The current code has weak > references or strong, they are both in there. But I really do think we are > talking about two different objects in this conversation. > > For message processing, sometimes the opposite is true--strong references > lead to memory bloat due to not cleaning up resources correctly especially > when you register into a singleton static object. I'll spin another version > and add some comments. Because of the briefness of the subscribe/unsubscribe > interface in the application context, a small amount of machinery has to be > added that helps with listener subscription and unsubscription. > > > > -----Original Message----- > From: Sandro Martini (JIRA) [mailto:[email protected]] > Sent: Sunday, June 20, 2010 4:48 PM > To: [email protected] > 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=12880671#action_1 > 2880671 ] > > Sandro Martini commented on PIVOT-535: > -------------------------------------- > > Hi to all, > I like the proposal, and generally speaking anything that could help to > simplify/extend user code in a simpler way. > But I agree that I'd like to exclude code too complex to mantain or too > "foreign" respect to Pivot philosophy. > > So, what do you think on an initial (experimental) version without weak > listeners ? > > > And finally, Appddevvv, thank you for sharing/discuss with us many things > and improvements on Pivot. > > Bye, > Sandro > > >> 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. >
