xdoclet

[edwardkenworthy]

I'm probably missing something, but xdoclet confuses me.

As I understood it the EJB deployment descriptor allowed you to separate environment configuration (eg data-base mapping) from the implementation (the Java code).

xdoclet seems to screw that up. If I use xdoclet I have to embed environment information (eg database mapping) into my java source files, which means when they change I have to change my java source - and re-run all the unit tests and up...

If that's the case who would be mad enough to use xdoclet ? Or am I missing the point ?

[sgturner]

Yup, you are missing it. First of all, this is a JBoss site, not Xdoclet. Comments/questions are better posted to forums/lists/etc. having to do with Xdoclet.

[edwardkenworthy]

Why don't you sod off. So far you've made utterly worthless responses to two of my postings. If you don't know the answer, or even understand why it's relevant to JBoss then you'd be better off keeping your mouth shut. At least that way the rest of us would only *suspect* you're an idiot.

[pvamstel]

It is confusing to me as well.

Where do you use XDoclet for????

[edwardkenworthy]

It's used in the template and examples for 3.0 to build the home and remote interfaces and the deployment descriptors. See chapter 3 of the quickstart guide.

[juha]

Dude,


> Why don't you sod off. So far you've made utterly
> worthless responses to two of my postings. If you
> don't know the answer, or even understand why it's
> relevant to JBoss then you'd be better off keeping
> your mouth shut. At least that way the rest of us
> would only *suspect* you're an idiot.


You're way out of line. Greg Turner is one of the best contributors to these forums. Telling him to go "sod off" will not help anyone, least of all you. You're the one ending up looking like an idiot here.

-- Juha

[bruyeron]

You do not HAVE TO embed DB mappings in your code. But you can...

XDoclet is great to generate code automatically (home/remote/local interfaces, MBean interfaces, etc). This stuff is usually monkey stuff, and it's a monster pain to have to go through all these interfaces when you modify/refactor your code...

It is also great to generate the ejb-jar descriptors, or at least a template for them.

As for the vendor deployment descriptors (the ones where the DB mappings are), xdoclet can generate a template for you, which is great because that way you do not forget / miss anything. Then in your build, you can add your own site customization (through Xdoclet's own extension points or via your own stuff (XSL ?)) to what xdoclet generated.

IMHO, the point of xdoclet is that 99% of the ejb descriptors and 90% of the vendor-specific stuff can be generated from the source (and 100% of the interfaces). I am exagerating the % to make a point.

- Renaud

[edwardkenworthy]

juha

best ? wow the standard must be really low. From the evidence, ie his recent postings, he strikes me as an utter waste of oxygen.

Now, did you have anything *on topic* (there's a novel thought) to add or are you just blowing hot air as well ?

[edwardkenworthy]

bruyeron

yes I know all that. But if you do that you embed appserver specific code in your EJBs, which was part of the reason for having deployment descriptors in the first place.

Anyway, I've found the answer - elsewhere - which I'll decline to share here as that appears to be the culture of this forum.

[cyates]

Well I figure that makes you not only childish, but also a hypocrite.

If you are going to criticise other people's behaviour, don't reproduce that behaviour :)

Don't forget how much time people put into monitoring and answering questions asked in these forums. You act like you have a *right* to get answers. You don't. Particularly when you can't be bothered to share information that you have learnt.

Too many people ask a question, find the answer somewhere else and don't bother sharing it on these forums.

I am only passing on a lesson that I had to learn :)

[cepage]

I think your point about the deployment descriptor separating environment configuration from the implementation is very valid once a component has stabilized. Once I have released a component, I no longer use Xdoclet to continually regenerate the descriptors.

But during the development process, Xdoclet can be a great help. For entity beans, generating and debugging deployment descriptors can be very time-consuming, and Xdoclet provides a convenient and intuitive manner to generate and update the deployment descriptors during the development process.

Corby

[burnsanthony]

you make an excellent point about the sharing the info I totally agree

I still dont understand Xdoclet or what exactly it is used for

[mnewcomb]

XDoclet supports the idea of continuous integration.

For example:

A typical entity bean has several different files that changes to it may impact:

5 classes:
- Remote class
- Remote Home class
- Local class
- LocalHome class
- Bean class

Deployment descriptor:
- ejb-relationship section
- entity definition
- permissions

Application descriptor(s):
- jboss.xml
- jbosscmp-jdbc.xml
- jaws.xml

So, that is a sh*tload of things to change if you decide to rework the bean. Now, mutiply that times 10-50 entity beans per project (maybe more)!

That's where XDoclet comes in.

You use custom XDoclet javadoc-style tags to 'tag' your bean and those methods. From there, XDoclet uses your tags to auto-generate the mundane stuff like the all the interfacs (Remote, RemoteHome, Local, LocalHome) the deployment descriptor (ejb-jar.xml) and most of the application specific deployment descriptors (jboss.xml, jbosscmp-jdbc.xml, and jaws.xml).

That way, when you want to make a change, you do it in *one* place, the Bean class. Your bean class can have XDoclet tags for JBoss, WebSphere, JRun, etc... and when building the class, it can generate a different JAR for each server and can be dynamically deployed to any one.

Michael