Is XDoclet useful if i am using IBM Websphere

[Ashok C M]

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]

"widow black",
Please go and change your display name. It is clearly a fake and thus in violation of our naming policy.
Thanks.

[Lasse Koskela]

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]

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]

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]

I'm using ant right now.....What difference will it make if i use xdoclet?

[Lasse Koskela]

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]

Does, it mean we no need to use Application assemble tool of websphere.. to generate deployable jar file.

[Ashok C M]

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]

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]

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.....

[Lasse Koskela]

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]

Oh! So do you mean to say that XDoclet does only what ant does.?Nothing more?

[Dave Coombes]

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]

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]

Can u guide me to any information regarding the use of XDoclet with IBM Websphere? I would be grateful....

[Ashok C M]

What can XDoclet do that Ant cannot do(when using IBM Websphere)?

[Lasse Koskela]

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]

Does that mean that XDoclet is useles for IBM Websphere?

[Lasse Koskela]

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]

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.

[Lasse Koskela]

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]

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]

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]

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]

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]

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.

[Craig Walls]

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]

Excellent explantation Craig. Thanks for that.

[Ashok C M]

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]

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:

 
EmployeeLocalHome localHome = EmployeeUtil.getLocalHome();
EmployeeLocal employee = localHome.create("Smith", "Bob");
return employee.getEmployeeValue();
 

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]

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]

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]

thanx lasse for the info...

[Craig Walls]

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.