Discussions

News: Opinion: Is XDoclet really needed?

  1. Opinion: Is XDoclet really needed? (69 messages)

    Norman Richards, author of XDoclet in Action, has replied to a comment on whether XDoclet is needed. He discusses the uses of XDoclet (beyond generating EJB descriptors!), his thoughts about descriptors, and how he sees XDoclet fitting into the world of JSR 175.

    Specifically, there are going to be some things that you can't do with JSR 175. With an XDoclet approach you are acting as a pre-processor, outside of the rules of a compiler.

    What do you feel about XDoclet? Are people going to use it more and more for codegen? or is there a small backlash?

    Read Norman Richards in Is XDoclet really needed?

    Threaded Messages (69)

  2. Opinion: Is XDoclet really needed?[ Go to top ]

    am just curious, how many of you use XDoclet on live projects? doesn't XDoclet
    go hand in hand with the MDA paradigm with MDA tools being built
    upon XDoclet something(MDA paradigm) the original creator of XDoclet does not
    fancy at all?
  3. Opinion: Is XDoclet really needed?[ Go to top ]

    Ray,
    We use X-Doclet running with Eclipse or Ant scripts to develop our EJB components in our projects. It has saved us fair amount of time.

    Suneet Shah
    www.diamelle.com
  4. Opinion: Is XDoclet really needed?[ Go to top ]

    I use XDoclet extensively to create EJBs (MDBs and SSBs) as well as JMX components, including xmbean deployment descriptors. I've also used XDoclet to quickly expose those same EJB and JMX components as Web services. I find it an invaluable tool for generating all the container boiler-plate/glue code. Other projects in the company I work for use it with good success to generate Hybernate related files as well.

    Having the XDoclet meta-data in the source code can sometimes be troublesome, but in my case the deployment descriptors don't need to be modified for the different environments the application is deployed to so it is a "definciency" that I can certainly deal with. The benefits of not having to mess with stubs and deployment descriptors is well worth using XDoclet.

    Of course, this all begs the question of why do people care if XDoclet is really needed. If you need it, you will use it, if you don't you won't. What's the big mystery here? Even if something new were to come out, one still can decide which to use. I don't suspect that XDoclet is going to just disappear one day. I mean Perl is still around isn't it? :-) (j/k of course)
  5. >Dustin: Of course, this all begs the question of why do people care if XDoclet is really needed. If you need it, you will use it, if you don't you won't. What's the big mystery here?


    Need is a subjective thing. ;-D.
    In the software world, where folks love to jump on the latest zing thing with little thought just becuase it's cool and make the projects they work on as guinea pigs, a little discussion on what is better v/s not-so-better is essential.

    Dustin: Even if something new were to come out, one still can decide which to use.

    Informed decision always pays off. That's why.

    Cheers,
    Srikanth Shenoy
  6. Informed decision always pays off. That's why.

    >
    > Cheers,
    > Srikanth Shenoy

    I completely agree. But, if the point of this topic is broader then the title would imply, then maybe the topic should be "Is code generation really needed" not is XDoclet needed.
  7. I use Xdoclet extensively in systems that have since then been moved into production and have had several iterations of "enhancement". Xdoclet never got in the way unlike round-tripping with other code generation tools. Additionally, it saved us a lot of time and effort.

    Struts : before you give up on Struts config and Xdoclet, play around with Velocity templating and hopefully you can it to work for your case as well.


    Xdoclet can save you time and effort -- and if these are important to you, you have to invest in the learning curve.
  8. More than a time-saving tool[ Go to top ]

    Xdoclet can save you time and effort -- and if these are important to you, you have to invest in the learning curve.


    Code generation (ala XDoclet) is more than just time-savings. Yes, it can save you time. The most notable time-saving comes with using XDoclet to generate EJB artifacts.

    But it's also about keeping your codebase cleaner, leaner, and easier to manage. It's about writing DRY (don't repeat yourself) code. It's about programming close to the problem domain. It's about not having to flip between a half-dozen editors just to see how **ONE** component is defined.

    So, after reading what I just wrote, I guess it really is about saving time, but in a more indirect way. If my code's clean and DRY, it's probably easier to manage and thus easier to chase out bugs which translates into time saved to do other things.
  9. many people[ Go to top ]

    I think XDOCLET is the one of the bests things of J2EE

    retures all the need of mantaining lot os classes an lot o xml files

    i use xdoclet on live projects, many of then (5 more or less)

    regards,
  10. XDoclet[ Go to top ]

    I have used XDoclet in the development of an ERP solution and it has helped us save a lot of time and effort. We have made use of XDoclet in generating all the interfaces and deployment descriptors. The continuous integration of the modules that get developed in increments and the ease of incorporating new change in the code at any stage didnt cause any major set back to us. We found Xdoclet an extremely useful tool for EJB projects.

    Edwin Yaqub
    AdamSoft Intl.
  11. MDA and XDoclet[ Go to top ]

    They don't necessarily go together, but they can. You might check out AndroMDA, which generates XDoclet enhanced EJBs from a UML model. I find the approach fascinating because there is two layers of code generation. AndroMDA does it's specialized work in mapping details from the UML to the bean but it doesn't have to be concerned about all the messy details of the various EJB interfaces and deployment descriptors. Instead, is passes the relevant information to XDoclet, which is more of a specialist in EJB code generation. When small things change in EJB, the XDoclet side might need to change, but AndroMDA doesn't need to worry about those minor details.
  12. Opinion: Is XDoclet really needed?[ Go to top ]

    I use XDoclet for generating Hibernate descriptors and its a big time saver. Not only from creating lots of little hbm.xml files, but from trouble shooting the odd little typos that you can make when you create lots of relationships between objects. It works quite well for hibernate.
  13. I use XDoclet for generating Hibernate descriptors and its a big time saver. Not only from creating lots of little hbm.xml files, but from trouble shooting the odd little typos that you can make when you create lots of relationships between objects. It works quite well for hibernate.


    I'm reading this thread with great interest as I'm just starting to investigate XDoclet. For quite some time, I couldn't understand why someone would want to put configuration data back into source code when the whole purpose of config files are to decouple configuration from code.

    However, I can see some instances(mentioned above) where it can save some time. I would think the basic question you have to ask yourself is there any instance where I could alter the business functionality of my program without tampering with code? if yes, then using XDoclet might require rethinking. Does that sound correct( experienced XDoclet users)?

    Mike
  14. Opinion: Is XDoclet really needed?[ Go to top ]

    However, I can see some instances(mentioned above) where it can save some time. I would think the basic question you have to ask yourself is there any instance where I could alter the business functionality of my program without tampering with code? if yes, then using XDoclet might require rethinking. Does that sound correct( experienced XDoclet users)?


    Business logic isn't really the problem space that XDoclet addresses. It's primary function is to generate infrastructure code that you will have to build no matter what your business logic is.

    A good example is generating all the client stubs (Remote/Local/Home interfaces) for an EJB. You have to either generate these or write them by hand no matter what the EJB itself does. The nice part is that if you change a method signature in your EJB, you don't have to manually go thru all the EJB interfaces and make sure they match the new signature. You just regenerate them.

    Another example is generating DAO and Value Objects persistence frameworks like Hibernate or CMP. The DAO's themselves aren't really business logic per say, they are just storage objects that are subsequently used by your business logic layers.

    There may be cases where XDoclet can be or is used to change business logic behaviour, but I would guess that it is not the norm.
  15. Config info in source code[ Go to top ]

    For quite some time, I couldn't understand why someone would want to put configuration data back into source code when the whole purpose of config files are to decouple configuration from code.


    One of most overlooked (or unknown) things you can do in XDoclet is to reference Ant properties when you write you XDoclet tags. For example, let's say you're using XDoclet to generate web.xml for your servlets (not that servlets are the only place this concept can be applied) and you end up using @web.servlet-init-param to set an initialization parameter:

    /**
     * @web.servlet name="myServlet"
     *
     * @web.servlet-init-param
     * name="logLevel"
     * value="DEBUG"
     */
    public class MyServlet extends HttpServlet {...}

    This begs the question: Why would I hard-code an XDoclet tag with an initialization parameter when I could bypass XDoclet altogether and hard-code the "DEBUG" value everywhere I use it in XDoclet?

    But what if you did this?:

    /**
     * @web.servlet name="myServlet"
     *
     * @web.servlet-init-param
     * name="logLevel"
     * value="${log.level}"
     */
    public class MyServlet extends HttpServlet {...}

    Now we have something cool. We're telling XDoclet to generate a web.xml file for us, registering MyServlet in the web.xml and to put in the "logLevel" initialization parameter. But we're not going to tell XDoclet what the value of "logLevel" should be until compile time when we set the Ant ${log.level} property.
  16. Config info in source code[ Go to top ]

    Finishing my own thoughts...

    It's funny to talk to people who tell me that using XDoclet to code deployment information directly into your source code is bad, but then have those same people tell me how excited they are about JSR-175 because it will eliminate the need for deployment descriptors.

    QUESTION: Which is worse? Generating deployment descriptors from metadata or compiling deployment information directly into the class file?

    I'm not bashing JSR-175. It's a good spec and has valid uses. I just doubt it will make deployment descriptors obsolete. And it most certainly won't do away with code-generation in general.
  17. Config info in source code[ Go to top ]

    Finishing my own thoughts...

    >
    > It's funny to talk to people who tell me that using XDoclet to code deployment information directly into your source code is bad, but then have those same people tell me how excited they are about JSR-175 because it will eliminate the need for deployment descriptors.
    >
    > QUESTION: Which is worse? Generating deployment descriptors from metadata or compiling deployment information directly into the class file?
    >
    > I'm not bashing JSR-175. It's a good spec and has valid uses. I just doubt it will make deployment descriptors obsolete. And it most certainly won't do away with code-generation in general.

    The difference is that some values are deployment specific, like JNDI binding names for data sources, etc, while some metadata is really tied in with the code, like transactional context. You code your class in a certain way expecting that it will / will not be in a transaction, so if you change your transactional context, you need to change your code, and it doesn't make sense for your operations staff to go and change this in some XML file at runtime. This is what JSR175 metadata is for. Deployment descriptors will not go away, they will merely be reduced to only containing the truly DEPLOYMENT data, which one might want to change from deployment to deployment.
  18. Config info in source code[ Go to top ]

    The difference is that some values are deployment specific, like JNDI binding names for data sources, etc, while some metadata is really tied in with the code, like transactional context.


    I agree here. I never said that JSR-175 was useless and couldn't be used to replace some deployment descriptor functionality. Just not all of it.
  19. W.r.t J2E: One key point to bear in mind is that the J2EE paradigm separates teh roles of the assembler and deployer. For a good reason. Albeit this is not frequently used. Using XDoclet for vendor specific deployment info (that goes into vendor XMLs) goes against the grain of this utility.

    Having said that, in development phase, it is unlikely that different developers/QA team members will use different vendor XMLs. In this phase XDoclets may make sense. Again, any IDE can do this for you. With as much lockin to XDoclet utilities as there is to the IDE. Using XDoclet and a simple editor is in effectequivalent in all respects to using a J2EE IDE.

    Cheers,
    Ramesh
  20. Opinion: Is XDoclet really needed?[ Go to top ]

    am just curious, how many of you use XDoclet on live projects?


    On my real projects (the ones that I get a paycheck for), we're using XDoclet to generate TLD files and Hibernate mapping files. In the past we've also used it to generate struts-config.xml. On my personal (geek-time) projects, I've used it for just nearly everything it can be used for, but mostly for Hibernate, struts-config.xml, generating MockObjects, and TLD files.

    Another poster says using XDoclet for struts-config.xml is bad. I'm hard-pressed to understand his logic. It sounds like he's using struts-config.xml as a road-map for his Struts code. I question the value of that (struts-config.xml is hard to read), but to each his own. If you want to use struts-config.xml that way, there's no reason why XDoclet can't generate it for you and then you consume it however you like.

    I think the most important thing to consider when using XDoclet with Struts (or with anything else for that matter) is that you're able to keep everything regarding a Struts Action in exactly one place: In the Action's source code. This makes for more easily managed code, more DRY (don't repeat yourself) code, and helps you program closer to the problem domain.
  21. We use Xdoclet[ Go to top ]

    We use XDoclet to generate the interfaces and deployment descriptor for the three Session EJBs. It is also used to generate the Castor objects that bind to the XML schema. And we use it to generate the Hibernate configuration files for our persistent classes.
  22. We use Xdoclet[ Go to top ]

    Sorry I just realiased Xdoclet doesn't generate the castor classes - the Castor generation tool that that directly from the ant. But we still use it for the EJBs and the Hibernate configuration.

    Which brings me to another point; another poster said they would prefer to replace CMP EJB with Hibernate and this eliminates XDoclet. But I'm afraid it doesn't necessarily. Now you have two files you have to keep in synch for every class; the class itself, and the hibernate.hbm.xml for the class which contains the mapping. OK you have eliminated all the bother with remote home etc interfaces but you've still got this mapping data that has to be in synch with your classes or else you system comes crashing down in a screaming heap at runtime.

    So at this point if you don't want to hand-maintain this mapping information, and remembering that in a big system you could have hundreds or even thousands of domain classes, your choice is clear; Xdoclet to map the classes to automatically generated hibernate mapping files, or the Hibernate generation tool that takes the mapping files and generates the source code for you.

    We chose the former.
  23. XDoclet is one of many possibilities.[ Go to top ]

    I enjoyed reading the comments here. I think XDoclet has gone as far as it needs to. I really like the tip on pointing back to ant scripts. However, that doesn't buy us anything truly dynamic in nature. I know the point of configuration is that you may not anything dynamic or that you declare all dynamic possibilites however...there is sometimes a fuzzy line between declarative and dynamic in requirements and you may need to CRUD those live and transactionally. In fact, I find that sometimes, it is things like parts of the program that operate as a kind of workflow or state system that start off as configuration and later need to be more dynamic. And it isn't always obvious what part of said workflow will need to change.

    Xdoclet is good with EJB paradigm...mainly because of pesky xml hell in the way of deployment descriptors. XML is but one kind of persistent form of data. There are other persistent forms of data that lend to more dynamism and flexibility. I sometimes think database data dictionaries are a wonderful way to go. They can be turned to XML and have a slight speed increase compared to live parsing. (you can cache either). Basically, if it's softcode (literals), I like to stick it in special tables....and I can sometimes do this with a special separate database that I can cache into objects easily. I can lock the tables or unlock them and have nice fine tuned transaction control. I know this isn't the point of configuration but often, the requirements bend on what needs to be configured at one time or what needs to be allowed to change under certain conditions. If you want the most flexibility, I just stick with a simple database read & cache type of object. (you can do this easily with frameworks ie: like the one that begins with H and ends with "ate".)

    You may not want to use a database for configuration...it could be any number of store mechanisms. Perhaps the only real configuration you need is "where" the store is at and in what form (JNDI name only perhaps)...even that can be somewhat standardized/detected and automated by some kind of name already set up.

    The biggest headache is that configuration in long format is unfriendly (regardless of developer or end user). These are like globals too and should be kept to a minimum.

    going at 2 cents...take it or leave it.
  24. Opinion: Is XDoclet really needed?[ Go to top ]

    Ofcourse it will continue to be used until something better comes along. IDEs are maturing across the board and each integrating there own code generation strategies, but they all do Ant. That's the best integration point still. To integrate a new "wizard" into a GUI environment takes effort, tight coupling, and usaully some heavy framework following. XDoclet drops the barriers to entry allowing early support of new frameworks and custom templating. I wonder if there isn't some conspiracy to downplay the raft of alternative frameworks to J2EE that XDoclet supports. XDoclet offers the ability to decouple code generation from the IDE/vendor/spec version and provides a portability pivot point that container vendors don't want you toying with.

    Even so, do I use it? yes and no. For prototyping yes. Extreme even. It's great going from developer->integration->QA->PROD environments by just typing "ant." With BEA Workshop I must use EJBGEN so there no. If the app server is IBM, then WSAD with its nasty, ugly descriptors.

    Things I don't like about XDoclet

    It seems that XDoclet has just too broad a focus supporting so many frameworks, specs, and design patterns to call it manageable or integrateable into IDEs. JBoss does well. The 2.0 version decouples vendor/spec/patterns as plugins so low quality/unsupported modules don't drag core system development down. But where is it. Seems that this obsession of inversion of control, multi-controller, multi-template support, and multi-licensing is creating more effort than it's saving. When it's out and solid I'll be happy. Just tell me where to download it.

    Re: JSR-175. Seems like loosely typed metadata, although lacking compile time validation, seems more portable. I'm sure XDoclet will offer both JSR-175 and "classic" javadoc.

    Descriptor v. inline metadata: Surprised the aspect police haven't jumped on this one. Acedemics can have thier well-formed and valid descriptors. I'll take XDoclet's descriptor less verbose tags and descriptor defaults.

    The XDoclet team has done a great job putting up with low quality module bug fixes and feature requests. It has enhanced the viability of JBoss, Struts, and Hiberate to name few. Don't kill their buzz.
  25. XDoclet vs Websphere[ Go to top ]

    This might sound like a stupid question (I'm fresh to EJB), but we are using Websphere and as far as I can see, Websphere is doing all the EJB construction and deployment for me.
    Is there a need for XDoclet if you have Websphere?
  26. XDoclet vs Websphere[ Go to top ]

    This might sound like a stupid question (I'm fresh to EJB), but we are using Websphere and as far as I can see, Websphere is doing all the EJB construction and deployment for me.
    Is there a need for XDoclet if you have Websphere?

    You don't need XDoclet to generate EJBs when you are using WSAD.
  27. XDoclet and Struts[ Go to top ]

    XDoclet and Struts - Do they seem like a pair from heaven .. Think again

    Using XDoclet for autogenerating struts-config.xml is not a good idea at all!! Before you raise you eyebrows (or accusing fingers), give me a chance to justify myself.

    In the XDoclet approach, there is no struts-config.xml at all! The file is generated at build time. All the requisite information linked to the <form-bean> and <action> are specified in the Action and Form classes using special XDoclet tags as follows:


    * @struts.action name="custForm" path="/editCustomer" scope="request"
    * validate="false" parameter="action" input="mainpage"
    *
    * @struts.action-forward name="showCustForm" path="/ShowCustomerForm.jsp"


    will generate

    <action path="/editCustomer"
        type="mybank.app1.ShowCustomerAction"
        name="userForm" scope="request" input="mainpage"
        unknown="false" validate="false">

            <forward name="showCustForm" path="/ShowCustomerForm.jsp"
                redirect="false"/>
    </action>


    And now, on to my justification: XDoclet is project on sourceforge that started off with auto-generating home interface, remote interface, ejb-jar.xml from special tags in the EJB implementation class. It was a good idea with EJBs since the EJB implementation class would drive everything else - home, remote and the ejb-jar.xml.

    However, with struts-config.xml, none of the individual classes drive the flow in entirety. Everything works always in relation to another. You always want to track what is going on, how various pieces interact together and how the flow works. You always want to see which action takes you where and get the whole big picture as you develop. Hence the struts-config.xml serves much like whiteboarding - visualizing whats going on in its entirety. Providing this information via piecemeal approach in different files using XDoclet tags defeats the purpose.

    It really does not matter when a small example application is assembled. It looks great in fact. I for once had tried to apply XDoclet for autogenerating struts-config.xml in a large J2EE project - 500 jsps, 50 Entity EJBs. You can imagine developers sweating out, trying to put the pieces of the puzzle together to figure out the page flow going throuhg the Action classes. And then I decided - no more Xdoclet with Struts. I continue to use XDoclet with EJBs happily, but not with Struts.

    PS: Reminds me of something - When microwave was first invented, there were cookbooks telling you how to cook frozen dinner to a thanksgiving turkey dinner - all in a microwave. And then finally things settled and people realized and went back to cooking turkey in the best place - conventional oven.

    PS: Reproduced from my blog on Jan 25 - http://jroller.com/page/javajoe

    Cheers,
    Srikanth Shenoy
  28. XDoclet and Struts[ Go to top ]

    And then finally things settled and people realized and

    > went back to cooking turkey in the best place - conventional oven.

    Actually, deep frying is the best way to cook
    turkey :-)
  29. XDoclet and Struts is a good thing[ Go to top ]

    Using XDoclet for autogenerating struts-config.xml is not a good idea at all!! Before you raise you eyebrows (or accusing fingers), give me a chance to justify myself.

    > ...
    > In the XDoclet approach, there is no struts-config.xml at all! The file is generated at build time. All the requisite information linked to the <form-bean> and <action> are specified in the Action and Form classes using special XDoclet tags as follows:

    Absolutely incorrect. While it is true that you define your struts configuration in the Action and ActionForm classes instead of in the struts-config.xml, the WHOLE POINT of XDoclet is that it generates a struts-config.xml.

    In fact, by using XDoclet to generate your struts-config.xml, you actually get the best of both worlds.

    In the microcosm of a single Action or ActionForm, you can see exactly the relevant struts configuration settings together with the source code (and they are versioned with the source!).

    In the macrocosm of an application, you can see all of the settings for all of the actions by looking at the generated struts-config.xml. If you want some sort of reporting/sorting mechasism, then an XML reporting tool or XPath tool is your friend.

    But beyond struts-config.xml, using the XDoclet validation tags is even MORE useful. Since this allows you to define your validation criteria in the code right on the setter method of the ActionForm.

    > It really does not matter when a small example application is assembled. It looks great in fact. I for once had tried to apply XDoclet for autogenerating struts-config.xml in a large J2EE project - 500 jsps, 50 Entity EJBs. You can imagine developers sweating out, trying to put the pieces of the puzzle together to figure out the page flow going throuhg the Action classes. And then I decided - no more Xdoclet with Struts. I continue to use XDoclet with EJBs happily, but not with Struts.

    The reality is that no matter what you do, an application with 500 jsps, actions, etc, registered in the struts-config.xml is going to be difficult to understand just by reading the struts-config.xml. For that size application, you NEED to have some higher level documentation (and ideally you'd also want to break the struts configuration into modules...and while it is true that you can't rename the generated config file from XDoclet struts, you can setup the ant task to run from different base package names and rename the output files after the ant task).

    P.S. The one other enormous benefit of using XDoclet with struts is that you no longer have a dozen developers all trying to make changes to the same darn configuration file(s) and constantly having to merge changes!!!
  30. XDoclet and Struts is a good thing[ Go to top ]

    and while it is true that you can't rename the generated config file from XDoclet struts


    I beg to differ. A quick (30 seconds) inspection of the StrutsConfigXmlSubTask code shows that the (default) generated filename gets set in the constructor. This means you should be able to include a
    destinationfile="some-other-struts-config.xml"
    attribute on the subtask to override the output file location.

    For some subtasks this isn't the case as they set the value in the execute method, but this one looks okay. And if that's not the case, you know where our JIRA is ;-)
  31. XDoclet and Struts[ Go to top ]

    You do know that you can generate the struts-config.xml file and read it, don't you?
  32. XDoclet and Struts[ Go to top ]

    Using XDoclet for autogenerating struts-config.xml is not a good idea at all!!


    I agree with Srikanth. Xdoclet is great for EJBs but not suitable for frameworks like Struts at all. The whole point of Model 2 is to explicitly separate routing logic from both business logic and presentation logic. What's the point in putting it right back in through meta-tags?

    Someone here posted that one could always read the generated struts-config.xml file. He misses the point. Routing logic must be *specified* in one place, in a way independent of the business and presentation components. It's the highest-level document in the design, if you think of code as self-documenting. When you look at the struts-config.xml, you can see which form calls which Action class, and you can see all the presentation components (.jsp or .do) that an Action can forward to, based on its return status. That's the high-level view of the application's screen flow.

    *Then* you drill down into the details of any one piece of business logic or presentation logic.

    I guess webdoclet must have initially seemed like a great idea, but I only used it once before I realised it's not.

    Regards,
    Ganesh Prasad
  33. It's premature to eliminate XDoclet from the tool chain, but conceivable within the near future. Eventually a container will check for attributes directly in the component classes. So components won't need external descriptors. Struts wouldn't need struts-config.xml; JSP wouldn't need a TLD; etc. With JSR-175 it makes more sense to replace XDoclet with attribute aware containers. I think J3EE is had by rewriting the J2EE specifications to replace external descriptors with attributes. The problem is that external descriptors often contain heirarchical and repeating XML elements. Could JSR-175 handle that?
  34. Valuable tool, but..[ Go to top ]

    The problem with the XDoclet lies in the fact that the plugins "just generate code". They are not supposed to check whether the generated code is valid or not. For example with Hibernate this means that the Hibernate tool will catch by mistakes and complain about them. The problem is, that Hibernatejust knows about the generated XML. It doesn't know where it came from, i.e. where the real error is. It is then my responsibility to figure out which xdoclet comments produced the problematic XML.

    In long term, I think it would make more sense if there was a good way for the Hibernate tools to directly process the metadata stored in the Java files. Maybe the whole thing should be handled by the compiler and not by a separate pre-procesor.
  35. Valuable tool, but..[ Go to top ]

    The problem with the XDoclet lies in the fact that the plugins "just generate code". They are not supposed to check whether the generated code is valid or not.

    That's just a another annoying symptom of code generation. The root of the problem is code generation. Ideally, a runtime should be data driven. Metadata enable this; XDoclet distracts from it.


    In long term, I think it would make more sense if there was a good way for the Hibernate tools to directly process the metadata stored in the Java files.

    Exactly as I suggested here a moment ago. XDoclet likely goes away when tool vendors embrace metadata. Really, metadata needs to be in the many J2EE related specifications. I doubt there's a J2EE API that couldn't be satisfied with the right mix of metadata bearing POJOs.
  36. .hbm.xml[ Go to top ]

    In long term, I think it would make more sense if there was a good way for the Hibernate tools to directly process the metadata stored in the Java files. Maybe the whole thing should be handled by the compiler and not by a separate pre-procesor.<

    We would get this with JSR175, I guess.
  37. Love & Hate[ Go to top ]

    I've looked at xdoclet for struts & J2EE. For struts, I'd never use it because I can do it faster by hand using Intellij IDEA or Camino. For J2EE, it's VERY valuable. With struts there's 1 config file (roughly). With J2EE on Jboss, there are 2-4 interfaces, ejb.xml, jboss.xml, jbosscmp-jdbc.xml at the minimum. Throw in come value objects and whatnot, and xdoclet becomes a persistance generation framework.

    However I hate the fact I need to use it. If SUN had done a good job, not better - GOOD, then I wouldn't need it. Again it's just more cannon fodder for and from my .NET friends.

    xdoclet definately fills a need for me.
  38. Love & Hate[ Go to top ]

    I've looked at xdoclet for struts & J2EE. For struts, I'd never use it because I can do it faster by hand using Intellij IDEA or Camino. For J2EE, it's VERY valuable. With struts there's 1 config file (roughly). With J2EE on Jboss, there are 2-4 interfaces, ejb.xml, jboss.xml, jbosscmp-jdbc.xml at the minimum. Throw in come value objects and whatnot, and xdoclet becomes a persistance generation framework.


    I won't argue that it might be faster/easier to do the same thing that XDoclet does in an IDE like Intellij. However, I would argue that relying on a feature in a single IDE is a slippery slope. Using XDoclet via Ant (or Maven) builds may not be as easy/intuitive to do as it is in your favorite IDE, but it will certainly work anywhere and on anyone's system even if they don't have a copy of Intellij.

    I say use a hybrid solution. Use Intellij for your POCs and maybe developement. But for production building and deploying, it's hard to beat the portability of XDoclet and Ant (or Maven).

    > However I hate the fact I need to use it. If SUN had done a good job, not better - GOOD, then I wouldn't need it. Again it's just more cannon fodder for and from my .NET friends.

    I really don't see this as a huge problem. I think nice to have an abstracted pre-compiler like XDoclet that isn't tied to JDK releases. If you want a nice new wiz bang feature, you can extend XDoclet to do it. Versus waiting for that new feature in a future JDK release. I don't know about you, but I'd prefer the former.

    As far as cannon fodder is concerned, no matter what you say, you'll never convince the "enemy" that your side of the fence does indeed have the greener grass, so I wouldn't lose any sleep over it. :)
  39. Couldn't agree more[ Go to top ]

    I think there is too little talk right now about how to learn from .NET. In .NET Microsoft has imporved the java language and learned from its mistakes. I'm not a .NET expert, so I am not sure about this, but as far as I can tell from what I have read, there is no real persistance framework like EJB. I realize there is ADO.NET, but it doesn't behave the same way. So it may not be as far along on the architecture end, but Microsoft learned from the deployment file hell that java suffers from and fixed the problem in the LANGUAGE. They created metadata and attributes like [Web Method] that greatly simplify the development process.
    Now I realize that the goal of deployment descriptors is that you don't have to recompile code to reuse it, but with XDoclet you don't have to either. XDoclet provides a way to keep all of your information in one place. you can generate and regenerate files like struts-config or ejb-jar as many times as you like while keeping all the information central to the source file. The place I want to go if I want to learn what an app is doing.
    Sun needs a system that takes away its biggest liability (in my opinion), deployment file hell. Solve this problem and the ONLY advantage .NET has is speed. (and im really not sure about the validity of this argument). I don't know if JSR 175 can do this or not, I am not familiar enough with it. But something needs to move the tons of information in these descriptors to where it is not cumbersome to read and understand.
    As an example, if I want to know the method to call in an entity bean (In jboss) to set a column in a database I need to look at the database, find the corresponding field in the jboss-cmp check the ejb-jar file and then read the actual bean to see if it is available remotely. Thats 4 different places I need to look. Does anyone else not find this insane.
    With XDoclet set up in my source I look through maybe a couple soure files until i find the bean corresponding to my table, which with the right ide could be available in the metadata displayed in a source file tree, and I look for the method that persists to the field I want. Easy as pie.
    Wake up Sun!!!
  40. No Vendor Plugins for XDoclet 2.0[ Go to top ]

    XDoclet is a great product and saves me a lot of time on my developmnent. I use XDoclet 1.2b3 to generate my EJB interfaces and descriptors for JBoss and WLS. However, I don't see any adoption of the new Vendor development of propriatery plugins for app servers. So far it looks like one person is slowly chugging away on the XDoclet 2.0 project (or am I missing something). 2.0 has some nice internal design improvements, but at the pace things are changing Vendor adoption seems to be a big issue, especially since new versions of app servers are out like WLS 8 and J2EE 1.4.

    What will become of XDoclet?
  41. Honestly, I recommend you plan to stay with 1.2 for a while. It'll be quite a while before I think you'll see a usable XDoclet 2 with the level of module support 1.2 has. I can't comment on the state of the weblogic modules in 1.2, but I think you'll have a better chance getting 1.2 support for updates in the short to midterm.
  42. Michael:
     2.0 has some nice internal design improvements, but at the pace things are changing Vendor adoption seems to be a big issue, especially since new versions of app servers are out like WLS 8 and J2EE 1.4.

    This is probably due to the fact that EJBGen is the official tool for WLS. It supports all the newest descriptors introduced in WLS 8.1 (and even some new ones not yet released, but shhhh).

    The latest stable version is 2.17 but I post regular betas on the mailing-list, which has been pretty busy for almost three years now.

    --
    Cedric
  43. Is it the right tool? It depends[ Go to top ]

    Is it the right tool? It depends.

     I'ts a very useful tool if you are using CMP entity beans. It generates interfaces, primary keys, value objects and deployment descriptors. This is far better than the error prone way of hand coding these files.

    But a bigger question may be asked: Why do we need all these files? Wouldn't an object/relational mapper like Hibernate be a better solution in a lot of cases. In my humble opinion, YES.
  44. Opinion: Is XDoclet really needed?[ Go to top ]

    I think that such tools like XDoclet are existing because of "code smell". You need so many classes and files when using Entity Beans. XDoclet helps, but its existing just because of this code smell. The code smell should be removed instead of spraying perfume on it.

    Is it possible that the meta descriptions can replace XDoclet completely?
  45. Opinion: Is XDoclet really needed?[ Go to top ]

    There seems to be a growing trend towards labelling anything which works well and is easy to understand as a "code smell" just because it happens not to be particularly OO.

    Code generation has been around since almost the beginning of programming. It's still with us today for the simple reason that some things are better done at compile/build time than they are at runtime.

    I'm not afraid to use XDoclet, or a perl script, or a shell script if it does the job in a manner that satisfies me. Quite often a spot of code generation can replace really complex, buggy, and slow/memory hog runtime constructs.

    If it helps you, think of it this way - javac is nothing more than a code generator that creates .class files full of bytecode :-)

        -Mike
  46. .hbm.xml[ Go to top ]

    XDoclet is great for generating Hibernate mapping documents but I think that in the long term this is better handled by JSR175 annotations and that is the direction we will move in (of course, we will need to keep supporting XDoclet for a long time).

    But JSR175 is not really appropriate to the job of *code* generation, which is what XDoclet was really designer for.
  47. .hbm.xml[ Go to top ]

    But JSR175 is not really appropriate to the job of *code* generation, which is what XDoclet was really designer for.


    *EXACTLY* my point. Where JSR 175 makes sense it should be applied. In those areas, XDoclet's role will diminish. But there's always going to be something that needs to be generated and that's where XDoclet comes in.
  48. And another thing...[ Go to top ]

    Not everybody has the luxury of upgrading to the latest and greatest Java or application server on our projects. There are many reasons why this is the case, but I assure you that the day Tiger is released will not spell the end of deployment descriptors. Lots of projects won't even be able to use Tiger for a year (or more).

    So, XDoclet will still be there for those folks, ready to generate deployment descriptors (and other stuff that JSR-175 doesn't make sense with).
  49. .hbm.xml[ Go to top ]

    But JSR175 is not really appropriate to the job of *code* generation, which is what XDoclet was really designer for.

    I disagree. JSR175 doesn't limit how or when the metadata is used. Every XDoclet tag that triggers the generation of extra classes could just as easily be metadata that directs a container to dynamicly synthesize those extra classes. Hence metadata obviates XDoclet.
  50. .hbm.xml[ Go to top ]

    directs a container to dynamicly synthesize those extra classes.Hence metadata obviates XDoclet.

    Well, very often I prefer to _see_ generated code rather than try to _guess_ what goes wrong at runtime...
  51. .hbm.xml[ Go to top ]

    Well, very often I prefer to _see_ generated code rather than try to _guess_ what goes wrong at runtime...

    Can you please give an example. I can't remember the last time I had to review generated source. So why? To me the whole point of abstraction is to *shrink* the codebase. Code generation doesn't help that. As a developer I appreciate having less code to consider. Take for example, object serialization. I don't want to see the serialization marshalling source logic. I never review the guts of generated JAXB source. Nor stub source for RMI or WSDL or IDL. Is it XDoclet generated source you've had to manually review?
  52. interpreters vs. compilers[ Go to top ]

    I think most people really miss the point here. The basic argument is kind of the argument between compilers and interpreters, there are advantages to both approaches! Generated code is simply an artefact, just like a .class or an .exe, except that it simply requires a bit more processing before it is directly machine usable. The code-base (that is the original, human-written/maintained stuff) HAS SHRUNK, and the nitty-gritty derivable boring bits are generated for you. It doesn't matter whether these are available in source form or not as long as they work, it is merely a design decision as to whether these things were statically generated and/or bound or run-time generated and/or bound. It is like the AOP discussions; many AOPers decry AspectJ's static compiler, and then go off creating all these fancy runtime interception schemes, find out the performance aint so hot and then use CGLIB to dynamically create the class files. Now, apart from the fact that the generated .class files don't exist in the jar, WTF is the difference?

    The only argument left that is vaguely interesting (and that not very) is about whether to check these artefacts in to your CVS. The answer is NO NEVER, except when they are really static and not subject to much change, and also very expensive to produce.
  53. interpreters vs. compilers[ Go to top ]

    I think most people really miss the point here. The basic argument is kind of the argument between compilers and interpreters, there are advantages to both approaches! Generated code is simply an artefact, just like a .class or an .exe, except that it simply requires a bit more processing before it is directly machine usable. The code-base (that is the original, human-written/maintained stuff) HAS SHRUNK, and the nitty-gritty derivable boring bits are generated for you. It doesn't matter whether these are available in source form or not as long as they work, it is merely a design decision as to whether these things were statically generated and/or bound or run-time generated and/or bound. It is like the AOP discussions; many AOPers decry AspectJ's static compiler, and then go off creating all these fancy runtime interception schemes, find out the performance aint so hot and then use CGLIB to dynamically create the class files. Now, apart from the fact that the generated .class files don't exist in the jar, WTF is the difference?

    >

    I agree with you, there is nothing bad in source code generation in general.
    Sometimes it can be better to generate source code at build time. I think
    parser generators like javacc is a good example. But I do not think it is a good
    idea to generate source code for garbage like proxies or jsp servlets.
    Difference is very trivial, it is just faster to test script and dynamic code generation helps to remove build time configuration, tools and some useless files.



    > The only argument left that is vaguely interesting (and that not very) is about whether to check these artefacts in to your CVS. The answer is NO NEVER, except when they are really static and not subject to much change, and also very expensive to produce.
  54. interpreters vs. compilers[ Go to top ]

    As more I think as more I am sure javac and code generators are not right tools to develop trivial web applications(www.theserverside.com can be a good example for this kind of application).
    It must be better to use some messaging, RPC, servlet container and RDMS friendly scripting for home pages or DB frontends.
    BTW Why PHP is so popular ?
  55. When do you need those classes?[ Go to top ]

    How to you expect to write code against an EJB remote interface that only gets generated at runtime?

    You can't get away from build-time code generation.

    You could however use metadata to drive the code generator, which will probably be XDoclet. The only thing that you could get rid of would be the javadoc syntax.
  56. When do you need those classes?[ Go to top ]

    How to you expect to write code against an EJB remote interface that only gets generated at runtime?

    >

    It is not a very good ide to generate EJB remote interface at runtime, it can be used by "dynamic" clients only (scripting). It is more meaningfull to generate implementation for EJB remote interface at runtime, it is possible to code EJB without remote interfaces, this way works without problems in my tests.

    > You can't get away from build-time code generation.
    >
    > You could however use metadata to drive the code generator, which will probably be XDoclet. The only thing that you could get rid of would be the javadoc syntax.
  57. When do you need those classes?[ Go to top ]

    How to you expect to write code against an EJB remote interface that only gets generated at runtime?



    Clients import only the generated Jar from the EJB project. They use the rmeote interface found there.
  58. I've got a case where alas XDoclet doesn't help.

    I still have to resort to creating external descriptor files for Hibernate.

    I have a broad category of situations where DTOs are being defined in XML schema and DTOs arrive over JMS as XML documents.

    Using JAXB code generated classes, the XML documents are being nicely unmarshaled into Java object graphs. The object graph is processed and persisted using Hibernate.

    The classes are code generated, though, so there's no oppurtunity to use XDoclet to generate the mapping files.

    Nor would metatags, ala, JDK 1.5 be an option as it would still require that the Java class source code be created by a developer instead of a tool.

    Guess the only hope here is if the JAXB tool could eventually be made to recognize some sort of XDoclet-like directives that are embedded in the .xsd XML schema files.

    I think I'm going to be stuck with hand creating these Hibernate mapping files for a long time to come.
  59. Nor would metatags, ala, JDK 1.5 be an option as it would still require that the Java class source code be created by a developer instead of a tool.

    I think it a myth that JSR-175 metadata must be available in the source code and that it must be added to the class by hand.
  60. I'm surprised no one has commented yet that JSR 175 metadata is intrusive and just plain ugly. At least with doclet based metadata, it is non-intrusive in the sense that it does not alter the syntax of the programming language proper.

    That being said, maybe after a long transition period, the JSR 175 enhancement to the syntax will become better accepted. It may even become less offensive to those of us, who are already accustomed to reading code that looks a certain way, which we deem asthetically pleasing.

    It makes me wonder how JSR 175 passed the public review without a revolt from the user community. Perhaps the disruptive syntax was so offensive that those who opposed it stabbed out their own eyes, before being able to write their protests.
  61. Ben:
    I'm surprised no one has commented yet that JSR 175 metadata is intrusive and just plain ugly.

    Well, if nobody commented, maybe it means that hardly anyone finds it intrusive and ugly?

    Actually, to be fair, it is intrusive, that's a fact. Ugly... well, that's a personal opinion, which I don't believe is shared by many people based on the feedback we received.

    Of course, this feedback contained criticism, sometimes justified, other times not, but I would certainly remember if an overwhelming majority of it had the term "ugly" in it.

    Besides, where were you when we were in public review? :-)

    At least with doclet based metadata, it is non-intrusive in the sense that it does not alter the syntax of the programming language proper.

    True, but that's a double edge sword, and the community has decided it preferred the other side of the blade.

    That being said, maybe after a long transition period, the JSR 175 enhancement to the syntax will become better accepted. It may even become less offensive to those of us, who are already accustomed to reading code that looks a certain way, which we deem asthetically pleasing.

    I think that's pretty much guaranteed. I bet that in two-three years from now, a big majority of the source files we will be manipulating on a daily basis will contain JSR 175 annotations. Mark my words.

    --
    Cedric
  62. Actually, to be fair, it [JSR175] is intrusive, that's a fact.

    Maybe not. A bytecode enhancer could easily add metadata to POJOs that lacked metadata. That's very amenable to aspect weaving.
  63. XDcolet VS Intellij[ Go to top ]

    Hi there,

    I'm pretty interested in this subject since my company has just started to develop a J2EE application. We'r using IntelliJ4 and it can generate most of the interfaces and the development descriptors for us. Is there any need to learn XDoclet if most of the tasks are done by your IDE?
  64. <quote>
    Is there any need to learn XDoclet if most of the tasks are done by your IDE?
    </quote>

    Yes for sure we will always need:
    - Ant
    - XDoclet and later JSR 175 metadata
    - MDA tool like AndroMDA

    If you have to develop a big system with many components on it, you surely need some automatic generation, test, deploy, etc. These tasks cannot be done manually by using IDE because you'll do them in scheduled time, therefore: Ant, XDoclet/metadata and MDA tool like AndroMDA are needed for sure!

    Check EJOSA for development process purely based on Ant and other Open Source tools (Model Driven and Sourcecode Centric Development):
    http://ejosa.sourceforge.net
    http://sourceforge.net/projects/ejosa

    The version ejosa_revo in CVS (http://cvs.sourceforge.net/viewcvs.py/ejosa/ejosa-revo/) adds support for AndroMDA, so the development process folows this rule:

    For each component:
    1. build the model
    2. build the specification
    3. build the business layer
    4. build the data layer
    5. build the automated unit test
    6. build the presentation layer
    7. build the stress/load test (to be added)

    Lofi.
    http://www.openuss.org
  65. Re: XDoclet VS IntelliJ[ Go to top ]

    For me one of the best features of XDoclet is being able to edit the templates and write new ones. Most IDEs force you to generate interfaces and classes in only one way and if it doesn't meet your projects' requirements bad luck.

    As mentioned in other comments, XDoclet works very well within scope of Ant Scripts, and we find that in IntelliJ 3.0.5 the Ant integration allows us XDoclet ant IntelliJ to co-exist very happily.

    Bob Boothby.
  66. XDoclet usage[ Go to top ]

    Hi,

    I'm using XDoclet in all my J2EE projects. It helps me to do the projects in less time.
    Most of the time I'm using XDOCLET for generating CMP code.

    I like this tool and hope to have long live.
    Also, using XDOCLET is making the project to not relay on a IDE.

    Regards,
    Gabi
  67. XDoclet usage[ Go to top ]

    Hi,

    >
    > I'm using XDoclet in all my J2EE projects. It helps me to do the projects in less time.
    > Most of the time I'm using XDOCLET for generating CMP code.
    >
    > I like this tool and hope to have long live.
    > Also, using XDOCLET is making the project to not relay on a IDE.
    >
    > Regards,
    > Gabi
    I don't see XDoclet as a very helpful tool for CMP deployment descriptors generation. In my view there is a lack of universal DB mapping tags (EJB Field To Column Mapping, Relation to Tables mapping etc.) which would automatically produce container specific descriptors. In other words, if I have to describe a CMP to DB mapping I have to write these mappings for any target container (JBoss, Weblogic...) individually, for example try to describe a many-to-many relationship over 3 tables.
    In our team we use ...JBuilder as a CMP code & descriptors generation tool. May be this looks stupid but I don't see another way to describe a model once and port it to any container in future just changing a target server in preferences ;)
  68. XDoclet usage[ Go to top ]

    I don't see XDoclet as a very helpful tool for CMP deployment descriptors generation. In my view there is a lack of universal DB mapping tags (EJB Field To Column Mapping, Relation to Tables mapping etc.) which would automatically produce container specific descriptors.

    Agreed. XDoclet is even worse when the component's source code is unavailable. Remember that J2EE assumes components are released as binary. This is where JSR175 metadata shines. It allows (perhaps automatic) conversion of metadata *after* compilation. This lets JSR175 be used in a variety of places that XDoclet can't: class loaders, jar analyzers, packaging tools, etc. JSR175 is a significant step forward.
  69. Re: Is XDoclet really needed?[ Go to top ]

    Really great thread and responses! I enjoyed reading this...

    Well, it depends on what context exactly you're going to have code/config generation. Usually I'm using XDoclet (or any other such tools) at the following two cases:
    1. When I should go for a routine repeatable *code*, like:
       - EJB stuffs (remote and home interfaces) or
       - Exposing my server side components as web services (SOAP or XML-RPC)...
         In this case for example, I can use XDoclet to generate both my server and client side SOAP supportive classes and can eb a great help.

    2. When I can have multiple configuration files per my defined information.
       For example on the two above examples, I can generate both my EJB and SOAP configuration files (XMLs actually) all in one shot by defining a single block of information as javadoc styles inside the code.


    But in my opinion, the cases Struts or Hibernate where we have *one configuration* (either a whole config file or a block of config) *per class* mappings, really no gain for me to use XDoclet or so.
    Actually I'm distributing my whole configuration accross the javadocs of each method of class... That's all! XDoclet can't save me much. It doesn't generate anything extra for me but just transforming the javadocs into XML. Please note that you should have some tags for config X and another set of tags for config type Y. You're *not* having *only one* set of tags then getting generated many configurations just using them and this is the negative point I'm seeing!
    What's the point of separating XML configurations from the code? With these kinds of generations, we're actually returning the configs back to the code! Where's the separation then? There should be a big plus for me to go that approach since I've already lost the code-config separation.

    As a separate note, I prefer to have/see these config-per-class mapping files (as Hibernate or Struts) all in one shot. It gives me better overview...

    Well, you may question me about the consistency. Having a change on the code will effect on the configuration files too and they need to be kept in synch.
    Yes! We have this need too and one of the main reasons why many of us have gone for tools like XDoclet... But a question: How much do you modify such code? How much do you change your entities (names, signatures and so on) to effect the Hibernate XML files? Are they that much to worth adding a new layer of complexity (config genaration)? At least it's not the case for me. I feel way comfortable to directly open my *.hbm.xml file and correct the data there rather than adding a whole generation tool for this to keep in consistent.
    On the other hand, we have the units tests! Guys.. have you forgotten this? They can easily catch the flaws if we've somehow missed to update the configs.
    Also, developing environments like IDEA provide me many great facilities for refactoring (even among the text and XML config files). You change an attribute name within an entity, IDEA can search for you inside the Hibernate XML files to update them. I'm not counting this a big plus in this explicit discussion though but just thought it worths to mention.

    All just my 0.02$...

    Armond
  70. Re: Is XDoclet really needed?[ Go to top ]

    But in my opinion, the cases Struts or Hibernate where we have *one configuration* (either a whole config file or a block of config) *per class* mappings, really no gain for me to use XDoclet or so.


    Not really sure I understand your problem with this. The alternative is to write your source files and mapping files seperately. How is this any better? It certainly is not faster (development-wise). If your problem is not having all of your mappings in one file, this can easily be accomplished with some XML post-processing of the per-class mapping files.

    If you do not generate the mapping files, any time you add/change a persistant property of a class, you have to go edit the mapping file, too. If you keep all of your mappings in one file (yech!), you have to keep finding the specific class in this mapping file. This single mapping file will get quite large *and* you are likely to have merge conflicts by placing so many points of change in one file.

    Let me give an example...which is easier to maintain:

    ======== THIS ==========

    /**
     * @hibernate.class
     */
    public class User implements Serializable {
        
        private String userId;
        private String name;
            
        /**
         * @hibernate.id
         * column="user_id"
         * generator-class="assigned"
         */
        public String getUserId() {
            return userId;
        }

        public void setUserId(String userId) {
            this.userId = userId;
        }

        /**
         * @hibernate.property
         */
        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }

    ======== OR THIS ==========

    public class User implements Serializable {
        

        private String userId;
        private String name;
            
        public String getUserId() {
            return userId;
        }

        public void setUserId(String userName) {
            this.userId = userName;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }

    <hibernate-mapping>

        <class name="User">

            <id name="userId" column="user_id">
                <generator class="assigned"/>
            </id>

            <property name="name"/>

        </class>

    </hibernate-mapping>

    OK. Now rename the class. Now repackage the class. Now change a column name. Now add five properties. Each time you do this, you have to edit twice as many files as you need to.

    Ryan