File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Java Products and Servers and the fly likes Is XDoclet useful if i am using IBM Websphere Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Other Java Products and Servers
Bookmark "Is XDoclet useful if i am using IBM Websphere" Watch "Is XDoclet useful if i am using IBM Websphere" New topic
Author

Is XDoclet useful if i am using IBM Websphere

Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
I'm using IBM websphere to deploy J2EE applications(mainly IBM portlets)....Is XDoclet in anyway useful to me?......The IDE that i'm using is eclipse.....
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
"widow black",
Please go and change your display name. It is clearly a fake and thus in violation of our naming policy.
Thanks.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
XDoclet is useful if you use Ant for building your sources and would prefer writing deployment descriptors into javadoc comments instead of the actual deployment descriptor files.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
I badly wanted to...Can u tell me how to do it....i searched for a link to change my display name...I had to give this name as the system was not accepting my name saying that it is already in use.....I f u could help me i'll do it now....
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
ya ya i got it and have changed it.....thanx for the link..... but tell me what u mean by javadoc comment...
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
I'm using ant right now.....What difference will it make if i use xdoclet?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
The difference will be that you don't write, for example, ejb-jar.xml and websphere-ejb-jar.xml (or whatever) yourself. Instead, you write the metadata that would go into those XML files into your EJB code's javadoc comments and let XDoclet generate the XML files for you during the build.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
Does, it mean we no need to use Application assemble tool of websphere.. to generate deployable jar file.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
Because, even now i'm not writing ejb-jar.xml and other dependancy files.....It is generated by the Application Assembly Toolkit provided by IBM.......
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
In that case, no, you're not using Ant for your builds. You're using the Application Assembly tool and XDoclet is not at your disposal.
Ashok C. Mohan
Ranch Hand

Joined: Dec 03, 2003
Posts: 75
I'm using ant to build the deployable files and then using AAT to assemble them in a websphere specific way....with all dependant files.....


SCJP 1.4
Do not dwell in the past, do not dream of the future, concentrate the mind on the present moment.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ok. Then using XDoclet would mean that you do <whatever-you-do-using-AAT> with Ant from now on.
Something like:
1) run XDoclet to generate standard and WebSphere specific deployment descriptors
2) compile everything
3) package into .ear/.war/.jar
Ashok C. Mohan
Ranch Hand

Joined: Dec 03, 2003
Posts: 75
Oh! So do you mean to say that XDoclet does only what ant does.?Nothing more?
Dave Coombes
Greenhorn

Joined: Nov 06, 2001
Posts: 19
For what its worth, we are currently using XDoclet in a project deploying in to Websphere and JBoss. It works very well, dramatically reducing the number of atrificats we have to keep under CVS. However, we did need to make some extensions to generate certain elements of the IBM specific deployment descriptors.
Cheers
Dave
norman richards
Author
Ranch Hand

Joined: Jul 21, 2003
Posts: 367
I am not a regular websphere user, so I can't comment from practical experience. But, XDoclet does have websphere tasks and tags that others are using with great success. (in addition to the core EJB/web tasks which are app server independent)
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
Can u guide me to any information regarding the use of XDoclet with IBM Websphere? I would be grateful....
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
What can XDoclet do that Ant cannot do(when using IBM Websphere)?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ashok C.M.:
What can XDoclet do that Ant cannot do

Ant is a build system. XDoclet is a code generation framework. Thus, Ant cannot do anything what XDoclet does and vice versa.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
Does that mean that XDoclet is useles for IBM Websphere?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ashok C.M.:
Does that mean that XDoclet is useles for IBM Websphere?
No. XDoclet can be useful if you use Ant to build your system, regardless of which application server you use.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Lasse Koskela:
No. XDoclet can be useful if you use Ant to build your system, regardless of which application server you use.

