xdoclet q

[Pradeep bhatt]

Howdy,

Consider that If I use Xdoclet to generate primary key of an entity EJB. i modify the source. Now again I make change to xdoclet and run the script. Is Xdcolet smart enough to retain the changes that I made to the primary key source.
I am new to Xdoclet, so if this looks stupid please ignore the post.
Thanks

[norman richards]

You won't make changes to the primary key source directly. You will generate your primary key to a temporary directory away from your main source tree. You will not check the generated files into your revision control system and you will make sure that they are deleted when in your "clean" target.
In XDoclet, you only touch the inputs and not the outputs. The two most common ways you
will make changes to your generated class is through merge files and through superclasses. Merge files let you insert code into the generated class when XDoclet runs. Your merge files can be full XDoclet templates, if you like, which means you can do just about anything you
want. Another common method that most tasks support is specifying a superclass for the generated class. The generated class can extend your superclass and inherit functionality that way.
But, the rule is that you only change the inputs...

[Craig Walls]

Originally posted by Pradeep Bhat:
Consider that If I use Xdoclet to generate primary key of an entity EJB. i modify the source. Now again I make change to xdoclet and run the script. Is Xdcolet smart enough to retain the changes that I made to the primary key source.

I'm not sure that I understand the question. But let me try anyway.


First off, you probably won't use XDoclet to generate a primary key for an entity bean. A primary key is a data element that should be generated at runtime, while XDoclet is a build-time code generation tool.


That said, there is a <utilobject> subtask of <ejbobject> that generates a nifty utility class. This utility class (among other things) has a method useful for generating globally unique IDs (GUIDs). The GUIDs generated from this method are 32-character strings that are unique to the server's IP address, to an object's hash code, to the millisecond and to a SecureRandom. These GUIDs are suitable for use as primary keys of entity beans.


But, don't get the two pieces confused: XDoclet is a code generation tool. One of the many artifacts it can generate is an EJB utility object which has a method useful for generating GUIDs.

[Lasse Koskela]

I believe Pradeep was talking about primary key classes(?)

[Craig Walls]

Originally posted by Lasse Koskela:
I believe Pradeep was talking about primary key classes(?)

A-ha! My bad. I wasn't even thinking about PK classes. I so rarely use PK classes because I'm a firm believer in avoiding complex primary keys.


In the case of PK classes, what Norm said applies. Always keep your generated code separate from your main codebase and never check your generated code into source control.

[norman richards]

Originally posted by Craig Walls:

A-ha! My bad. I wasn't even thinking about PK classes. I so rarely use PK classes because I'm a firm believer in avoiding complex primary keys.

Same here. I've only worked on one project that used wierd primary keys, and then the primary key was really just a long value in a typed wrapper. (you couldn't mistakenly use a FooPK when I BarPK was called for...

[Pradeep bhatt]

Originally posted by Lasse Koskela:
I believe Pradeep was talking about primary key classes(?)

Yes, I was. I accept that my wordings were not good.

[David Harkness]

Originally posted by norman richards:
... then the primary key was really just a long value in a typed wrapper. (you couldn't mistakenly use a FooPK when I BarPK was called for...

Was that worth the trouble? I suppose with XDoclet each bean's PK class could be generated automatically, but did you really see a benefit to doing this? I chose Integer and defined database PKs as number(10). While I doubt we'll go past that (2 billion rows?), I'm thinking a Long may have been a better choice to be safe. However, that means changing a lot of code. In this case, had I defined a PK class (even one shared by all beans), making the change would have been trivial.
The reason I didn't go that route is that using PK classes seemed like such a PITA (especially before XDoclet).

[norman richards]

Originally posted by David Harkness:

Was that worth the trouble? I suppose with XDoclet each bean's PK class could be generated automatically, but did you really see a benefit to doing this?

I didn't initiate the practice on the project, and I wasn't a huge fan of it. But that was how the system worked when I got there. There's definitely some value in making sure you don't get ids confused, but I'm not sure it really demands typed primary keys. Most of the primary key classes went away in the migration to XDoclet, but there are still some used in some old BMP classes.

[David Harkness]

Originally posted by norman richards:
I didn't initiate the practice on the project, and I wasn't a huge fan of it. But that was how the system worked when I got there.

I cannot begin to count how many times I've said/thought that myself. I wouldn't have used entity beans in my current project, but that's what I inherited. They're used as simple row-level objects, and if I get my way we'll swap them out for Hibernate and POJOs.
For PK classes, I'd probably forego creating one for each bean and just create a generic one for the whole system (ObjectID or something). This would have eased the pain if I ever switch from Integer to Long. Instead of multiple PK classes, couldn't you add an "object type" attribute to the PK class? To create a PK for a User, you'd do

Long userID = ...
ObjectID userPK = new ObjectID(DomainConstants.USER, userID);

Then whenever you expect a User PK you could verify that it had the correct "object type". This avoids creating multiple PK classes with the disadvantage of less clean code as the above would be simpler as

UserPK pk = new UserPK(userID);

Yet another compile-time-versus-run-time tradeoff.