Discussion:
[Middlegen-user] Value Object support++
Eivind Waaler
2003-05-21 13:43:03 UTC
Permalink
Thought I'd send some information about what's been done in the
VALUEOBJECT_REFACTORING_BRANCH branch in CVS.

New features:
====================

1. Value Object support. In the build.xml, you can now specify
valueobject="true". There are two value objects for each entity, an
XXLightValue which only has fields and an XXValue which extends
XXLightValue and has relationships.

2. Entity Facade support. By specifying sessionfacade="true" in the
build.xml file, a Middlegen specific version of XDoclet entity facade
objects are generated. These can be used to access all the entities
remotely. Value objects must be generated for this to work, as all data
are transported as value objects (since local entity references can't be
passed remotely).

3. DynamicQL for JBoss. By specifying dynamicQL="true" on the <jboss>
subelement of the <cmp20> plugin, a method for dynamic JBossQL is added to
all entities:

findByDynamicQL(java.lang.String jbossql, java.lang.Object[] args)

If you're using JBoss this is really cool, because you can specify finders
runtime. Example:

String jbossql = "SELECT OBJECT(p) FROM Person p WHERE p.lastName = ?1";
Object[] arguments = new Object[1];
arguments[0] = "waaler";
Collection persons = personFacade.findByDynamicQL(jbossql, arguments);
System.out.println("persons: " + persons);

This piece of code runs the JBossQL statement on the person entity,
remotely through the person facade session bean. It returns a Collection
of PersonValue objects. How cool is that?

Known issues/limitations/problems:
====================

- Update/create on all entities must be done with the foreign key fields
set (not relationships). For example to set an address to the person:

personValue.setAddressIdFk(new Integer(1)); // works
personValue.setAddress(addressValue); // does not work

I haven't figured out a smooth solution to this.

- On getting a value object, all relationships are actually returned as
light value objects. This is due to the reentrant problem discussed on the
list earlier. There are some different solutions to this, I haven't
implemented any other yet.

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

Please get the VALUEOBJECT_REFACTORING_BRANCH from CVS and try it out. I
have not testet it on anything but mysql + jboss 3.2.1 yet, so there might
be issues. The branch has got a separate version in the JIRA, so please
log bugs/issues/patches/whatever there:

http://jira.codehaus.org/secure/BrowseProject.jspa?id=10110

Cheers
.eivind
D***@nascopgh.com
2003-05-21 20:38:05 UTC
Permalink
Eivind: this looks great! Thanks for the work.

One problem: the @ebj.facade xdoclet template assumes you're using
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() & .getValue() in
the Facade.

I guess in order to use this one could just replace XDoclet's
entityfacade.xdt

Dave
Eivind Waaler
2003-05-22 04:52:04 UTC
Permalink
I've already replaced XDoclet ejb module included in the CVS branch. Just
check it out:

http://tinyurl.com/cdi8

The changes are a real hack, as I don't really know much about XDoclet and
simply wanted it to work ASAP. I've simply hardcoded the names of the
Middlegen value objects in there.

I'm using the XXValue as return value and XXLightValue as parameter to
most of the methods (since relationships are now handled only with the FK
field directly). But since XXValue extends XXLightValue that should not be
noticable for the user. Typical methods in facade:

public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders

We've successfully deployed a remote application in JBoss from a database
with 100 tables using this Middlegen version. A total of around 1300
compiled classes, all generated! Being accessed from a standalone Java
client..

Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() & .getValue() in
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
D***@nascopgh.com
2003-05-22 11:33:05 UTC
Permalink
So, you re-jarred XDoclet w/ this version of the template?

I'd be interested in helping out w/ this, BTW.

I wonder if the XDoclet team would take a patch switching to VO's?

Dave





Eivind Waaler <***@tihlde.org>
Sent by: middlegen-user-***@lists.sourceforge.net
05/22/2003 02:50 AM
Please respond to middlegen-user

