You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by "Appddevvv (JIRA)" <ji...@apache.org> on 2010/06/19 22:18:23 UTC
[jira] Created: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
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.
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
And so the argument is to base your design on a garbage collection scheme that may or may not be employed by the currently installed JVM, simply to avoid calling removeListener() in the few cases that the lifetime of the listener isn't itself tied to the lifetime of the component? That's doesn't seem like sound development advice to me. Might as well time some for loops to see how many iterations your animation should run for while you're at it. ;-)
I can potentially see an argument for weak references in a message bus framework where there is no component that will be garbage collected and thus reclaim the listener as well. So maybe it is worth considering there. But I certainly don't see that as a valid argument against using strong listeners elsewhere.
On Jun 22, 2010, at 8:59 AM, Noel Grandin wrote:
>
> It was quite a while ago that I tried, probably around JDK 1.2.2.
>
> I've only ever run across a couple of memory leaks related to strong
> listeners, and they were dead-easy to find and kill - just follow the
> this$0 reference.
>
> Weak listeners on the other hand, manifested as UI controls that would
> work for a while, and then stop listening. Which was a major pain to
> find and fix.
>
> You're right - this is much less of a problem with modern VM's because
> the GC strategy so aggressively collects short-lived objects.
>
> -- Noel Grandin
>
> Michael Bushe wrote:
>> How long ago was that experience with weak listeners? VMs since 1.5
>> (maybe 1.4) would collect a weak listener before the next statement
>> after subscribe() executes. Try to get a test to pass with a weak
>> listener, it's been a long time since I've seen it.
>>
>> Even if that were not true, failing after a few minutes is a lot
>> better than a memory leak as slow to close as the BP's Gulf Gusher.
>>
>> Michael Bushe
>> Principal
>> Bushe Enterprises, Inc.
>> michael@bushe.com <ma...@bushe.com>
>> www.bushe.com <http://www.bushe.com>
>> www.mindfulsoftware.com <http://www.mindfulsoftware.com>
>> www.eventbus.org <http://www.eventbus.org>
>>
>>
>> On Tue, Jun 22, 2010 at 2:59 AM, Noel Grandin <noelgrandin@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hi
>>
>> Unfortunately, weak listeners don't "fail fast". In my experience,
>> with
>> large applications, weak listeners generally take a couple of
>> minutes to
>> fail, which makes them quite painful to track down.
>>
>> I think the reason you don't see this issue is because your primary
>> pattern doesn't use anonymous inner classes.
>>
>> But yes, I can see how weak listeners will make life-cycle management
>> easier when your listeners are methods on a normal class.
>>
>> -- Noel Grandin
>>
>> Michael Bushe wrote:
>>> In my experience in supporting users of the EventBus, in both
>> the open
>>> source world and in professional teams, weak references are not
>> something to
>>> be feared. This is because:
>>> 1) Weak references fail fast.
>>> 2) Weak reference semantics can be documented. Make the API's
>> clear, make
>>> the doc clear, make the examples clear. Document the
>> anti-pattern, put it
>>> in the FAQ.
>>> 3) Assume your users are smarter than you might think.
>> WeakReferences are
>>> pretty easy to understand. Even if a rookie doesn't understand
>> them, you
>>> can make it a teachable moment.
>>> 4) WeakReferences are clean and simple. Managaging listener
>> lifecycle is
>>> like managing memory in C- it a buggy job that sucks
>> productivity and bloats
>>> code.
>>> 5) In the 6 years of the EventBus' life, only one user posted a
>> "this
>>> doesn't work" question because they didn't RTFM.
>>>
>>> Greg, you didn't detail many of the "number of issues" with
>> WeakReferences,
>>> so I'm not sure what the perception is, but in my experience
>> WeakReferences
>>> are better since the lifecycle of the listener is generally (90%+)
>>> equivalent to the lifecycle of the component that defines the
>> listener.
>>>
>>> One issue mentioned is the use of an anonymous inner class (a
>> questionable
>>> pattern anyway), but when annotations are available users
>> generally use that
>>> more terse route rather than using an anonymous class. When
>> developers use
>>> the anonymous class anti-pattern, it fails quickly and they
>> change it -
>>> often forcing them to think about garbage collection in their
>> apps, which is
>>> a great thing. The corollary of using .subscribe(new
>> XXXSubscriber()) is
>>> even worse when using strong references - without a reference it's
>>> impossible to clean up.
>>>
>>> I think the encapsulation argument is extremely weak. Firstly,
>> most UI
>>> developers don't care too much about building extensible
>> classes, but even
>>> when they do, I prefer the opposite effect: Each method that is
>> annotated as
>>> a subscriber becomes part of the contract of the component.
>> This is a form
>>> of programming by contract that is very powerful. It says,
>> "whenever this
>>> event is fired, I'm going to call this method." Derived classes can
>>> manipulate the behavior as needed. Hiding it is equivalent to
>> the static
>>> final listeners that are all over the Swing framework - it stops
>> extension
>>> and customization in it's tracks. I went into this pub/sub
>>> programming-by-contract method quite a bit in the
>>>
>> article<http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts>I
>>> wrote on the EventBus+Pivot. Lastly, if you don't like that
>> idea, you
>>> can
>>> easily create private fields that are listeners.
>>>
>>> The best argument for weak references is that strong references
>> generally
>>> suck. Strong references have the opposite effects listed above:
>>> 1) Strong references cause memory "leaks" that don't fail fast.
>> They fail
>>> very slowly and insiduously. They are often not caught until
>> production.
>>> 2) Strong reference issues are hard to document.
>>> 3) Even smart, experienced developers wind up wasting hours or
>> days tracking
>>> down memory leaks before they find the culprit.
>>> 4) Lifecycle management of listeners is not always easy. It is
>> error prone
>>> and bloats code. Even in the easy cases, it's easily forgotten and
>>> difficult to test for.
>>>
>>> Note: The Spring ActionScript EventBus shifted (is shifting?) from
>>> defaulting to strong to defaulting to weak.
>>>
>>> I look forward to seeing how the MessageBus API develops.
>>>
>>> Michael Bushe
>>> Principal
>>> Bushe Enterprises, Inc.
>>> michael@bushe.com <ma...@bushe.com>
>>> www.bushe.com <http://www.bushe.com>
>>> www.mindfulsoftware.com <http://www.mindfulsoftware.com>
>>> www.eventbus.org <http://www.eventbus.org>
>>>
>>> On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv
>> <aappddeevv@verizon.net <ma...@verizon.net>> wrote:
>>>
>>>
>>>> I think that's fair to do.
>>>>
>>>> -----Original Message-----
>>>> From: Greg Brown [mailto:gkbrown@mac.com <ma...@mac.com>]
>>>> Sent: Monday, June 21, 2010 2:11 PM
>>>> To: dev@pivot.apache.org <ma...@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:gkbrown@mac.com <ma...@mac.com>]
>>>>> Sent: Monday, June 21, 2010 9:52 AM
>>>>> To: dev@pivot.apache.org <ma...@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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Noel Grandin <no...@gmail.com>.
It was quite a while ago that I tried, probably around JDK 1.2.2.
I've only ever run across a couple of memory leaks related to strong
listeners, and they were dead-easy to find and kill - just follow the
this$0 reference.
Weak listeners on the other hand, manifested as UI controls that would
work for a while, and then stop listening. Which was a major pain to
find and fix.
You're right - this is much less of a problem with modern VM's because
the GC strategy so aggressively collects short-lived objects.
-- Noel Grandin
Michael Bushe wrote:
> How long ago was that experience with weak listeners? VMs since 1.5
> (maybe 1.4) would collect a weak listener before the next statement
> after subscribe() executes. Try to get a test to pass with a weak
> listener, it's been a long time since I've seen it.
>
> Even if that were not true, failing after a few minutes is a lot
> better than a memory leak as slow to close as the BP's Gulf Gusher.
>
> Michael Bushe
> Principal
> Bushe Enterprises, Inc.
> michael@bushe.com <ma...@bushe.com>
> www.bushe.com <http://www.bushe.com>
> www.mindfulsoftware.com <http://www.mindfulsoftware.com>
> www.eventbus.org <http://www.eventbus.org>
>
>
> On Tue, Jun 22, 2010 at 2:59 AM, Noel Grandin <noelgrandin@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi
>
> Unfortunately, weak listeners don't "fail fast". In my experience,
> with
> large applications, weak listeners generally take a couple of
> minutes to
> fail, which makes them quite painful to track down.
>
> I think the reason you don't see this issue is because your primary
> pattern doesn't use anonymous inner classes.
>
> But yes, I can see how weak listeners will make life-cycle management
> easier when your listeners are methods on a normal class.
>
> -- Noel Grandin
>
> Michael Bushe wrote:
> > In my experience in supporting users of the EventBus, in both
> the open
> > source world and in professional teams, weak references are not
> something to
> > be feared. This is because:
> > 1) Weak references fail fast.
> > 2) Weak reference semantics can be documented. Make the API's
> clear, make
> > the doc clear, make the examples clear. Document the
> anti-pattern, put it
> > in the FAQ.
> > 3) Assume your users are smarter than you might think.
> WeakReferences are
> > pretty easy to understand. Even if a rookie doesn't understand
> them, you
> > can make it a teachable moment.
> > 4) WeakReferences are clean and simple. Managaging listener
> lifecycle is
> > like managing memory in C- it a buggy job that sucks
> productivity and bloats
> > code.
> > 5) In the 6 years of the EventBus' life, only one user posted a
> "this
> > doesn't work" question because they didn't RTFM.
> >
> > Greg, you didn't detail many of the "number of issues" with
> WeakReferences,
> > so I'm not sure what the perception is, but in my experience
> WeakReferences
> > are better since the lifecycle of the listener is generally (90%+)
> > equivalent to the lifecycle of the component that defines the
> listener.
> >
> > One issue mentioned is the use of an anonymous inner class (a
> questionable
> > pattern anyway), but when annotations are available users
> generally use that
> > more terse route rather than using an anonymous class. When
> developers use
> > the anonymous class anti-pattern, it fails quickly and they
> change it -
> > often forcing them to think about garbage collection in their
> apps, which is
> > a great thing. The corollary of using .subscribe(new
> XXXSubscriber()) is
> > even worse when using strong references - without a reference it's
> > impossible to clean up.
> >
> > I think the encapsulation argument is extremely weak. Firstly,
> most UI
> > developers don't care too much about building extensible
> classes, but even
> > when they do, I prefer the opposite effect: Each method that is
> annotated as
> > a subscriber becomes part of the contract of the component.
> This is a form
> > of programming by contract that is very powerful. It says,
> "whenever this
> > event is fired, I'm going to call this method." Derived classes can
> > manipulate the behavior as needed. Hiding it is equivalent to
> the static
> > final listeners that are all over the Swing framework - it stops
> extension
> > and customization in it's tracks. I went into this pub/sub
> > programming-by-contract method quite a bit in the
> >
> article<http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts>I
> > wrote on the EventBus+Pivot. Lastly, if you don't like that
> idea, you
> > can
> > easily create private fields that are listeners.
> >
> > The best argument for weak references is that strong references
> generally
> > suck. Strong references have the opposite effects listed above:
> > 1) Strong references cause memory "leaks" that don't fail fast.
> They fail
> > very slowly and insiduously. They are often not caught until
> production.
> > 2) Strong reference issues are hard to document.
> > 3) Even smart, experienced developers wind up wasting hours or
> days tracking
> > down memory leaks before they find the culprit.
> > 4) Lifecycle management of listeners is not always easy. It is
> error prone
> > and bloats code. Even in the easy cases, it's easily forgotten and
> > difficult to test for.
> >
> > Note: The Spring ActionScript EventBus shifted (is shifting?) from
> > defaulting to strong to defaulting to weak.
> >
> > I look forward to seeing how the MessageBus API develops.
> >
> > Michael Bushe
> > Principal
> > Bushe Enterprises, Inc.
> > michael@bushe.com <ma...@bushe.com>
> > www.bushe.com <http://www.bushe.com>
> > www.mindfulsoftware.com <http://www.mindfulsoftware.com>
> > www.eventbus.org <http://www.eventbus.org>
> >
> > On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv
> <aappddeevv@verizon.net <ma...@verizon.net>> wrote:
> >
> >
> >> I think that's fair to do.
> >>
> >> -----Original Message-----
> >> From: Greg Brown [mailto:gkbrown@mac.com <ma...@mac.com>]
> >> Sent: Monday, June 21, 2010 2:11 PM
> >> To: dev@pivot.apache.org <ma...@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:gkbrown@mac.com <ma...@mac.com>]
> >>> Sent: Monday, June 21, 2010 9:52 AM
> >>> To: dev@pivot.apache.org <ma...@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.
> >>>
> >>>
> >>
> >>
> >
>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Michael Bushe <mi...@bushe.com>.
How long ago was that experience with weak listeners? VMs since 1.5 (maybe
1.4) would collect a weak listener before the next statement after
subscribe() executes. Try to get a test to pass with a weak listener, it's
been a long time since I've seen it.
Even if that were not true, failing after a few minutes is a lot better than
a memory leak as slow to close as the BP's Gulf Gusher.
Michael Bushe
Principal
Bushe Enterprises, Inc.
michael@bushe.com
www.bushe.com
www.mindfulsoftware.com
www.eventbus.org
On Tue, Jun 22, 2010 at 2:59 AM, Noel Grandin <no...@gmail.com> wrote:
> Hi
>
> Unfortunately, weak listeners don't "fail fast". In my experience, with
> large applications, weak listeners generally take a couple of minutes to
> fail, which makes them quite painful to track down.
>
> I think the reason you don't see this issue is because your primary
> pattern doesn't use anonymous inner classes.
>
> But yes, I can see how weak listeners will make life-cycle management
> easier when your listeners are methods on a normal class.
>
> -- Noel Grandin
>
> Michael Bushe wrote:
> > In my experience in supporting users of the EventBus, in both the open
> > source world and in professional teams, weak references are not something
> to
> > be feared. This is because:
> > 1) Weak references fail fast.
> > 2) Weak reference semantics can be documented. Make the API's clear,
> make
> > the doc clear, make the examples clear. Document the anti-pattern, put
> it
> > in the FAQ.
> > 3) Assume your users are smarter than you might think. WeakReferences
> are
> > pretty easy to understand. Even if a rookie doesn't understand them, you
> > can make it a teachable moment.
> > 4) WeakReferences are clean and simple. Managaging listener lifecycle is
> > like managing memory in C- it a buggy job that sucks productivity and
> bloats
> > code.
> > 5) In the 6 years of the EventBus' life, only one user posted a "this
> > doesn't work" question because they didn't RTFM.
> >
> > Greg, you didn't detail many of the "number of issues" with
> WeakReferences,
> > so I'm not sure what the perception is, but in my experience
> WeakReferences
> > are better since the lifecycle of the listener is generally (90%+)
> > equivalent to the lifecycle of the component that defines the listener.
> >
> > One issue mentioned is the use of an anonymous inner class (a
> questionable
> > pattern anyway), but when annotations are available users generally use
> that
> > more terse route rather than using an anonymous class. When developers
> use
> > the anonymous class anti-pattern, it fails quickly and they change it -
> > often forcing them to think about garbage collection in their apps, which
> is
> > a great thing. The corollary of using .subscribe(new XXXSubscriber()) is
> > even worse when using strong references - without a reference it's
> > impossible to clean up.
> >
> > I think the encapsulation argument is extremely weak. Firstly, most UI
> > developers don't care too much about building extensible classes, but
> even
> > when they do, I prefer the opposite effect: Each method that is annotated
> as
> > a subscriber becomes part of the contract of the component. This is a
> form
> > of programming by contract that is very powerful. It says, "whenever
> this
> > event is fired, I'm going to call this method." Derived classes can
> > manipulate the behavior as needed. Hiding it is equivalent to the static
> > final listeners that are all over the Swing framework - it stops
> extension
> > and customization in it's tracks. I went into this pub/sub
> > programming-by-contract method quite a bit in the
> > article<
> http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts
> >I
> > wrote on the EventBus+Pivot. Lastly, if you don't like that idea, you
> > can
> > easily create private fields that are listeners.
> >
> > The best argument for weak references is that strong references generally
> > suck. Strong references have the opposite effects listed above:
> > 1) Strong references cause memory "leaks" that don't fail fast. They
> fail
> > very slowly and insiduously. They are often not caught until production.
> > 2) Strong reference issues are hard to document.
> > 3) Even smart, experienced developers wind up wasting hours or days
> tracking
> > down memory leaks before they find the culprit.
> > 4) Lifecycle management of listeners is not always easy. It is error
> prone
> > and bloats code. Even in the easy cases, it's easily forgotten and
> > difficult to test for.
> >
> > Note: The Spring ActionScript EventBus shifted (is shifting?) from
> > defaulting to strong to defaulting to weak.
> >
> > I look forward to seeing how the MessageBus API develops.
> >
> > Michael Bushe
> > Principal
> > Bushe Enterprises, Inc.
> > michael@bushe.com
> > www.bushe.com
> > www.mindfulsoftware.com
> > www.eventbus.org
> >
> > On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv <aa...@verizon.net>
> wrote:
> >
> >
> >> I think that's fair to do.
> >>
> >> -----Original Message-----
> >> From: Greg Brown [mailto:gkbrown@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:gkbrown@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.
> >>>
> >>>
> >>
> >>
> >
>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Noel Grandin <no...@gmail.com>.
Hi
Unfortunately, weak listeners don't "fail fast". In my experience, with
large applications, weak listeners generally take a couple of minutes to
fail, which makes them quite painful to track down.
I think the reason you don't see this issue is because your primary
pattern doesn't use anonymous inner classes.
But yes, I can see how weak listeners will make life-cycle management
easier when your listeners are methods on a normal class.
-- Noel Grandin
Michael Bushe wrote:
> In my experience in supporting users of the EventBus, in both the open
> source world and in professional teams, weak references are not something to
> be feared. This is because:
> 1) Weak references fail fast.
> 2) Weak reference semantics can be documented. Make the API's clear, make
> the doc clear, make the examples clear. Document the anti-pattern, put it
> in the FAQ.
> 3) Assume your users are smarter than you might think. WeakReferences are
> pretty easy to understand. Even if a rookie doesn't understand them, you
> can make it a teachable moment.
> 4) WeakReferences are clean and simple. Managaging listener lifecycle is
> like managing memory in C- it a buggy job that sucks productivity and bloats
> code.
> 5) In the 6 years of the EventBus' life, only one user posted a "this
> doesn't work" question because they didn't RTFM.
>
> Greg, you didn't detail many of the "number of issues" with WeakReferences,
> so I'm not sure what the perception is, but in my experience WeakReferences
> are better since the lifecycle of the listener is generally (90%+)
> equivalent to the lifecycle of the component that defines the listener.
>
> One issue mentioned is the use of an anonymous inner class (a questionable
> pattern anyway), but when annotations are available users generally use that
> more terse route rather than using an anonymous class. When developers use
> the anonymous class anti-pattern, it fails quickly and they change it -
> often forcing them to think about garbage collection in their apps, which is
> a great thing. The corollary of using .subscribe(new XXXSubscriber()) is
> even worse when using strong references - without a reference it's
> impossible to clean up.
>
> I think the encapsulation argument is extremely weak. Firstly, most UI
> developers don't care too much about building extensible classes, but even
> when they do, I prefer the opposite effect: Each method that is annotated as
> a subscriber becomes part of the contract of the component. This is a form
> of programming by contract that is very powerful. It says, "whenever this
> event is fired, I'm going to call this method." Derived classes can
> manipulate the behavior as needed. Hiding it is equivalent to the static
> final listeners that are all over the Swing framework - it stops extension
> and customization in it's tracks. I went into this pub/sub
> programming-by-contract method quite a bit in the
> article<http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts>I
> wrote on the EventBus+Pivot. Lastly, if you don't like that idea, you
> can
> easily create private fields that are listeners.
>
> The best argument for weak references is that strong references generally
> suck. Strong references have the opposite effects listed above:
> 1) Strong references cause memory "leaks" that don't fail fast. They fail
> very slowly and insiduously. They are often not caught until production.
> 2) Strong reference issues are hard to document.
> 3) Even smart, experienced developers wind up wasting hours or days tracking
> down memory leaks before they find the culprit.
> 4) Lifecycle management of listeners is not always easy. It is error prone
> and bloats code. Even in the easy cases, it's easily forgotten and
> difficult to test for.
>
> Note: The Spring ActionScript EventBus shifted (is shifting?) from
> defaulting to strong to defaulting to weak.
>
> I look forward to seeing how the MessageBus API develops.
>
> Michael Bushe
> Principal
> Bushe Enterprises, Inc.
> michael@bushe.com
> www.bushe.com
> www.mindfulsoftware.com
> www.eventbus.org
>
> On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv <aa...@verizon.net> wrote:
>
>
>> I think that's fair to do.
>>
>> -----Original Message-----
>> From: Greg Brown [mailto:gkbrown@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:gkbrown@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.
>>>
>>>
>>
>>
>
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
Folks, while interesting, I suggest we delay this conversation until later
when something is submitted. Then we can rally the conversation around some
concrete items.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Tuesday, June 22, 2010 10:30 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
AFAIK, EventBus doesn't have any dependencies on Pivot, nor vice versa.
There is also nothing in Pivot that would preclude a developer from using
EventBus in a Pivot app.
On Jun 22, 2010, at 10:09 AM, Noel Grandin wrote:
> Hi
>
> This argument seems to be running in circles a little.
>
> I personally don't particularly like the EventBus style of doing things,
> but I'm perfectly happy for people to pick their own style of development.
>
> I don't see that sufficient of the Pivot developers are sufficiently
> keen to make this part of the Pivot library itself (I could be wrong),
> but I don't anything that prevents people from using the EventBus
> library together with Pivot.
>
> (Am I correct? Does EventBus require any additional support from Pivot
> itself? It doesn't seem like it from what I read.)
>
> In which case I suggest that we mark this feature request as "Thanks,
> feel free to keep developing your idea, but we're not keen on
> incorporating it right now".
>
> -- Noel Grandin
>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
AFAIK, EventBus doesn't have any dependencies on Pivot, nor vice versa. There is also nothing in Pivot that would preclude a developer from using EventBus in a Pivot app.
On Jun 22, 2010, at 10:09 AM, Noel Grandin wrote:
> Hi
>
> This argument seems to be running in circles a little.
>
> I personally don't particularly like the EventBus style of doing things,
> but I'm perfectly happy for people to pick their own style of development.
>
> I don't see that sufficient of the Pivot developers are sufficiently
> keen to make this part of the Pivot library itself (I could be wrong),
> but I don't anything that prevents people from using the EventBus
> library together with Pivot.
>
> (Am I correct? Does EventBus require any additional support from Pivot
> itself? It doesn't seem like it from what I read.)
>
> In which case I suggest that we mark this feature request as "Thanks,
> feel free to keep developing your idea, but we're not keen on
> incorporating it right now".
>
> -- Noel Grandin
>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Noel Grandin <no...@gmail.com>.
Hi
This argument seems to be running in circles a little.
I personally don't particularly like the EventBus style of doing things,
but I'm perfectly happy for people to pick their own style of development.
I don't see that sufficient of the Pivot developers are sufficiently
keen to make this part of the Pivot library itself (I could be wrong),
but I don't anything that prevents people from using the EventBus
library together with Pivot.
(Am I correct? Does EventBus require any additional support from Pivot
itself? It doesn't seem like it from what I read.)
In which case I suggest that we mark this feature request as "Thanks,
feel free to keep developing your idea, but we're not keen on
incorporating it right now".
-- Noel Grandin
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
> This is dead wrong. If component A adds a subscriber and component A goes
> away, the subscriber must be removed.
That's only true if something else maintains a reference to the listener, which is generally not the case when using anonymous inner classes as listeners.
>> Anonymous inner classes are not a questionable design pattern...To me,
>> they are somewhat akin to closures, which
>> also seemed strange at first but are the cornerstone of many currently
>> popular languages.
>
> They aren't closures and a main motivation
> for getting Closures in Java is because anonymous inner classes are a
> suboptimal at best.
I didn't say they were closures - I said they were akin to closures. Also, at least one of the proposals for implementing closures in Java is effectively syntactic sugar around anonymous inner classes (though I'm not sure if that is the one that is actually being implemented for Java 7).
>> I am not familiar with techniques for using annotations to replace
>> anonymous inner classes. Can you provide some examples?
>
> There are a number of detailed examples in the article and demo I wrote on
> Pivot and the EventBus and sent to you a few months ago. Did you read it
> yet?
I read it. I did not memorize it.
>>> I think the encapsulation argument is extremely weak. Firstly, most UI
>>> developers don't care too much about building extensible classes
>>
>> It's not a question of extensibility - it is about method visibility. When
>> your class implements an interface, all listener methods by necessity become
>> public.
>
> This is a good design since it allows the component to be tested in
> isolation.
It is not good design. It breaks encapsulation, and thus violates a basic OO principle. You should not be making a list selection change listener part of your public API, for example. It allows an arbitrary caller to simulate a change event, which may leave your class in an inconsistent state.
If you want to test something in isolation, you can make the methods package private and create a JUnit test that lives in the same package.
> Besides, if you use annotations, you don't need to implement an interface.
And thus lose the compile-time benefits of using an interface.
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Michael Bushe <mi...@bushe.com>.
On Tue, Jun 22, 2010 at 8:57 AM, Greg Brown <gk...@mac.com> wrote
> > in my experience WeakReferences
> > are better since the lifecycle of the listener is generally (90%+)
> > equivalent to the lifecycle of the component that defines the listener.
>
> I mentioned this in my previous email, and I think it is actually a much
> stronger argument for strong references: In this case, you don't need to
> worry about unregistering the listener anyways, so weak references add
> almost no value.
>
>
This is dead wrong. If component A adds a subscriber and component A goes
away, the subscriber must be removed.
Take out pub/sub and it's still wrong: If component A adds a listener to
component B and component A goes away, the listener must be removed.
THE SUBSCRIBER HAS THE SAME LIFECYCLE AS THE COMPONENT.
> Anonymous inner classes are not a questionable design pattern. They have a
> valid use case in event handling, also described in my previous email. Once
> you get used to the syntax (which I'll admit seemed a bit strange at first),
> they become quite useful. To me, they are somewhat akin to closures, which
> also seemed strange at first but are the cornerstone of many currently
> popular languages.
Huh? Just because you don't question them doesn't mean they are not
questionable. Lots of other people question them. Google it if you are
interested in what other people think. Personally, I've written hundreds of
them so I'm "used to the syntax." They aren't closures and a main motivation
for getting Closures in Java is because anonymous inner classes are a
suboptimal at best.
> > when annotations are available users generally use that
> > more terse route rather than using an anonymous class.
>
> I am not familiar with techniques for using annotations to replace
> anonymous inner classes. Can you provide some examples?
>
There are a number of detailed examples in the article and demo I wrote on
Pivot and the EventBus and sent to you a few months ago. Did you read it
yet?
>
> > I think the encapsulation argument is extremely weak. Firstly, most UI
> > developers don't care too much about building extensible classes
>
> It's not a question of extensibility - it is about method visibility. When
> your class implements an interface, all listener methods by necessity become
> public. Any other class can now invoke the listener method, effectively
> spoofing the event. This is a poor design that inner classes allow you to
> avoid.
>
This is a good design since it allows the component to be tested in
isolation. Spoofing events is sometimes a nice way to get things done in
normal (non-test) development too. Encapsulation in UI development is way
overrated. There's already so much exposed just by extending a base class.
Besides, if you use annotations, you don't need to implement an interface.
>
> Also, if your class needs to respond to multiple events, it must now
> implement multiple interfaces. This further bloats its public API and
> exposes it to additional misuse.
>
Most components already implement a ton of interfaces and adding more to
describe all the responsibilities of a class is better than trying to hide a
bloated class with a lot of hidden features. Besides, if you use
annotations, you don't need to implement an interface.
>
> > Lastly, if you don't like that idea, you can easily create private fields
> that are listeners.
>
> I'm not sure how you could do this without inner classes.
>
> They would be inner classes, but since they are fields, they are not
anonymous and thus are lifecycle'd with the component.
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
> Greg, you didn't detail many of the "number of issues" with WeakReferences,
Most of them are related to different approaches we might take to support weak references - I left them out because there are other stronger arguments against weak references and didn't want to muddy the rest of the email.
> in my experience WeakReferences
> are better since the lifecycle of the listener is generally (90%+)
> equivalent to the lifecycle of the component that defines the listener.
I mentioned this in my previous email, and I think it is actually a much stronger argument for strong references: In this case, you don't need to worry about unregistering the listener anyways, so weak references add almost no value.
> One issue mentioned is the use of an anonymous inner class (a questionable
> pattern anyway)
Anonymous inner classes are not a questionable design pattern. They have a valid use case in event handling, also described in my previous email. Once you get used to the syntax (which I'll admit seemed a bit strange at first), they become quite useful. To me, they are somewhat akin to closures, which also seemed strange at first but are the cornerstone of many currently popular languages.
> when annotations are available users generally use that
> more terse route rather than using an anonymous class.
I am not familiar with techniques for using annotations to replace anonymous inner classes. Can you provide some examples?
> I think the encapsulation argument is extremely weak. Firstly, most UI
> developers don't care too much about building extensible classes
It's not a question of extensibility - it is about method visibility. When your class implements an interface, all listener methods by necessity become public. Any other class can now invoke the listener method, effectively spoofing the event. This is a poor design that inner classes allow you to avoid.
Also, if your class needs to respond to multiple events, it must now implement multiple interfaces. This further bloats its public API and exposes it to additional misuse.
> Lastly, if you don't like that idea, you can easily create private fields that are listeners.
I'm not sure how you could do this without inner classes.
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Michael Bushe <mi...@bushe.com>.
In my experience in supporting users of the EventBus, in both the open
source world and in professional teams, weak references are not something to
be feared. This is because:
1) Weak references fail fast.
2) Weak reference semantics can be documented. Make the API's clear, make
the doc clear, make the examples clear. Document the anti-pattern, put it
in the FAQ.
3) Assume your users are smarter than you might think. WeakReferences are
pretty easy to understand. Even if a rookie doesn't understand them, you
can make it a teachable moment.
4) WeakReferences are clean and simple. Managaging listener lifecycle is
like managing memory in C- it a buggy job that sucks productivity and bloats
code.
5) In the 6 years of the EventBus' life, only one user posted a "this
doesn't work" question because they didn't RTFM.
Greg, you didn't detail many of the "number of issues" with WeakReferences,
so I'm not sure what the perception is, but in my experience WeakReferences
are better since the lifecycle of the listener is generally (90%+)
equivalent to the lifecycle of the component that defines the listener.
One issue mentioned is the use of an anonymous inner class (a questionable
pattern anyway), but when annotations are available users generally use that
more terse route rather than using an anonymous class. When developers use
the anonymous class anti-pattern, it fails quickly and they change it -
often forcing them to think about garbage collection in their apps, which is
a great thing. The corollary of using .subscribe(new XXXSubscriber()) is
even worse when using strong references - without a reference it's
impossible to clean up.
I think the encapsulation argument is extremely weak. Firstly, most UI
developers don't care too much about building extensible classes, but even
when they do, I prefer the opposite effect: Each method that is annotated as
a subscriber becomes part of the contract of the component. This is a form
of programming by contract that is very powerful. It says, "whenever this
event is fired, I'm going to call this method." Derived classes can
manipulate the behavior as needed. Hiding it is equivalent to the static
final listeners that are all over the Swing framework - it stops extension
and customization in it's tracks. I went into this pub/sub
programming-by-contract method quite a bit in the
article<http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts>I
wrote on the EventBus+Pivot. Lastly, if you don't like that idea, you
can
easily create private fields that are listeners.
The best argument for weak references is that strong references generally
suck. Strong references have the opposite effects listed above:
1) Strong references cause memory "leaks" that don't fail fast. They fail
very slowly and insiduously. They are often not caught until production.
2) Strong reference issues are hard to document.
3) Even smart, experienced developers wind up wasting hours or days tracking
down memory leaks before they find the culprit.
4) Lifecycle management of listeners is not always easy. It is error prone
and bloats code. Even in the easy cases, it's easily forgotten and
difficult to test for.
Note: The Spring ActionScript EventBus shifted (is shifting?) from
defaulting to strong to defaulting to weak.
I look forward to seeing how the MessageBus API develops.
Michael Bushe
Principal
Bushe Enterprises, Inc.
michael@bushe.com
www.bushe.com
www.mindfulsoftware.com
www.eventbus.org
On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv <aa...@verizon.net> wrote:
> I think that's fair to do.
>
> -----Original Message-----
> From: Greg Brown [mailto:gkbrown@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:gkbrown@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.
> >
>
>
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
I think that's fair to do.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@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:gkbrown@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.
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
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:gkbrown@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.
>
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
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:gkbrown@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.
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
> 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.
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
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:gkbrown@mac.com]
Sent: Monday, June 21, 2010 8:57 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
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:jira@apache.org]
> Sent: Sunday, June 20, 2010 4:48 PM
> 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=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.
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
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:jira@apache.org]
> Sent: Sunday, June 20, 2010 4:48 PM
> 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=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.
>
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
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:jira@apache.org]
Sent: Sunday, June 20, 2010 4:48 PM
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=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.
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
I think a regression entered into the code I just sent out on this...let me
resend or confirm before you look at it although the "design" is there.
-----Original Message-----
From: Greg Brown (JIRA) [mailto:jira@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.
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
Yes that's correct. That's one of the reasons why I have become less of a
fan around observer/listener semantics of any type lately and more towards
message-based communication for tree events/property changes, etc.
Anyway, that's fine. The annotation base class that I'll offer up as the
starting point allows the listener class to be specified so it can be
implemented as a subclass of the base listener class that is automatically
created to support annotations like this. The default can be a strong
subscription. At the same time, I'll mention that the default can be set to
strong so it takes a conscious choice to make it weak and there are a lot of
good weak use cases where having this would be nice. In this case, its all
about convenience.
-----Original Message-----
From: Noel Grandin (JIRA) [mailto:jira@apache.org]
Sent: Sunday, June 20, 2010 5:00 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=12880607#action_1
2880607 ]
Noel Grandin commented on PIVOT-535:
------------------------------------
See (some parts of) the earlier discussion we had about weak listeners here:
http://www.mail-archive.com/pivot-dev@incubator.apache.org/msg03847.html
Bottom line is that weak listeners are a bad idea.
> 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.
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
Here's the correction with the regression fixed.
-----Original Message-----
From: aappddeevv [mailto:aappddeevv@verizon.net]
Sent: Sunday, June 20, 2010 10:09 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
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:jira@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.
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
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:gkbrown@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:jira@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>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
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:jira@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>
>
Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by Greg Brown <gk...@mac.com>.
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:jira@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>
RE: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message listener
Posted by aappddeevv <aa...@verizon.net>.
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:jira@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.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880636#action_12880636 ]
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.
[jira] Updated: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Brown updated PIVOT-535:
-----------------------------
Fix Version/s: (was: 2.0)
> 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.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Sandro Martini (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880671#action_12880671 ]
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.
[jira] Updated: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Brown updated PIVOT-535:
-----------------------------
Fix Version/s: 2.0
> 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
> Fix For: 2.0
>
>
> 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.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881222#action_12881222 ]
Greg Brown commented on PIVOT-535:
----------------------------------
OK, I can see the value in the annotation processing. I imagine it would be accomplished via some static method in MessageBus, e.g.
public static void subscribe(Object listener)
This method would process the listener class's methods looking for annotations and subscribe to the appropriate topics - correct?
I can see adding support for weak references to the annotation, e.g.:
@MessageListener(weak=true)
I'm not as sure about message replies - how would that work with multiple listeners attached to the same topic? We do something like that with vetoable events right now, but we have a well-defined way for consolidating the return values (instances of Vote). I can't see how that would work for arbitrary objects.
Couple additional questions/comments:
1) We might want to rename @MessageListener to @MessageHandler. "MessageListener" implies that it is an event listener interface, whereas "handler" seems more appropriate for a method.
2) We should probably also provide additional static methods for managing weak listeners. These methods would be called via the static subscribe() method while processing the annotations. I was thinking earlier that adding a boolean "weak" argument to the subscribe() method would be sufficient, but I'm not sure what, if anything, that might mean for unsubscribe(). Thoughts?
> 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
> Fix For: 2.0
>
>
> 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.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880664#action_12880664 ]
Appddevvv commented on PIVOT-535:
---------------------------------
I've attached a design spec below. The posted code is a starting point but not a final answer. More thinking is needed around automatic unsubscribing. The issue of unsubscribing can be mostly handled using weak listeners *inside* the proposed general purpose message listener class. Weak listeners are safe inside the proposed message listener class associated with the annotation but robust thinking and examples will help flush out all use cases. They are safe as proposed but you can do without them with a little bit more code, they were an easy answer to the unsubscription problem to get a first cut out.
Pivot team, if you decide to keep this open, its okay if this gets bumped down on the priority list. I'll update the starting points that I sent out and post them.
Here's the spec:
Design Intent: To reduce code and improve line-of-sight into client intent when registering for application context messages in java. The motivation was based on the dev's list recommendation to look at pivot's message management capabilities and potentially use them, if appropriate, for decoupling sender and receivers. This was in response to some comments about EventBus somewhere in early 2010. The intent to make this easier in java is the same as allowing listener registration in the serializer in script. In some cases, its significantly easier and cleaner.
Examples:
Change code like this:
public class MyClass ... {
....
ApplicationContext.subscribe(MyTopic.class, new ApplicationContextMessageListener<MyTopic>() {
@Override
public void sentMessage(MyTopic arg) {
....
justDoIt(arg);
...
}
public void justDoIt(MyTopic arg) {
....
}
} ;
to:
public class MyClass ... {
public MyClass() {
MessageListenerAnnotationProcessor.process(this);
}
@MessageListener
public void justDoit(MyTopic arg) {
...
}
}
If you have more than one topic you are subscribing to within a class, the intent becomes more clear within that class. If you subclass the serializer, you can process this annotation on any object transparently but otherwise the annotation processor has to be called to scan the class. In the above example, it is shown being used in the constructor.
Design points:
a) Allow listener registration using annotations on a method.
b) Allow the option of strong or weak subscription. This refers to the proposed general message listener and *not* within the ApplicationContext itself. Default is weak. Most importantly, weak listener bad behavior is completely managed so it is less of an issue than with using inner anonymous classes. That's a plus. Also, strong references are not always perfect if you forget to unsubscribe. Both strong and weak have beneficial use cases and the code is nearly identical. Note that in the current form, you need to use a weak reference to the target object to allow it to unregister itself but that's because the starting point code examples were written quickly.
c) Allow the specification of the listener type when the annotation is processed. This allows you to create your own listener and move additional filtering and conditional logic out of your class and into the message handler. This makes it easier to address filtering. Class-level filtering can be fairly large-grained. In addition, it allows transparent add-ons and extensions to be added that are outside the scope of pivot's focus such as message logging, interception, filtering, queue control and proxying. This also allows other instantiation and initialization methods to be employed.
d) Support minimal reply-request behavior. This is also a common use of messages and the code is identical except for 2 lines in the implementation. This allows the user to write a method like below and translate messages without further reference to the application context. In fact, there are no references to the application context, message listeners or other pivot elements.
public class MyClass ... {
@MessageListener(requestReply=true)
public OutputMessage process(InputMessage message) {
....
return outputMessage;
}
}
Alternatives:
a) Perform message listening in script. This reduces code and in some cases, improves clarity on intent. However, this is not a java based solution and some classes may not have the benefit of being created in the serializer.
b) Keep coding by hand with anonymous classes. This approach works and is fine but part of the recommendation is to make this easier and more clear.
c) Use other libraries like EventBus. This is a good option, but the idea was to use more pivot features and decrease external library dependence, where possible. EventBus has more fine-grained filtering behavior but this may or may not be critical to a pivot application. For simple uses, pivot's is fine and appropriate. Easier message registration is a plus. The two systems can be easily bridged if need be.
Pros:
a) Clearer client intent.
b) Less java coding. This is similar in concept to the benefits of using of script in the serializer.
Cons:
a) More code in the pivot base to maintain.
b) Uses reflection (all internally). Some think this should be avoided in general.
c) Without ApplicationContext enhancements, you need to use weak listeners inside the specialized message listener class. While the implementation would be safe, it requires dealing with weak listener perceptions.
d) If you only have 1-2 message listener classes in your application, this is not reducing alot of complexity.
> 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.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and
an annotation processor for application context message listener
Posted by "Noel Grandin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880607#action_12880607 ]
Noel Grandin commented on PIVOT-535:
------------------------------------
See (some parts of) the earlier discussion we had about weak listeners here:
http://www.mail-archive.com/pivot-dev@incubator.apache.org/msg03847.html
Bottom line is that weak listeners are a bad idea.
> 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.