Here's how it is all supposed to work when using XDoclet with WebSphere (these same concepts apply to other appservers, as well):

  • Ant is your build system. It does several things, most notably running XDoclet, compiling your code, and packaging everything up in WAR and/or EAR files.
  • XDoclet is the code-generation system. Your WebSphere app will definitely need the basic deployment descriptors (such as web.xml and maybe ejb-jar.xml). XDoclet can generate these for you. You may also need the WebSphere-specific deployment descriptors (such as ibm-web-ext.xmi, ibm-web-bnd.xmi, ibm-ejb-jar-ext.xmi, or ibm-ejb-jar-bnd.xmi). XDoclet's WebSphere module can generate those for you. You may also need some other nifty gadgets such as EJB utility classes, value object classes, or JSP TLD files. XDoclet can generate those for you, too.


  • Granted, WebSphere has this GUI-based admin console that generates the WebSphere-specific stuff as you deploy, but IMO it's a piece of junk. Even so, you still benefit from XDoclet instead of the admin console because of the other stuff XDoclet can generate for you (value objects, TLDs, etc).

    Now the disclaimer...I work with WebSphere 4 daily but I don't use XDoclet to generate the WS-specific stuff (yet). The main reason is that the project I'm on doesn't really need the proprietary stuff. We're content to just click "Next" 12 times and then "Finish" to deploy.

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Craig Walls:
We're content to just click "Next" 12 times and then "Finish" to deploy.
Isn't that still a real drag to do everytime you make a build?
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Lasse Koskela:
Isn't that still a real drag to do everytime you make a build?

It is ridiculous, but it's not too bad. We develop and do our basic testing on Tomcat. We don't move it to WebSphere until we're darn ready. At that point, our finger is trained to click "Next" 12 times without us even thinking about it. Sure, I'd rather not do it that way, but it isn't that bad when you consider we only deploy to WebSphere once every day or so.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
So atlast we have come to the conclusion that, there is no point(atleast for now) in using XDoclet for IBM Websphere. The AAT is the best option now. Is'nt it? Do you have anything to say on this comment , Craig
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Ashok C.M.:
So atlast we have come to the conclusion that, there is no point(atleast for now) in using XDoclet for IBM Websphere. The AAT is the best option now. Is'nt it? Do you have anything to say on this comment , Craig

Not necessarily. Using XDoclet for WebSphere comes in two forms: Using it for WebSphere-specific deployment descriptors and using it for all of the other stuff that can be generated that has nothing to do with WebSphere.
If you are not using WebSphere-specific DDs, then obviously you shouldn't use XDoclet to generate those DDs. That's the case with the projects I'm on.
But, there's still benefit to be gained by using XDoclet with WebSphere (or whatever app server you use). With EJBs you can generate the basic ejb-jar.xml deployment descriptor, home/local/remote/localhome interfaces, utility objects, concrete EJB class (ask what this is and I'll explain further), value objects, etc, etc. For your JSP tag libraries, you can generate TLD file. For your servlets, filters, and listeners, you can generate the basic web.xml file. For Hibernated projects, you can generate Hibernate mapping files. The list goes on.
On my project we do not do anything WebSphere-specific, so we don't use XDoclet for that. We'd prefer not to use the admin tool (it's horrible), but there's another factor that forces us to use it. Our so-called system admins keep the boxes locked down pretty tightly and won't let us deploy an EAR file directly outside of the tool. We choose our battles and decided not to argue with them on this one. So we happily continue to click "next" 12 times to deploy. (Given the choice...we'd never touch that horrible admin tool.)
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Craig Walls:
...concrete EJB class (ask what this is and I'll explain further)...
I'll bite. What is it? Does XDoclet then generate the Java source that the vendor's "EJB compiler" such as ejbc would generate anyway?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

We'd prefer not to use the admin tool (it's horrible)

..and I just used it. May be I shouldn't from your experience. Take no chances and use XDoclet.


Groovy
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Lasse Koskela:
I'll bite. What is it? Does XDoclet then generate the Java source that the vendor's "EJB compiler" such as ejbc would generate anyway?

I was hoping someone would ask. :-)
When developing EJBs there are always these pesky methods such as ejbActivate(), ejbPassivate(), ejbLoad(), ejbStore(), etc that you must implement just because the EntityBean and SessionBean interfaces say you must. Nine times out of ten, these end up being empty methods, but you have to write them anyway because the interfaces make you do it.
With XDoclet there's an easier way. All of these empty implementations of EJB lifecycle methods are boilerplate code. XDoclet excels at handling boilerplate code. The <ejbdoclet> task has three subtasks--<entitybmp>, <entitycmp>, and ;<session>--that generate this boilerplate code for you. Notice that there's a subtask each for BMP, CMP, and session beans. If you're not using BMP beans, you don't need to use the <entitybmp> subtask.
When you write your EJB implementation class, go ahead and have it implement the appropriate interface (EntityBean or SessionBean), but don't write the empty methods. So that the compiler won't complain, declare your class as abstract. When the aforementioned subtasks get hold of your EJB class, they'll generate concrete subclasses of your EJB classes that include empty implementations of the lifecycle methods.
So, what if it's one of those rare occasions where you do what to implement the lifecycle method yourself? Simply go ahead and implement them in the abstract class and XDoclet won't override your methods when it creates the concrete subclass.
As if that wasn't cool enough, if you're using XDoclet to generate value objects for you, then the concrete implementations will also have convenience methods for constructing value objects from entity beans. What's even cooler than that, is that if your entity beans also have CMR relationships defined through XDoclet, there'll also be convenience methods for dealing with the relationships within the value objects.
All in all, this is one of the coolest things XDoclet can do for you if you are working with EJBs.
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Excellent explantation Craig. Thanks for that.


