• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

what will happen to XDoclet once EJB 3.0 is released?

 
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Author
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Where all the women are strong, all the men are good looking and all the tiny ads are above average:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic