Win a copy of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications this week in the Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

what will happen to XDoclet once EJB 3.0 is released?  RSS feed

 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Version 3 seems to have a lot of changes, and it aims to minimize the code we write to develop EJB (with the help of metatags). So I think they're "borrowing" some of the excellent principles that XDoclet has. I don't know on what extend EJB 3.0 will overlap the use of XDoclet.
any opinions?
 
norman richards
Author
Ranch Hand
Posts: 367
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's hard to say how JSR 175 metadata will be applied to EJB development. I wouldn't shed any tears if XDoclet needed to generate a few less things. I'd love it if XDoclet could focus more on the complex generation tasks like value objects and DAOs and less on generating yet-another-redundant interface. In addition to seeing how metadata can replace code generation, I'm curious to see how metadata can be used as an input source for XDoclet code generation.
 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by norman richards:
It's hard to say how JSR 175 metadata will be applied to EJB development. I wouldn't shed any tears if XDoclet needed to generate a few less things. I'd love it if XDoclet could focus more on the complex generation tasks like value objects and DAOs and less on generating yet-another-redundant interface. In addition to seeing how metadata can replace code generation, I'm curious to see how metadata can be used as an input source for XDoclet code generation.

Does XDoclet have support for VAO and DAO generation? I've used XDoclet months ago but never used that. It'd be awesome!
 
Mcgill Smith
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the combination of the XDoclet tags and the ejbdoclet subtask cause
XDoclet to generate the value objects for entity beans.
please correct me if i am wrong.
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right. <ejbdoclet> has two subtasks, <valueobject> and <dataobject>, that generate value object classes for your entity beans. Which should you use? Always use <valueobject;> because it's much improved and <dataobject> has been deprecated.
There's also a <dao> subtask that can generate DAO interfaces for your BMP entity beans. It just generates an interface, no SQL or anything like that. And it's only useful with BMP entity beans. I've only used this subtask with a quick example in the book and have since forgotten it...I'm not a BMP entity bean fanatic and would prefer CMP entity beans (actually, I prefer Hibernate over any entity bean, but that's another story.)
 
norman richards
Author
Ranch Hand
Posts: 367
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The value object generation is very cool. You mark which fields belong on the value object and then XDoclet will generate the value object and will generate the methods to transfer the data to/from the value object.
Another nice feature is that you can generate multiple views. You might want one value object that just has your primary key and a couple of attributes to use on a list/summary page and then have another value object that contains the full view (maybe aggregating data from related beans) that you want to use when you display the details of a specific item.
It's very handy...
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!