You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/08/16 00:01:21 UTC
Re: [collections] NotifyingCollections - the wrapping problem
This isn't the problem case. Think about:
Collection c = new ArrayList();
ObservableCollection oc = CollectionUtils.observableCollection(c);
SynchronizedCollection sc = CollectionUtils.synchronizedCollection(oc);
oc.addListener(new CollectionListener() {
public void changed(CollectionEvent e) { Collection eventCollection =
e.getCollection() }
});
c.add("");
Fails - but all decorators ban this because c is decorated
oc.add("");
Sends event OK - eventCollection == oc, but all decorators ban this because
oc is decorated
sc.add("");
Sends event OK - BUT eventCollection == oc.
This is a problem, as if the listener then uses the collection, it will not
be synchronized. Big problem.
Stephen
----- Original Message -----
From: "Michael Heuer" <he...@acm.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: <ne...@users.sourceforge.net>
Sent: Thursday, August 14, 2003 11:02 PM
Subject: Re: [collections] NotifyingCollections - capturing rich non-uniform
data
>
> On Thu, 14 Aug 2003, Stephen Colebourne wrote:
>
> > <snip>
> >
> > The biggest problem with all this is that the collection returned by
> > getSource() on the event. If the observed collection is wrapped (eg. by
a
> > SyncronizedCollection) then getSource() SHOULD return the wrapped
> > collection, but it can't as it doesn't know about it. This problem
applies
> > to all designs so far.
>
> Is this also a problem? It's general to all of the delegation
> implementations.
>
>
> private boolean heardChange = false;
>
> public void testChangeToBackingCollection()
> {
> Collection c = new ArrayList();
> ObservableCollection oc = CollectionUtils.observableCollection(c);
> oc.addListener(new CollectionListener()
> {
> public void changed(CollectionEvent e) { heardChange = true; }
> });
>
> c.add("hello");
>
> assertTrue("heardChange == true", heardChange == true);
> }
>
>
> I don't think it's possible to make this test pass -- just a
> shortcoming of the wrapper design. That's why I was looking into
> aspect-based implementations.
>
> michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] NotifyingCollections - the wrapping problem
Posted by Neil O'Toole <ne...@yahoo.com>.
Guys,
Sorry I haven't had a chance to read this thread - I've been on the
road since thursday. I'll be back in the real world tomorrow and i'll
get back to you all then.
- Neil
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> From: "Chuck Daniels" <cj...@yahoo.com>
> > > sc.add("");
> > > Sends event OK - BUT eventCollection == oc.
> > > This is a problem, as if the listener then uses the collection,
> > > it will not
> > > be synchronized. Big problem.
> >
> > I don't think this will actually be a problem. If calls to sc are
> > synchronized, then anything that the listener does to the backing
> collection
> > (oc in this case) is still within the context of the synchronized
> call on
> > sc. Therefore, access to the backing collection is indirectly
> synchronized.
> > Or am I missing something here?
>
> Intruiging. Yes, you are probably correct, so long as the listener
> operates
> in the same thread in a normal fashion. I was thinking of trying to
> spot if
> the ObservedCollection was being decorated and inform it, but maybe
> thats
> over zealous, and javadoc will do.
>
> Stephen
>
>
>
>
>
> > > ----- Original Message -----
> > > From: "Michael Heuer" <he...@acm.org>
> > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> > > Cc: <ne...@users.sourceforge.net>
> > > Sent: Thursday, August 14, 2003 11:02 PM
> > > Subject: Re: [collections] NotifyingCollections - capturing rich
> > > non-uniform
> > > data
> > >
> > >
> > > >
> > > > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> > > >
> > > > > <snip>
> > > > >
> > > > > The biggest problem with all this is that the collection
> returned by
> > > > > getSource() on the event. If the observed collection is
> > > wrapped (eg. by
> > > a
> > > > > SyncronizedCollection) then getSource() SHOULD return the
> wrapped
> > > > > collection, but it can't as it doesn't know about it. This
> problem
> > > applies
> > > > > to all designs so far.
> > > >
> > > > Is this also a problem? It's general to all of the delegation
> > > > implementations.
> > > >
> > > >
> > > > private boolean heardChange = false;
> > > >
> > > > public void testChangeToBackingCollection()
> > > > {
> > > > Collection c = new ArrayList();
> > > > ObservableCollection oc =
> CollectionUtils.observableCollection(c);
> > > > oc.addListener(new CollectionListener()
> > > > {
> > > > public void changed(CollectionEvent e) { heardChange =
> true; }
> > > > });
> > > >
> > > > c.add("hello");
> > > >
> > > > assertTrue("heardChange == true", heardChange == true);
> > > > }
> > > >
> > > >
> > > > I don't think it's possible to make this test pass -- just a
> > > > shortcoming of the wrapper design. That's why I was looking
> into
> > > > aspect-based implementations.
> > > >
> > > > michael
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] NotifyingCollections - the wrapping problem
Posted by Neil O'Toole <ne...@yahoo.com>.
Guys,
Sorry I haven't had a chance to read this thread - I've been on the
road since thursday. I'll be back in the real world tomorrow and i'll
get back to you all then.
- Neil
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> From: "Chuck Daniels" <cj...@yahoo.com>
> > > sc.add("");
> > > Sends event OK - BUT eventCollection == oc.
> > > This is a problem, as if the listener then uses the collection,
> > > it will not
> > > be synchronized. Big problem.
> >
> > I don't think this will actually be a problem. If calls to sc are
> > synchronized, then anything that the listener does to the backing
> collection
> > (oc in this case) is still within the context of the synchronized
> call on
> > sc. Therefore, access to the backing collection is indirectly
> synchronized.
> > Or am I missing something here?
>
> Intruiging. Yes, you are probably correct, so long as the listener
> operates
> in the same thread in a normal fashion. I was thinking of trying to
> spot if
> the ObservedCollection was being decorated and inform it, but maybe
> thats
> over zealous, and javadoc will do.
>
> Stephen
>
>
>
>
>
> > > ----- Original Message -----
> > > From: "Michael Heuer" <he...@acm.org>
> > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> > > Cc: <ne...@users.sourceforge.net>
> > > Sent: Thursday, August 14, 2003 11:02 PM
> > > Subject: Re: [collections] NotifyingCollections - capturing rich
> > > non-uniform
> > > data
> > >
> > >
> > > >
> > > > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> > > >
> > > > > <snip>
> > > > >
> > > > > The biggest problem with all this is that the collection
> returned by
> > > > > getSource() on the event. If the observed collection is
> > > wrapped (eg. by
> > > a
> > > > > SyncronizedCollection) then getSource() SHOULD return the
> wrapped
> > > > > collection, but it can't as it doesn't know about it. This
> problem
> > > applies
> > > > > to all designs so far.
> > > >
> > > > Is this also a problem? It's general to all of the delegation
> > > > implementations.
> > > >
> > > >
> > > > private boolean heardChange = false;
> > > >
> > > > public void testChangeToBackingCollection()
> > > > {
> > > > Collection c = new ArrayList();
> > > > ObservableCollection oc =
> CollectionUtils.observableCollection(c);
> > > > oc.addListener(new CollectionListener()
> > > > {
> > > > public void changed(CollectionEvent e) { heardChange =
> true; }
> > > > });
> > > >
> > > > c.add("hello");
> > > >
> > > > assertTrue("heardChange == true", heardChange == true);
> > > > }
> > > >
> > > >
> > > > I don't think it's possible to make this test pass -- just a
> > > > shortcoming of the wrapper design. That's why I was looking
> into
> > > > aspect-based implementations.
> > > >
> > > > michael
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] NotifyingCollections - the wrapping problem
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Chuck Daniels" <cj...@yahoo.com>
> > sc.add("");
> > Sends event OK - BUT eventCollection == oc.
> > This is a problem, as if the listener then uses the collection,
> > it will not
> > be synchronized. Big problem.
>
> I don't think this will actually be a problem. If calls to sc are
> synchronized, then anything that the listener does to the backing
collection
> (oc in this case) is still within the context of the synchronized call on
> sc. Therefore, access to the backing collection is indirectly
synchronized.
> Or am I missing something here?
Intruiging. Yes, you are probably correct, so long as the listener operates
in the same thread in a normal fashion. I was thinking of trying to spot if
the ObservedCollection was being decorated and inform it, but maybe thats
over zealous, and javadoc will do.
Stephen
> > ----- Original Message -----
> > From: "Michael Heuer" <he...@acm.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Cc: <ne...@users.sourceforge.net>
> > Sent: Thursday, August 14, 2003 11:02 PM
> > Subject: Re: [collections] NotifyingCollections - capturing rich
> > non-uniform
> > data
> >
> >
> > >
> > > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> > >
> > > > <snip>
> > > >
> > > > The biggest problem with all this is that the collection returned by
> > > > getSource() on the event. If the observed collection is
> > wrapped (eg. by
> > a
> > > > SyncronizedCollection) then getSource() SHOULD return the wrapped
> > > > collection, but it can't as it doesn't know about it. This problem
> > applies
> > > > to all designs so far.
> > >
> > > Is this also a problem? It's general to all of the delegation
> > > implementations.
> > >
> > >
> > > private boolean heardChange = false;
> > >
> > > public void testChangeToBackingCollection()
> > > {
> > > Collection c = new ArrayList();
> > > ObservableCollection oc = CollectionUtils.observableCollection(c);
> > > oc.addListener(new CollectionListener()
> > > {
> > > public void changed(CollectionEvent e) { heardChange = true; }
> > > });
> > >
> > > c.add("hello");
> > >
> > > assertTrue("heardChange == true", heardChange == true);
> > > }
> > >
> > >
> > > I don't think it's possible to make this test pass -- just a
> > > shortcoming of the wrapper design. That's why I was looking into
> > > aspect-based implementations.
> > >
> > > michael
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] NotifyingCollections - the wrapping problem
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Chuck Daniels" <cj...@yahoo.com>
> > sc.add("");
> > Sends event OK - BUT eventCollection == oc.
> > This is a problem, as if the listener then uses the collection,
> > it will not
> > be synchronized. Big problem.
>
> I don't think this will actually be a problem. If calls to sc are
> synchronized, then anything that the listener does to the backing
collection
> (oc in this case) is still within the context of the synchronized call on
> sc. Therefore, access to the backing collection is indirectly
synchronized.
> Or am I missing something here?
Intruiging. Yes, you are probably correct, so long as the listener operates
in the same thread in a normal fashion. I was thinking of trying to spot if
the ObservedCollection was being decorated and inform it, but maybe thats
over zealous, and javadoc will do.
Stephen
> > ----- Original Message -----
> > From: "Michael Heuer" <he...@acm.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Cc: <ne...@users.sourceforge.net>
> > Sent: Thursday, August 14, 2003 11:02 PM
> > Subject: Re: [collections] NotifyingCollections - capturing rich
> > non-uniform
> > data
> >
> >
> > >
> > > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> > >
> > > > <snip>
> > > >
> > > > The biggest problem with all this is that the collection returned by
> > > > getSource() on the event. If the observed collection is
> > wrapped (eg. by
> > a
> > > > SyncronizedCollection) then getSource() SHOULD return the wrapped
> > > > collection, but it can't as it doesn't know about it. This problem
> > applies
> > > > to all designs so far.
> > >
> > > Is this also a problem? It's general to all of the delegation
> > > implementations.
> > >
> > >
> > > private boolean heardChange = false;
> > >
> > > public void testChangeToBackingCollection()
> > > {
> > > Collection c = new ArrayList();
> > > ObservableCollection oc = CollectionUtils.observableCollection(c);
> > > oc.addListener(new CollectionListener()
> > > {
> > > public void changed(CollectionEvent e) { heardChange = true; }
> > > });
> > >
> > > c.add("hello");
> > >
> > > assertTrue("heardChange == true", heardChange == true);
> > > }
> > >
> > >
> > > I don't think it's possible to make this test pass -- just a
> > > shortcoming of the wrapper design. That's why I was looking into
> > > aspect-based implementations.
> > >
> > > michael
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] NotifyingCollections - the wrapping problem
Posted by Chuck Daniels <cj...@yahoo.com>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Saturday, August 16, 2003 8:01 AM
> To: Jakarta Commons Developers List
> Subject: Re: [collections] NotifyingCollections - the wrapping problem
>
>
> This isn't the problem case. Think about:
>
> Collection c = new ArrayList();
> ObservableCollection oc = CollectionUtils.observableCollection(c);
> SynchronizedCollection sc = CollectionUtils.synchronizedCollection(oc);
> oc.addListener(new CollectionListener() {
> public void changed(CollectionEvent e) { Collection eventCollection =
> e.getCollection() }
> });
>
> c.add("");
> Fails - but all decorators ban this because c is decorated
>
> oc.add("");
> Sends event OK - eventCollection == oc, but all decorators ban
> this because
> oc is decorated
>
> sc.add("");
> Sends event OK - BUT eventCollection == oc.
> This is a problem, as if the listener then uses the collection,
> it will not
> be synchronized. Big problem.
I don't think this will actually be a problem. If calls to sc are
synchronized, then anything that the listener does to the backing collection
(oc in this case) is still within the context of the synchronized call on
sc. Therefore, access to the backing collection is indirectly synchronized.
Or am I missing something here?
>
> Stephen
>
> ----- Original Message -----
> From: "Michael Heuer" <he...@acm.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Cc: <ne...@users.sourceforge.net>
> Sent: Thursday, August 14, 2003 11:02 PM
> Subject: Re: [collections] NotifyingCollections - capturing rich
> non-uniform
> data
>
>
> >
> > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> >
> > > <snip>
> > >
> > > The biggest problem with all this is that the collection returned by
> > > getSource() on the event. If the observed collection is
> wrapped (eg. by
> a
> > > SyncronizedCollection) then getSource() SHOULD return the wrapped
> > > collection, but it can't as it doesn't know about it. This problem
> applies
> > > to all designs so far.
> >
> > Is this also a problem? It's general to all of the delegation
> > implementations.
> >
> >
> > private boolean heardChange = false;
> >
> > public void testChangeToBackingCollection()
> > {
> > Collection c = new ArrayList();
> > ObservableCollection oc = CollectionUtils.observableCollection(c);
> > oc.addListener(new CollectionListener()
> > {
> > public void changed(CollectionEvent e) { heardChange = true; }
> > });
> >
> > c.add("hello");
> >
> > assertTrue("heardChange == true", heardChange == true);
> > }
> >
> >
> > I don't think it's possible to make this test pass -- just a
> > shortcoming of the wrapper design. That's why I was looking into
> > aspect-based implementations.
> >
> > michael
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [collections] NotifyingCollections - the wrapping problem
Posted by Chuck Daniels <cj...@yahoo.com>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Saturday, August 16, 2003 8:01 AM
> To: Jakarta Commons Developers List
> Subject: Re: [collections] NotifyingCollections - the wrapping problem
>
>
> This isn't the problem case. Think about:
>
> Collection c = new ArrayList();
> ObservableCollection oc = CollectionUtils.observableCollection(c);
> SynchronizedCollection sc = CollectionUtils.synchronizedCollection(oc);
> oc.addListener(new CollectionListener() {
> public void changed(CollectionEvent e) { Collection eventCollection =
> e.getCollection() }
> });
>
> c.add("");
> Fails - but all decorators ban this because c is decorated
>
> oc.add("");
> Sends event OK - eventCollection == oc, but all decorators ban
> this because
> oc is decorated
>
> sc.add("");
> Sends event OK - BUT eventCollection == oc.
> This is a problem, as if the listener then uses the collection,
> it will not
> be synchronized. Big problem.
I don't think this will actually be a problem. If calls to sc are
synchronized, then anything that the listener does to the backing collection
(oc in this case) is still within the context of the synchronized call on
sc. Therefore, access to the backing collection is indirectly synchronized.
Or am I missing something here?
>
> Stephen
>
> ----- Original Message -----
> From: "Michael Heuer" <he...@acm.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Cc: <ne...@users.sourceforge.net>
> Sent: Thursday, August 14, 2003 11:02 PM
> Subject: Re: [collections] NotifyingCollections - capturing rich
> non-uniform
> data
>
>
> >
> > On Thu, 14 Aug 2003, Stephen Colebourne wrote:
> >
> > > <snip>
> > >
> > > The biggest problem with all this is that the collection returned by
> > > getSource() on the event. If the observed collection is
> wrapped (eg. by
> a
> > > SyncronizedCollection) then getSource() SHOULD return the wrapped
> > > collection, but it can't as it doesn't know about it. This problem
> applies
> > > to all designs so far.
> >
> > Is this also a problem? It's general to all of the delegation
> > implementations.
> >
> >
> > private boolean heardChange = false;
> >
> > public void testChangeToBackingCollection()
> > {
> > Collection c = new ArrayList();
> > ObservableCollection oc = CollectionUtils.observableCollection(c);
> > oc.addListener(new CollectionListener()
> > {
> > public void changed(CollectionEvent e) { heardChange = true; }
> > });
> >
> > c.add("hello");
> >
> > assertTrue("heardChange == true", heardChange == true);
> > }
> >
> >
> > I don't think it's possible to make this test pass -- just a
> > shortcoming of the wrapper design. That's why I was looking into
> > aspect-based implementations.
> >
> > michael
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org