User: ara_e_w
Date: 02/06/13 12:16:50
Modified: samples/src/java/test/ejb CustomerBean.java
Log:
- MethodImpl.buildStringId() is ued for hashcode/equals, but also uses modifiers of
the method, which is wrong, because if you override an abstract method then it thinks
they are two different methods, which really are not, and that leads to problems in
some of the superclass/override sensitive templates. I removed modifiers from the
calculation.
- CustomerBean had missing imports, which leads to overriding code to fail. I also
added a long description about why you should explicitly import to CustomerBean's
import section.
- cleanup
Revision Changes Path
1.4 +26 -1 xdoclet/samples/src/java/test/ejb/CustomerBean.java
Index: CustomerBean.java
===================================================================
RCS file: /cvsroot/xdoclet/xdoclet/samples/src/java/test/ejb/CustomerBean.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -w -r1.3 -r1.4
--- CustomerBean.java 12 Jun 2002 09:22:46 -0000 1.3
+++ CustomerBean.java 13 Jun 2002 19:16:50 -0000 1.4
@@ -5,7 +5,32 @@
import javax.ejb.*;
import javax.naming.*;
-import test.interfaces.*;
+//remember it helps xdoclet if you define the exact import statement
+//test.interfaces.* won't do it.
+//The reason is that CustomerData for example is not yet generated,
+//so xdoclet encounters a method which has CustomerData parameter,
+//tries to find its package name, but because it's not generated yet
+//assumes it's in current package (test.ejb). So if you then override
+//from this package for example, xdoclet can't figure out that it's the
+//same method (different parameter types) and that means you may end up
+//with two methods with the same syntax!
+//As an example you can remove these explicit imports, use test.interfaces.*
+//and see what happens. you see that the derived test.ejb.CustomerBMPBMP
+//subclass has two ejbPostCreate(CustomerNormalValue data) methods because
+//CustomerBMPBean imports CustomerNormalValue explicitly but CustomerBean
+//doesn't, so xdoclet thinks they are two different methods, not redundant
+//overriden methods. Overall the best thing you can do is define the parameters
+//in full qualified format, instead of imports, for stuff which will later be
+//autogenerated by xdoclet.
+import test.interfaces.Customer;
+import test.interfaces.CustomerData;
+import test.interfaces.CustomerPK;
+import test.interfaces.CustomerNormalValue;
+import test.interfaces.CustomerLightValue;
+import test.interfaces.ApplicationException;
+import test.interfaces.CustomerLightValue;
+import test.interfaces.AccountHome;
+import test.interfaces.AddressLocalHome;
/**
* This is a customer bean. It is an example of how to use the XDoclet tags.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
