Customer Problem Description:
-------------------------------
I attached two files:  a doclet that simply enumerates the methods of 
the processed file, and a test file.  You can build and run the test with:

  javac -classpath  { path to j2sdk1.4.1_02}/lib/tools.jar:. -d . BugDoclet.java
 
  javadoc -doclet BugDoclet TraderEJB.java

And you will notice that instead of listing two methods (example1() 
overloaded once), it only lists one:

    D:\t\trader>javac -d . BugDoclet.java && javadoc -doclet BugDoclet
    TraderEJB.java

    
METHOD:examples.ejb20.basic.statefulSession.TraderEJB.example1(java.lang.Integer,
    java.lang.Integer, UserSession)


If you modify the signature of the example1() method that is not listed, 
then JavaDoc displays it correctly (I added the first int parameter to it):

    
METHOD:examples.ejb20.basic.statefulSession.TraderEJB.example1(java.lang.Integer,
    java.lang.Integer, UserSession)
    METHOD:examples.ejb20.basic.statefulSession.TraderEJB.example1(int,
    SourceLocationEntityLocal, LocationEntityLocal, int)


See Attachments for sample codes

Add to the classpath the class (or jar) files needed to resolve the
symbols that the javadoc tool warns about.  Things like:

	TraderEJB.java:41: cannot resolve symbol
	symbol  : class UserSession 

  xxxxx@xxxxx   2003-03-24

I can reproduce your results with javadoc 1.4.1 and 1.4.2.
The attached file TraderEJB.java that works fine, printing both methods.
To reproduce the error, remove the first "int n" parameter from the
second example1 method in TraderEJB.  Then the second example1 method 
will not print.  Ignore the warning messages, as the customer runs
the doclet without the referenced classes on the classpath.

The problem seems to be that this second method never appears in the
ClassDoc.methods() array:

public void example1(SourceLocationEntityLocal p_sourceLocationEntity, 
                     LocationEntityLocal p_locationEntity, 
                     int p_iTest) 
                     throws BusinessException {}

  xxxxx@xxxxx   2003-03-21


This bug is in the javadoc tool, and can be reproduced using the
standard doclet.  The custom doclet attached is useful in ruling
out the standard doclet as the culprit, but is otherwise unneeded.

The bug can be reproduced by running "javadoc T1.java" on the following:

    public class T1 {
	public void m(Bogus b) {}
	public void m(Goofy g) {}
	public void m(Daffy d) {}
    }

It appears that when method "m" is overloaded any number of times 
differing only in an unresolvable type, then the first method
appears in the javadoc but none of the others.

Using "m(int i)" works similarly.  With the following:

    public class T2 {
	public void m(Bogus b) {}
	public void m(int i) {}
    }

only the first method appears in the javadoc.  When we reverse the order
of the methods like this:

    public class T3 {
	public void m(int i) {}
	public void m(Bogus b) {}
    }

again it's the first method only that appears in the javadoc.  However,
we now get an additional diagnostic that's suggestive of how the
tool might be getting confused:

    T3.java:3: m(int) is already defined in T3
	    public void m(Bogus b) {}

  xxxxx@xxxxx   2003-03-24


Bug is in 1.4.0 as well.

  xxxxx@xxxxx   2003-03-24


Info from   xxxxx@xxxxx  :
Since Bogus is an undefined type, the compiler treats it
as an "error" type which matches all other types in order to
suppress cascaded diagnostics.  But in this case matching other
types is the wrong thing to do.  I think we can adjust the
code in the compiler to behave appropriately in these situations.

  xxxxx@xxxxx   2003-03-25