I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
WOW! That was some pretty good explanation i heard in years.Hats off to you Craig.....
I never knew that i can do all that stuff(like generate TLD file for the tag libs )using XDoclet....
And even XDoclet will create concrete implementations ? That is real cool...Maybe i should start using XDoclet...
then the concrete implementations will also have convenience methods for constructing value objects from entity beans.

Can you please expand on the value objects part....
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Ashok C.M.:
Can you please expand on the value objects part....

No problem. You can use the <valueobject> subtask of <ejbdoclet> to generate value objects for your entity EJBs. It's fairly straightforward--just add the <valueobject> subtask to your build and then tag your entity bean classes with @ejb.value-object. There's some other fancy stuff you can do, such as generating value objects that contain a subset of the entity's properties and dealing with relationships, but I'll defer those rather hefty topics for another time (or I can also suggest a book that covers it )
If you're letting XDoclet generate value objects for you and you're also letting XDoclet generate concrete implementation classes, then you're in for a real treat. The concrete classes will contain handy methods for constructing value objects. So, let's say that you have a session bean acting as a session facade to your entity beans. You don't want the client of the session facade to have to deal with the entiry beans directly and so that's why you're using value objects. Once the session facade has the reference to the entity bean, it can simply make a call to one of these value object constructor methods to get a fully populated value object instance.
For example, suppose that you're session facade class is to return a value object for an employee entity bean. You have a reference to the local interface of the entity bean. Here's what it might look like to return the value object:

Now...what's not clear in this simple example is that the EmployeeLocalHome interface, the EmployeeUtil utility class, the EmployeeLocal interface, and the EmployeeValue class that is being returned are all generated by XDoclet. Refer to the book's examples for a complete example of how this all gets pulled together (and feel free to ask me if you need further insight).
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
That is some real cool info on what XDoclet can do.... Now i really feel like using it....As soon as possible....
Now...what's not clear in this simple example is that the EmployeeLocalHome interface, the EmployeeUtil utility class, the EmployeeLocal interface, and the EmployeeValue class that is being returned are all generated by XDoclet. Refer to the book's examples for a complete example of how this all gets pulled together (and feel free to ask me if you need further insight)

I think i'll bite on that bait......Please....
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ashok, now that you've started a new topic for this question, it would be polite to delete the identical post in this topic. You can do that in the "edit post" view by selecting the "Delete Post" checkbox before submitting the form.
Thanks.
Ashok C M
Greenhorn

Joined: Dec 03, 2003
Posts: 17
thanx lasse for the info...
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Ashok C.M.:
That is some real cool info on what XDoclet can do.... Now i really feel like using it....As soon as possible....

I think i'll bite on that bait......Please....

Without posting very large sections of chapter 3 here, I really can't go into much detail. This is where I invite you to take a look at the book's example code, run the builds for yourself, and see how it all fits together. If you run into trouble or have questions as you do this, I'm happy to help.
But, to summarize:
  • <localinterface> generates local interfaces for EJBs
  • <localhomeinterface> generates local home interfaces for EJBs
  • <valueobject> generates value object classes for entity beans
  • <utilobject> generates utility object classes for EJBs
  • <entitybmp>, <entitycmp>, and <session> generate concrete implementations of EJB classes, implementing the lifecycle methods (such as ejbActivate(), ejbPassivate(), etc).


  • What's magical about this is that when you use all of these together, the code that each subtask generates works together very well with the code from the other subtasks. For example, as we discussed before, when you generate both value objects and concrete EJB classes, the concrete EJB classes will be generated with convenience methods for creating value objects.
    One thing I have forgotten to mention until now (slight change of topic) is that the utility class also has nifty methods for looking up EJB home interfaces. What's cool about these is that you can obtain a home interface in one line of code instead of writing all the JNDI setup yourself. Also, if you so choose (and you probably should), the utility object can cache the reference to the home interface for quick lookup of the same home interface later on.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Is XDoclet useful if i am using IBM Websphere