Filed By      : SPB JCK team (  xxxxx@xxxxx  )
JDK           : java full version "1.5.0-beta-b23"
JCK           : 1.5
Platform[s]   : Solaris
switch/Mode   : 
JCK test owner : http://javaweb.eng/jct/sqe/JCK-tck/usr/owners.jto
Failing Test [s] : 
api/java_beans/beancontext/BeanContextChildSupport/index.html#add [BeanContextChildSupport0003] 


Specification excerpt:
======================
--------- J2SE API spec v.1.5 ---------
...
public void addPropertyChangeListener(String name,
                                      PropertyChangeListener pcl)
Adds a property change listener. 

Specified by:
addPropertyChangeListener in interface BeanContextChild
Parameters:
name - The name of the property to listen on
pcl - The PropertyChangeListener to be added

===

public void removePropertyChangeListener(String name,
                                         PropertyChangeListener pcl)
Remove a property change listener. 

Specified by:
removePropertyChangeListener in interface BeanContextChild
Parameters:
name - The name of the property that was listened on
pcl - The PropertyChangeListener to be removed

===

public void addVetoableChangeListener(String name,
                                      VetoableChangeListener vcl)
Adds a VetoableChangeListener. 

Specified by:
addVetoableChangeListener in interface BeanContextChild
Parameters:
name - The name of the property to listen on
vcl - The VetoableChangeListener to be added

===

public void removeVetoableChangeListener(String name,
                                         VetoableChangeListener vcl)
Removes a VetoableChangeListener. 

Specified by:
removeVetoableChangeListener in interface BeanContextChild
Parameters:
name - The name of the property that was listened on
vcl - The VetoableChangeListener to be removed

...
---------- end-of-excerpt ---------------

Problem description
===================
The spec for the designated 4 methods does not say about the
expected behaviour in cases:

1. addPropertyChangeListener(String name,
                                      PropertyChangeListener pcl)
   if name == null;

2. addPropertyChangeListener(String name,
                                      PropertyChangeListener pcl)
   if pcl == null;

3. addPropertyChangeListener(String name,
                                      PropertyChangeListener pcl)
  if pcl has already been added;

4. public void removePropertyChangeListener(String name,
                                         PropertyChangeListener pcl)
  if name == null;

5. public void removePropertyChangeListener(String name,
                                         PropertyChangeListener pcl)
  if pcl == null;

6. public void removePropertyChangeListener(String name,
                                         PropertyChangeListener pcl)
  if there is no such listener as pcl;

7. public void removePropertyChangeListener(String name,
                                         PropertyChangeListener pcl)
  if pcl has been added regarding another property name;

8. The same 7 points about add/removeVetoableChangeListener methods

Please refer to the "Requirements for Writing Java API Specifications"
 (http://java.sun.com/j2se/javadoc/writingapispecs/index.html#method)
for more information.


JCK test source location:
==========================
/java/re/jck/1.5/promoted/latest/JCK-runtime-15/tests

======================================================================

N/A

  xxxxx@xxxxx   2003-10-16

The null parameters are addressed in Tiger at the package level. The other issues will be documented in this class.

  xxxxx@xxxxx   2003-10-27

As with bug 4937059, most of these items are already covered by the Beans spec and/or the java.beans package docs.

Items 1 and 4 are covered under the new bug, 4985020.

Items 2 and 5 are covered by the package level statement, "Unless explicitly stated, null values or empty Strings are not valid parameters for the methods in this package. You may expect to see exceptions if these parameters are used."

Items 3 is covered in section 6.5 of the Beans spec: "The relationship between registration order and event delivery order is implementation defined.  In addition the effects of adding the same event listener object more than once on the same event source, or of removing an event listener object more than once, or of removing an event listener object that is not registered, are all implementation defined."

I'm not sure what is meant by 6.  Assuming it is asking what happens when a listener is attempted to be removed from an event source that it was never registered with, then this is also covered by the Beans spec, like item 3.

Item 7 should be specified as such: "Attempting to remove a listener on a property for which it was never registered results in no action being taken."

The above are all true of VetoableChangeListeners as well.

To make this clearer, I'll add some references to the JavaBeans Spec to the methods in question.
  xxxxx@xxxxx   2004-01-30

Upon further discussion, we feel it is a better strategy to more explicitly specify the correct behavior in the JavaDoc.  This is in line with our solution to similar bug 4937059.
  xxxxx@xxxxx   2004-02-04