OK, it's even weirder than I thought when I thought it was weird.
It's a problem w/ java.beans.Introspector + XJavadoc + Middlegen -- and as usual, Middlegen is wrong :-(.
XJavadoc uses java.beans.Introspector.decapitalize() to turn a string into a variable name. The javadocs for Introspector say:
"This normally means converting the first character from upper case to lower case, but in the (unusual) special case when there is more than one character and both the first and second characters are upper case, we leave it alone.
Thus 'FooBah' becomes 'fooBah' and 'X' becomes 'x', but 'URL' stays as 'URL'."
Middlegen, on the other hand, simply decapitalizes the first letter. And it's worse than that: Middlegen has (since the intial revision in Sourceforge CVS) HAD COMMENTED OUT CODE WITH A CALL TO Introspector.decapitalize()!!!!!!!
Why was this code commented out, anybody? What will break if I make this change back, anything? Testing now, patch soon.
Dave
| [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED] 05/27/2003 06:44 PM
|
To: [EMAIL PROTECTED] cc: Subject: Re: [Middlegen-user] Value Object support++ |
Eivind,
OK, I have another issue.
in the light value objects, there's a method "hasIdentity()": it's got the value of the boolean field it's checking spelled wrong (lowercase first letter hard-coded) -- I have my own DbNameConverter, and my table names don't get converted the way Middlegen might expect them to (because they already look like Java class names and the stock DbNameConverter just screws them up: APClientCode would become ApclientCode which messes up the pneumonic and makes the classes too hard to find). It seems like whatever generates the variable name in "hasIdentity()" doesn't use the same scheme as the rest of the methods (the others which return the same field spell it right).
Where can I find the code that generates this: it's in your customized xdoclet-ejb-module, no? Is the source for that in CVS, or just the jar?
Dave
