File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes XDoclet Session Layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "XDoclet Session Layer" Watch "XDoclet Session Layer" New topic
Author

XDoclet Session Layer

Sheila Wallace
Greenhorn

Joined: May 24, 2001
Posts: 10
I am using XDoclet to generate interfaces and deployment descriptors for Session Beans. XDoclet has generated an additional 'Session Layer' class called [BEanNAme]Session which extends my original Session Bean and contains lifecyfle methods which pass through to my original bean. This seeems like a complete waste of time to me and I was wondering if anyone knows why these have been generated and an easy way to stop it.
Thanks in advance
norman richards
Author
Ranch Hand

Joined: Jul 21, 2003
Posts: 367
I see many people who create a sort of abstract base class the provide default implmentations of the lifecycle methods. If you don't want to do that, XDoclet can generate them underneath you. It's really a clever concept. Instead of generating a superclass that you have to extend, it generates a subclass and uses that as the bean instead. If you are using DAOs, the session subclass can provide DAO access methods, but other than that you probably aren't going to get tons of value from it. The value is a bit clearer when you are using entity beans. The entity bean subclass can implement the value object methods, for example.
If you don't want the session subclass, then don't use the session subtask. You can still generate your interfaces and the deployment descriptor without it...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XDoclet Session Layer