To: middlegen-***@lists.sourceforge.net
cc:
Subject: Re: [Middlegen-user] Value Object support++


I've already replaced XDoclet ejb module included in the CVS branch. Just
check it out:

http://tinyurl.com/cdi8

The changes are a real hack, as I don't really know much about XDoclet and
simply wanted it to work ASAP. I've simply hardcoded the names of the
Middlegen value objects in there.

I'm using the XXValue as return value and XXLightValue as parameter to
most of the methods (since relationships are now handled only with the FK
field directly). But since XXValue extends XXLightValue that should not be
noticable for the user. Typical methods in facade:

public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders

We've successfully deployed a remote application in JBoss from a database
with 100 tables using this Middlegen version. A total of around 1300
compiled classes, all generated! Being accessed from a standalone Java
client..

Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() & .getValue()
in
Post by D***@nascopgh.com
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Rod Macpherson
2003-05-22 13:19:14 UTC
Permalink
One of the first things I ditched was the Xdoclet value object
implementation. Instead I generated my own value objects with a velocity
template and a <java> sub-task: very clean, very simple. The next thing
I ditched were the create and find methods by customizing the default
CMP velocity script. We really did not want those gigantic ejbCreate
methods (yikes!) where every column was represented with a parameter. I
replaced that with a single value object ejbCreate.

-----Original Message-----
From: Eivind Waaler [mailto:***@tihlde.org]
Sent: Wednesday, May 21, 2003 11:50 PM
To: middlegen-***@lists.sourceforge.net
Subject: Re: [Middlegen-user] Value Object support++


I've already replaced XDoclet ejb module included in the CVS branch.
Just check it out:

http://tinyurl.com/cdi8

The changes are a real hack, as I don't really know much about XDoclet
and simply wanted it to work ASAP. I've simply hardcoded the names of
the Middlegen value objects in there.

I'm using the XXValue as return value and XXLightValue as parameter to
most of the methods (since relationships are now handled only with the
FK field directly). But since XXValue extends XXLightValue that should
not be noticable for the user. Typical methods in facade:

public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders

We've successfully deployed a remote application in JBoss from a
database with 100 tables using this Middlegen version. A total of around
1300 compiled classes, all generated! Being accessed from a standalone
Java client..

Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() & .getValue()
in
Post by D***@nascopgh.com
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore. Now
part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
middlegen-user mailing list middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user
D***@nascopgh.com
2003-05-22 13:59:15 UTC
Permalink
Eivind's branched version of the entity CMP velocity template does the
part you mentioned about creating the ejbCreate(valueobject) method.

I'd be interested in hearing more about your approach, however.

Dave





"Rod Macpherson" <***@verilet.com>
Sent by: middlegen-user-***@lists.sourceforge.net
05/22/2003 10:57 AM
Please respond to middlegen-user

To: <middlegen-***@lists.sourceforge.net>
cc:
Subject: RE: [Middlegen-user] Value Object support++


One of the first things I ditched was the Xdoclet value object
implementation. Instead I generated my own value objects with a velocity
template and a <java> sub-task: very clean, very simple. The next thing
I ditched were the create and find methods by customizing the default
CMP velocity script. We really did not want those gigantic ejbCreate
methods (yikes!) where every column was represented with a parameter. I
replaced that with a single value object ejbCreate.

-----Original Message-----
From: Eivind Waaler [mailto:***@tihlde.org]
Sent: Wednesday, May 21, 2003 11:50 PM
To: middlegen-***@lists.sourceforge.net
Subject: Re: [Middlegen-user] Value Object support++


I've already replaced XDoclet ejb module included in the CVS branch.
Just check it out:

http://tinyurl.com/cdi8

The changes are a real hack, as I don't really know much about XDoclet
and simply wanted it to work ASAP. I've simply hardcoded the names of
the Middlegen value objects in there.

I'm using the XXValue as return value and XXLightValue as parameter to
most of the methods (since relationships are now handled only with the
FK field directly). But since XXValue extends XXLightValue that should
not be noticable for the user. Typical methods in facade:

public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders

We've successfully deployed a remote application in JBoss from a
database with 100 tables using this Middlegen version. A total of around
1300 compiled classes, all generated! Being accessed from a standalone
Java client..

Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() & .getValue()
in
Post by D***@nascopgh.com
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore. Now
part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
middlegen-user mailing list middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
D***@nascopgh.com
2003-05-22 14:05:03 UTC
Permalink
Eivind,

What's the TreeBuilder referenced in the comments in entity-cmp-20.vm on
the branch?

Dave
Rod Macpherson
2003-05-22 14:44:20 UTC
Permalink
1. First part is to add a java sub-task to your middlegen so you get a
file with the bean name (the {0} variable) with Model or something else
appended:

<java name="model" destination="${build.source}"
package="com.acme.model">
<fileproducer filename="{0}Model.java"
destination="${build.source}" template="./velocity/model.vm"/>
</java>

2. Then you create your model.vtl using all of the "stuff" that is in
the velocity context by middlegen. Here is the commen theader of my
model.vm:


/***********************************************************************
*******
*
* Value object representing the ${table.sqlName} database table.
*
* Primary key:
*
* ${table.pkColumn.variableName}
*
#if(!$table.foreignKeyColumns.empty)
* Foreign keys:
*
#foreach($column in $table.foreignKeyColumns)
* ${column.variableName}
#end
#end
*
#if(!$table.mandatoryNotKeyColumns.empty)
* Required columns:
*
#foreach($column in $table.mandatoryNotKeyColumns)
* ${column.variableName}
#end
#end
*
#if(!$table.manyRelationshipRoles.empty)
* Collections:
*
#foreach($role in $table.manyRelationshipRoles)
* $table.getVariableName($role)
#end
#end
*/

package ${table.package};

import java.util.Set;
import java.util.Iterator;

public class _${table.baseClassName}Model extends Model
{
AND SO ON...


3. Then you edit the entity-cmp-20.vm so that you nuke the ejbCreates
and add your own. I also nuke the remote interfaces since we never use
those on entity beans (session facade, always).




-----Original Message-----
From: ***@nascopgh.com [mailto:***@nascopgh.com]
Sent: Thursday, May 22, 2003 8:59 AM
To: middlegen-***@lists.sourceforge.net
Subject: RE: [Middlegen-user] Value Object support++



Eivind's branched version of the entity CMP velocity template
does the part you mentioned about creating the ejbCreate(valueobject)
method.

I'd be interested in hearing more about your approach, however.

Dave




"Rod Macpherson" <***@verilet.com>
Sent by: middlegen-user-***@lists.sourceforge.net

05/22/2003 10:57 AM
Please respond to middlegen-user


To: <middlegen-***@lists.sourceforge.net>
cc:
Subject: RE: [Middlegen-user] Value Object support++



One of the first things I ditched was the Xdoclet value object
implementation. Instead I generated my own value objects with a
velocity
template and a <java> sub-task: very clean, very simple. The
next thing
I ditched were the create and find methods by customizing the
default
CMP velocity script. We really did not want those gigantic
ejbCreate
methods (yikes!) where every column was represented with a
parameter. I
replaced that with a single value object ejbCreate.

-----Original Message-----
From: Eivind Waaler [mailto:***@tihlde.org]
Sent: Wednesday, May 21, 2003 11:50 PM
To: middlegen-***@lists.sourceforge.net
Subject: Re: [Middlegen-user] Value Object support++


I've already replaced XDoclet ejb module included in the CVS
branch.
Just check it out:

http://tinyurl.com/cdi8

The changes are a real hack, as I don't really know much about
XDoclet
and simply wanted it to work ASAP. I've simply hardcoded the
names of
the Middlegen value objects in there.

I'm using the XXValue as return value and XXLightValue as
parameter to
most of the methods (since relationships are now handled only
with the
FK field directly). But since XXValue extends XXLightValue that
should
not be noticable for the user. Typical methods in facade:

public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders

We've successfully deployed a remote application in JBoss from a
database with 100 tables using this Middlegen version. A total
of around
1300 compiled classes, all generated! Being accessed from a
standalone
Java client..

Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
using
Post by D***@nascopgh.com
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() &
.getValue()
in
Post by D***@nascopgh.com
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit
in a
relational database is painful, don't do it! Check out
ObjectStore. Now
part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
middlegen-user mailing list middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit
in a
relational database is painful, don't do it! Check out
ObjectStore.
Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
middlegen-user mailing list
middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user
Eivind Waaler
2003-05-23 12:31:04 UTC
Permalink
Could you explain more why you chose to generate your own value objects?

What is the problem with the xdoclet generated ones as you see it?

Just asking to get a better overview. I'd rather use the xdoclet ones,
unless there are some major advantages of making your own.

Would be nice if we could come up with a smooth solution to this :-)

.eivind
Post by Rod Macpherson
1. First part is to add a java sub-task to your middlegen so you get a
file with the bean name (the {0} variable) with Model or something else
<java name="model" destination="${build.source}"
package="com.acme.model">
<fileproducer filename="{0}Model.java"
destination="${build.source}" template="./velocity/model.vm"/>
</java>
2. Then you create your model.vtl using all of the "stuff" that is in
the velocity context by middlegen. Here is the commen theader of my
/***********************************************************************
*******
*
* Value object representing the ${table.sqlName} database table.
*
*
* ${table.pkColumn.variableName}
*
#if(!$table.foreignKeyColumns.empty)
*
#foreach($column in $table.foreignKeyColumns)
* ${column.variableName}
#end
#end
*
#if(!$table.mandatoryNotKeyColumns.empty)
*
#foreach($column in $table.mandatoryNotKeyColumns)
* ${column.variableName}
#end
#end
*
#if(!$table.manyRelationshipRoles.empty)
*
#foreach($role in $table.manyRelationshipRoles)
* $table.getVariableName($role)
#end
#end
*/
package ${table.package};
import java.util.Set;
import java.util.Iterator;
public class _${table.baseClassName}Model extends Model
{
AND SO ON...
3. Then you edit the entity-cmp-20.vm so that you nuke the ejbCreates
and add your own. I also nuke the remote interfaces since we never use
those on entity beans (session facade, always).
-----Original Message-----
Sent: Thursday, May 22, 2003 8:59 AM
Subject: RE: [Middlegen-user] Value Object support++
Eivind's branched version of the entity CMP velocity template
does the part you mentioned about creating the ejbCreate(valueobject)
method.
I'd be interested in hearing more about your approach, however.
Dave
05/22/2003 10:57 AM
Please respond to middlegen-user
Subject: RE: [Middlegen-user] Value Object support++
One of the first things I ditched was the Xdoclet value object
implementation. Instead I generated my own value objects with a
velocity
template and a <java> sub-task: very clean, very simple. The
next thing
I ditched were the create and find methods by customizing the
default
CMP velocity script. We really did not want those gigantic
ejbCreate
methods (yikes!) where every column was represented with a
parameter. I
replaced that with a single value object ejbCreate.
-----Original Message-----
Sent: Wednesday, May 21, 2003 11:50 PM
Subject: Re: [Middlegen-user] Value Object support++
I've already replaced XDoclet ejb module included in the CVS
branch.
http://tinyurl.com/cdi8
The changes are a real hack, as I don't really know much about
XDoclet
and simply wanted it to work ASAP. I've simply hardcoded the
names of
the Middlegen value objects in there.
I'm using the XXValue as return value and XXLightValue as
parameter to
most of the methods (since relationships are now handled only
with the
FK field directly). But since XXValue extends XXLightValue that
should
public FlightValue create(FlightLightValue value)
public FlightValue update(FlightLightValue value)
public void removeEntity(FlightLightValue value)
+ finders
We've successfully deployed a remote application in JBoss from a
database with 100 tables using this Middlegen version. A total
of around
1300 compiled classes, all generated! Being accessed from a
standalone
Java client..
Regards
.eivind
Post by D***@nascopgh.com
Eivind: this looks great! Thanks for the work.
using
Post by D***@nascopgh.com
dataobjects, not valueobjects, and so it inserts calls to
realEJB.getData() and .setData() instead of .setValue() &
.getValue()
in
Post by D***@nascopgh.com
the Facade.
I guess in order to use this one could just replace XDoclet's
entityfacade.xdt
Dave
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit
in a
relational database is painful, don't do it! Check out
ObjectStore. Now
part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/middlegen-user
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit
in a
relational database is painful, don't do it! Check out
ObjectStore.
Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user
Eivind Waaler
2003-05-23 12:31:07 UTC
Permalink
Post by D***@nascopgh.com
So, you re-jarred XDoclet w/ this version of the template?
I got the latest version of xdoclet from cvs, made the changes to the
template and rebuilt the ejb module. I've added the new jar file to the
samples/lib dir of middlegen as
xdoclet-ejb-module-1.2b3-dev-MIDDLEGENVO.jar. Also added the template
itself, just to make sure the changes are not lost.
Post by D***@nascopgh.com
I'd be interested in helping out w/ this, BTW.
That would be awsome. There's plenty of work on this for sure.
Post by D***@nascopgh.com
I wonder if the XDoclet team would take a patch switching to VO's?
I've submitted my changed template as a patch. Though this is hardcoded to
Middlegen style value objects so probably not much use for anyone.
Eivind Waaler
2003-05-23 12:57:07 UTC
Permalink
Post by D***@nascopgh.com
Eivind,
What's the TreeBuilder referenced in the comments in entity-cmp-20.vm on
the branch?
The TreeBuilder is a way to overcome the entity reentrancy problem which
occurs with bi-directional relationships. The current solution simply lets
all relationships be returned as light value objects to avoid it. This
means we can't have more than 1 level of relationship under each value
object.

The TreeBuilder can build a tree of value objects given a path expression
as to what relationships to include. It requires a method called
getValueObject() on each entity bean.

The example of use is like this. Say you have an entity called membership,
with a member variable and a subscription variable, you could pass the
following string to the TreeBuilder to specify what relationships you want
included in the MemberShipValue object:

"Member.*, Subscription, Subscription.vehicle"

This will return a MemberShipValue object with a MemberValue with all
attributes set and a SubscriptionValue object with only the VehicleValue
attribute set.

I haven't had time to include it in middlegen yet, quite complex stuff
this.

.eivind
Post by D***@nascopgh.com
Dave
D***@nascopgh.com
2003-05-27 20:46:02 UTC
Permalink
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
Eivind Waaler
2003-05-28 05:09:08 UTC
Permalink
I'm not sure I understand your problem. The field is spelled wrong in the
hasIdentity() method? What about the regular value object? It should be
excactly the same there.

My guess if there's something wrong with the value objects, is that
there's a bug in xdoclet. The template for value objects is in the ejb
module of xdoclet, but I haven't made any changes to this..

Check out the XxBean class of your table, see if there's anything in there
that could lead to the error in the value object.

.eivind
Post by D***@nascopgh.com
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
D***@nascopgh.com
2003-05-28 13:45:06 UTC
Permalink
OK, this is wierd and I think it's definitely an XDoclet bug. It's not
lowercasing the first letter of the field names on just 2 of the VO
classes, and they both have DB fields that start w/ 2 caps. Aha! Same for
the CMP classes, which is probably what it uses to make the VOs! I think
I'm on the trail...

Dave
D***@nascopgh.com
2003-05-28 14:30:14 UTC
Permalink
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





***@nascopgh.com
Sent by: middlegen-user-***@lists.sourceforge.net
05/27/2003 06:44 PM
Please respond to middlegen-user

To: middlegen-***@lists.sourceforge.net
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

Loading...