Discussions

News: xPetstore 3.0 Released: Features EJB and non-EJB implementations

  1. xPetstore 3.0 has been released. xPetstore is a re-implementation of the Sun Microsystem PetStore based on xDoclet.

    This demo application demonstrates how to use open source frameworks to build WODRA (Write Once, Deploy and Run Anywhere) J2EE applications.

    xPetstore has been implemented using 2 differents approaches:
        - A pure EJB solution based on JSP, Struts, Sitemesh, EJB 2.0 and CMP 2.0
        - A Servlet solution based on Velocity, WebWork, Sitemesh, POJO and Hibernate.

    Both solutions have been deployed and tested on the following platforms:
        - Operating System:
              o Linux
              o Windows
        - Application Servers:
              o JBoss 3.x
              o WebLogic 7.x
        - Databases:
              o Hypersonic SQL
              o PostgreSQL
              o SapDB
              o MySQL
              o Oracle
              o MS SQL Server

    Checkout xPetstore at: http://xpetstore.sourceforge.net

    xPetstore is also a great sample to application to learn from. With xPetstore, you will learn how to use xDoclet to:

        - Generate EJB 2.0 files:
              o Home and Business interfaces (local and remotes) ejb-jar.xml
              o Application server specific deployment descriptors
              o Value Objects classes
        - Use J2EE 1.3 features like CMP 2.0 and CMR
        - Generate web deployment descriptors for:
              o Servlets
              o Web Filters
              o JSP Taglibs
        - Generate Struts deployment descriptors
        - Generate Webwork deployment descriptor
        - Use other web template technology like Velocity
        - Use Hibernate as persistence layer
        - Use xDoclet merge points to add extra stuff
        - Test J2EE application using JUnitEE framework

    Threaded Messages (26)

  2. How is a web application based on Velocity, Struts, SiteMesh, WebWorks,etc etc etc considered 'lightweight'?

    Sounds like a crap-load of integration and dependencies. I dont consider that light weight. Heck, has anyone ever counted just the number of configuration files alone by combining XDoclet, Velocity, Struts, SiteMesh and Webwork together ontop of Tomcat? Wonder if it overflows an int.
  3. Wonder if it overflows an int.


    In what language, and on what platform?
  4. How is a web application based on Velocity, Struts, SiteMesh, WebWorks,etc etc etc considered 'lightweight'?


    Sorry but you may not got it.
    There are 2 implementation of xPetstore:
     #1. One with JSP, Struts, Sitemesh, EJB+CMP2.0
     #2. One with Velocity, Webwork and Hibernate.

    Why #2 is considered as lightweighted ?
    - Because with Velocity, you don't need all the JSP taglibs (with their TLD)
    - Because with Webwork, you only have Action classes, while in Struts you have Action and Form classes.
    - Because #2 is uses 33 .java files / 970 line of code, while #1 uses 165 files / 3500 LOC.


    > Sounds like a crap-load of integration and dependencies. I dont consider that
    > light weight. Heck, has anyone ever counted just the number of configuration
    > files alone by combining XDoclet, Velocity, Struts, SiteMesh and Webwork
    > together ontop of Tomcat

    All the configuration files are generated by xDoclet. You just have to define the javadoc tags in the .java file. If that too much for you...
    If writing a build.xml ant file is too much for you....
    If dropping a 10 or 20 .jar files downloaded on the net is too much for you...

    So what do you consider as lightweight?
  5. All the configuration files are generated by xDoclet.


    I have yet to see a good debate on generated code, so let me try to keep this one going! :-)

    I personally believe that if code or configuration is so abundant that it requires generation to be productive, then the underlying framework is lacking. I've never come accross a case in my own work where I needed to generate code or configuration. Instead I've always found a way to abstract, encapsulate and/or layer software such that code is not *so* redundant that generation is required.

    Note: I am not ripping xdoclet or xpetstore here. I think both are very valuable. My purpose is to discuss why something like xdoclet or a fancy IDE is needed at all.

    What do you think?

    PS: Thanks to Herve for continuing with this great example.

    Cheers,

    Clinton Begin
    http://www.ibatis.com
    Home of JPetStore
  6. Code Generation[ Go to top ]

    It seems that a lot of code generation comes about from wanting to represent higher level ideas, and having the low level items generated for you.

    This could be a drag and drop GUI tool where the developers view is the app itself, and the GUI code is taken care of.

    It could also be having a nicer language to express common items, and having the laborious code generated for you (OR -> JDBC calls).

    It could also be having a higher level language to express ideas. Isn't javac a code generator? Many people don't want to write java bytecode, or assembly, we want to write to higher views.

    I think there is a place for code generators. However, sometimes people get carried away with them.... as with all things. If you look for the simplest solution, and go for that, you will normally do OK. You see too many people trying to find a problem to the solution that they have thought of (from tools, to patterns, ...)
  7. Clinton,

    I think one case where XDoclet shines is EJB development. If you are developing EJBs (whether this is a good thing is a *whole* other debate), the spec forces you to create multiple files. XDoclet helps you manage this in one place. I see this as a great use of code generation.

    Many "Model 2" servlet frameworks use the Dispatcher + Command pattern. In this case, which command (or "action") is called is determined by a URL mapping - the command is aliased to a particular URL pattern. This has to be mapped somewhere. So, either you maintain a seperate mapping file, or you denote the alias in the command class and generate the mapping file.

    These are dozens of cases like this where you need code + config (tag libs, servlets, JMX, etc). Often, coupling these two files with code generation is not bad, because in practice they *are* tightly coupled. XDoclet manages this for you and saves time and errors from jumping back and forth between mutliple files that redundantly define your application.

    If you have an alternative to reducing these headaches, I am all ears. And that is not a sarcastic jab at you - I honestly would like to hear about other approaches.

    As for original post in this thread - I am excited to take a look at the #2 version of the xPetStore. The more I work with Hibernate, the more I like it. I am curious to see how I can leverage XDoclet to speed up my development even more. Keep up the good work!

    Ryan
  8. Clinton I fully agree. If you need to generate code then something is lacking. One of the reasons I don't like EJBs is because you have to add javadoc tags (if using xdoclet) and generate the Home, Local and Remote (if remote access is required) interface for each class
  9. Hi Cameron and Clinton
    First to address your concern, you can try Jenerator (http://www.visioncodified.com) It dosent use JavaDoc tags. For normal generation the only thing which you have to configure is the Datasource name and the output directory. If you want to do some customization then you do the changes in a separate descriptor file and ***not*** as javadoc tags in the source. The descriptor file looks very much similar to the ejb-jar.xml file so the learning curve is greatly minimized moreover it is generated for you.

    In a server side component model as EJB where to write one EJB you have to write atleast 4 source files. I dont see any point in creating them manually if some product can let you do that.
    In the products which i have worked earlier we have generated 65% implementation code and unit testing code using a home made code generator. In my company we felt a need to generate repetious code which could be generated by giving little meta information from some source i.e. Database or Modeling tool or source files which would greatly reduce the time,cost and bugs and save ourselves from the donkey work. Since the code is generated from a XSL template one needs to only code review one file which generates the code for one type of source file. This file can be written by an experienced programmer. It also enforces a same style of code everywhere and in a way helps Conceptual Integrity. Since most of the code is generated the bugs are greatly reduced.
    In my opinion if a generator does the following things it is very usefull.
    1. Generates all the repetious code based on some meta information.
    2. The code is generated based on templates. Hence gives full control to the developer to change the way code is being generated.
    3. Configuring the code generator is as simple as possible.
       Hence IMHO that i dont like JavaDoc statements in the source file.
       A. One has to learn new tags.
       B. It is messy.
    4. It supports regeneration. So that after the first generation when you regenerate the second time it retains the manual code.
     
    I really dont see how one can say that if one requires code generation then the underlying framwork can be lacking.
    <Clinton>
    Instead I've always found a way to abstract, encapsulate and/or layer software such that code is not *so* redundant that generation is required


    I would really like to know how one can achieve less work, bugs and cost by using the techniques stated above i.e. abstract, encapsulate,layer software in a project using EJB's


    /Siddhartha
    Software Architect
    (Developed Jenerator http://www.visioncodified.com )
  10. I would really like to know how one can achieve less work, bugs and cost by

    >>using the techniques stated above i.e. abstract, encapsulate,layer software
    >>in a project using EJB's

    I just need to clarify: I don't have a magic solution for EJBs. Quite the opposite actually. I'm asking what you think of EJB in terms of the levels of code generation required to be productive. In other words, would xdoclet exist if EJB did not have so much configuration/descriptor/stub code? Would JBuilder/Together need an EJB GUI modeler?

    My questions were really around, whether the level of code generation required is representative of something lacking in the framework.

    If you're asking yourself: "What does he mean? How else could it be done?" I recommend looking into a product called Forte 4GL from a company called Forte that Sun bought. They had a "Service Object" model that was absolutely amazing. You simply coded a normal business object (with very few limits or implications) and deployed it anywhere. The service "wrappered" the object in a totally transparent way. The deployment and runtime environment took care of the details of configuration and stubbing etc.

    Right now Sun is sitting on this technology, it's in their basement. That's just one example. I seem to recall the JBoss folks working on something like this too....

    Thoughts?

    Clinton
  11. I agree with Clinton. If you have to generate lots of source and/or configuration code to be productive with a given API/framework, then you should be looking for a more well designed API/framework.

    One exception, perhaps, is GUI building APIs, such as Swing. However, although useful, a Swing GUI builder is not essential. One can be proficient in Swing using a good IDE, such as IDEA 3.0, which helps in creating event handlers, and allows the programmer to define any number of useful and easy to use code templates (which generate code snippets, always a good idea).

    As for EJBs, it's clear to me that an alternative that is much easier to develop and use, is possible (or rather, will be once J2SE 1.5 adds support for metadata in code). One example: I should be able to get access to an instance of (the equivalent of) a session bean by just creating (with "new") an automatically generated (but not in source code!) proxy object. With EJB today, I am forced to use JNDI to get a home object, and then get the session instance.

    I also wonder if xDoclet would even exist without EJB. Creating JSP .tld files, for instance, doesn't look like much to me.

    Rogerio
  12. A good discussion for this subject can be found at

    http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
  13. Rogerio,

    I guess I don't understand why gen'ing code is bad. Actually, most of the files I gen are config files. Let's take the example you cited - tag libs. Everytime you write or modify a tag class, you need to modify its descriptor file, too. Most of the information in this file is tightly coupled with the class, such as the class and attribute names. Personally, I would much rather sprinkle some meta-data in my class and gen the config file. No duplication, less work, fewer errors, less to maintain, repeatable. How is this a bad thing?

    This goes for many other things as well, such as adding mark ups to your POJOs to gen O/R mapping files for tools like Castor and Hibernate. Again, why not put the meta-data in the file that contains the class you are concerned with in the first place? As for EJBs... things are the way you (and most others) would like them in their current state. However, they are what they are. If you have to use them, why not use XDoclet to make your life easier.

    On last example I mentioned earlier - mapping URLs to "actions" or "commands". If you do this type of mapping - where do you define it. In a seperate config file that maps an alias to a class. If so, why not place a tag in the class that names an alias, and generate the config file?

    I admit, I thought adding javadoc tags for meta-data felt a bit "dirty" at first. But compared to the alternative (maintaining practically identical data in two files) - code gen'ing is a no brainer. Hopefully Sun will see the light a provide better mechanisms in the future.

    Ryan
  14. Ryan,

    There certainly are cases when generating source code is a good approach. In general, I would say that it's OK to generate code if 1) you have a higher-level language for a specific problem domain (ex.: Lex/Yacc parser generation), or 2) you are generating boilerplate code that is not going to be re-generated (such as the use of file templates, or IDE-generated code fragments).

    For the case of a JSP tag library descriptor (.tld file), I prefer to use a good XML editor, or even better, an IDE that supports XML, and do the editing by hand. I have done this, and found that the time spent editing the .tld file is not sigficant; and since I use and IDE that provides XML code completion and validation, making simple errors is not a concern. With XDoclet, I still would have to write a lot of (Javadoc) tags, and without any help from the IDE. I would have to learn the necessary XDoclet tags, as opposed to just knowing about TLD.
    Not to mention that I would have to remember running XDoclet every time I changed a JSP tag-related XDoclet tag.

    I am currently using Hibernate, but I don't see a need to use XDoclet. I rather understand Hibernate's XML mapping files, and edit them (one for each POJO) with the IDE's XML editor. To add XDoclet tags to the Java sources would pollute them. I haven't yet used it, but Hibernate's Java-to-XML mapping generation tool seems to be very useful as a starting point for the XML mapping file.

    For EJBs, when you have to use them, I agree XDoclet is a lot more useful. On the other hand, I played a little with IntelliJ IDEA 3.0 support for EJB development, and was impressed. It helps a lot in keeping the several files in synch, and has a nice GUI for ejb-jar.xml (no support for the proprietary XML files, though). I probably could be a bit more productive with XDoclet, but I would still prefer this approach (the IDE) instead of XDoclet. In the end, this wouldn't matter much, I suspect: most of development time is spent in activities other than manually editing Java or XML code.

    As for mapping URLs to actions/commands (as in Struts), I think it's a bad idea. Requests should be sent to web resources (JSP pages), not to a logical entity. Of course, you don't really want to manually construct URLs, and that's not necessary with a good MVC web app framework.

    I do agree that keeping two (or more) related files in synch is boring and somewhat error prone. But, assuming you have the appropriate editors (and any good IDE these days have that), it's not that hard. Anyway, unless you are doing EJBs, this need doesn't come up that often. Maybe what I most dislike about XDoclet is that it gives you an excuse to not learn about the secondary file languages (.tld, ejb-jar.xml, Hibernate's XML mapping, etc.).

    And about Sun seeing the light, I guess they are already in the right path. The metadata attributes of J2SE 1.5 will open the door for a new enterprise component model, and JSP 2.0's new tag files make it unnecessary to write tag classes and TLD files for most application-specific custom tags.

    Rogerio
  15. I agree with many points of what Rogerio said.

    EJB:
    IMHO, putting the EJB meta-data for deployment descriptors on the Java
    source is not a good practice:
    - You can use "one" implementation of EJB with "many" ejb-jar.xml. Let's
    say you implement one EJB discussion forum component and you want to use
    it two times within the same container, because the second discussion
    forum EJB needs to access into another database. So you need to make 2
    ejb-jar.xml for the same EJB implementation. You cannot generate this
    from your Java source. It is not always the case that you use one
    implementation of EJB with one ejb-jar.xml. That's why the name
    "deployment" descriptors ;-) So, to mix "development time" (Java
    classes) and "deployment time" (Deployment Descriptors) is a bad idea.
    - It seems to me that many people hate the deployment descriptors in
    EJB. I like them. For me dd is the advantage of using EJB. You can make
    many optimizations within the "deployment time" with them. I cannot
    imagine if I have to compile each time I change some transactions
    attributes within the dd ;-) -> This is all about in component-based
    development.

    The bad thing in EJB is that you need minimun of 4 classes (home,
    object, bean, pk, value object, etc.) for one implementation at the
    "development time". One class should be enough. This is where XDoclet
    can help a lot. Put all the stuffs into 1 class and generate the rest.
    And the class we should use is surely the bean class, where we implement
    the whole things.

    <quote>
    As for EJBs, it's clear to me that an alternative that is much easier to
    develop and use, is possible (or rather, will be once J2SE 1.5 adds
    support for metadata in code). One example: I should be able to get
    access to an instance of (the equivalent of) a session bean by just
    creating (with "new") an automatically generated (but not in source
    code!) proxy object. With EJB today, I am forced to use JNDI to get a
    home object, and then get the session instance.

    Until now I cannot imagine how these stuffs can be made easier or
    better... The structure of those files just follow a good basic design
    pattern:
    - home -> factory
    - object -> interface
    - bean -> implementation
    Just by doing "new" means that you don't have any controls to access an
    object on the network, is just like "I want to send my mail" without
    address ;-) JNDI is good practice. Get the factory (home) and access
    only the interface (object) without touching the implementation (bean).

    What I can imagine:
    Throw all those design pattern with EJB (value object, etc.). If we
    don't have to take care of these stuffs and we can work just normally
    with the EJBs (SB, EB, etc.) as if they were local:
    - Get the object through JNDI.
    - Create with Factory.
    - Access the method.
    And I don't have to care about these things:
    - Calling a method in EB means calling it through the network. Who
    cares? The EJB container takes care of this, no problem. The call will
    be optimized without you have to deal with it. No need for value object.
    - Session Facade is a good design pattern but instead sending value
    object, you can just send the EB, no problem.

    The development of EJB without those EJB design patterns (especially
    value object) would be a very easy development!

    So, the question is actually not building another component model with
    AOP or whatever. The question is actually how we can throw all those
    unnecessary EJB design patterns to make the development of EJB easier
    without performance problems -> back to the root.

    To sum up, using Floyd EJB design patterns book (sorry Floyd ;-)):
    - Throw Value Object, Data Transfer Object patterns, access directly to
    Entity Beans. The performance is just the same.
    - Throw Business Delegate. We only use EJB as our technology, so who
    cares about using Business Delegate patterns. Using EJB is just like
    using Object in Java.
    - Throw Businees Interface. We only need the RemoteObject interface. And
    throw Local Object. Everything should be remote without performance problem.
    - Throw EJBHomeFactory, InitialContext can cache itself.
    - Include UUID for EJB within EJB spec.

    The one who can make these changes happen are the EJB server vendors. So, EJB vendors (included JOnAS and JBoss) can you do this? ;-)
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
  16. EJB Ideas?[ Go to top ]

    One question: Is there any possibility adding method into the home interface?
    It would make the development of EJB a lot easier! Like this example shows:

    --------------------------------------------

    Workflow Object:
    SSB: LoginApplicationObject
         - Person applyForLogin(PersonObject person)
           -> Check whether the person's username already available
              -> Yes: Error
              -> No: Create the person.

    Business Object:
    CMP EB: PersonObject
            - userName (get/set)
            - password (get/set)

    --------------------------------------------

    Client application:

    // User gives input about the person userName and password
    ...

    // We don't want to persist the person directly
    PersonHome personHome = ... get home through JNDI ...
    PersonObject person = personHome.createValueObject(userName, password);

    // Use the workflow object to create the login
    LoginApplicationHome loginHome = ... get home through JNDI ...
    LoginApplicationObject loginApplication = loginHome.create();
    PersonObject newPerson = loginApplication.applyForLogin(person);

    // Do something with the person...
    // This will not change the content in the DB because
    // we have a ValueObject
    newPerson.setPassword("1. Change")

    // We want to make a direct access through the network
    // to change the content in the DB...
    PersonObject changePerson = newPerson.asObject();
    // This method will persist the result directly into the DB
    changePerson.setPassword("2. Change");
    ...

    --------------------------------------------

    Server application:
    LoginApplicationObject implementation -> LoginApplicationBean

    ...
    public PersonObject applyForLogin(PersonObject person) {

      PersonHome personHome = ... get home through JNDI ...
     
      try {
        // Check whether the person's username already available
        PersonObject searchPerson = personHome.findByUserName(
          person.getUserName());

      catch(FinderException ex) {
        // Not found, ok to continue...
      }

      // Create the person persistently
      PersonObject newPerson = personHome.create(
        person.getUserName(), person.getPassword());

      // Return the person as ValueObject
      return newPerson.asValueObject();
    }
    ...

    --------------------------------------------

    As you can see the EJB vendors should also implement the "createValueObject" method
    within the home interface. And also adding and implementing "asValueObject" and "asObject"
    method for EJBObject. So the "person object" can always change its character into
    persistance or non-persistance object...

    Advantages:
    - I as developer never need to implement the whole Value Objects by myself.
    - Access to those objects are standardized.
    - Flexibility: We can do what we want with those EBs. Make it persistance on server, client
      or make it non-persistance...
    - Maybe it is also good to let the developer extend the ValueObject implementation but
      in the beginning we get the standard implementation of ValueObject.

    I think this should be easy to do, right? ;-) BTW.: Is this already possible in the current
    EJB spec (I never thought about this ;-))? Any other ideas?

    Lofi Dewanto.
    http://openuss.sourceforge.net
  17. Take a look at this: codegenerationisadesignsmell

    And this one too:
    Interview

    Read what the guy who has developed many parts of XDoclet thinks about code generation. You see I agree with most of what you're saying here. Code generation should be avoided, use it only if you need it. @tags are a bit different. They add meta data to your code. It's ok to generate a struts config or xml file from @tags, it's not code generation in this case really, it's adding meta data to your code. Adding a @transaction tag to the code is easier and more readable than an obscure out of context <transaction/> element to an xml file. If you feel that a @tag really *belongs* to the code then use it, otherwise don't.

    With regard to EJBs, yes if you generate a lot then it means the framework is not well designed. XDoclet was born to make EJB development easy. But it's useful for other use cases too. Generating struts config files or Hibernate config files for example. Yes it's useful for Hibernate too, Gavin King himself uses it too. But that's true that you can work with Hibernate's xml files directly too, without a major hassle I mean. It shows how well designed Hibernate is. It's true about WebWork too. WebWork also has a very simple configuration system. I don't use XDoclet for webwork, but for Struts I would use it.

    Ara.
  18. XDoclet[ Go to top ]

    I am currently using Hibernate, but I don't see a need to use XDoclet. I rather understand Hibernate's XML mapping files, and edit them (one for each POJO) with the IDE's XML editor. To add XDoclet tags to the Java sources would pollute them. <

    I'm going to sit absolutely on the fence on this one. Both are absolutely valid approaches and I am quite happy working with either. At work I am using XDoclet, because

    (a) I personally find it very nice to have the metadata in the source; it is more self-documenting and makes code easier to refactor - metadata is often a major hindrance to refactoring in J2EE applications!
    (b) I need an XDoclet build *anyway*, because I am using session beans and refuse to write all that unnecessary gunk by hand

    OTOH, some small applications don't need a build script at all. So it might increase the compile / test cycle to add an XDoclet step, particularly if your IDE uses incremental compile.

    Hibernate doesn't require XDoclet, because Hibernate metadata was specifically designed to be *readable*. J2EE metadata, on the other hand, is often very unreadable. Particularly WebSphere stuff which is horrible. On top of that, J2EE forces you to write a bunch of code whose purpose is absolutely orthogonal to the business problem you are trying to solve. That is a Bad Thing and XDoclet is a brilliant fix.

    >> yes if you generate a lot then it means the framework is not well designed. <
    Absolutely. A number of people have said that the need for code generation points to a problem with the framework and that is completely true. I have no doubt that if you sat down a few of us in a room and asked us to build a framework that would allow declarative transactions, thread pooling, remoteness, declarative security, then we could build something simple and elegant that would not require all the EJB gunk. But the reality is that we all have to live with frameworks that are not ideal. I use session beans + XDoclet because the combination is still a Good Thing. Not perfect, but better than not having them. (OTOH, Entity beans are an abomination that I hope and believe will be deprecated in the next release of J2EE.)

    In the end, XDoclet is absolutely invaluable to the J2EE platform. If you are developing J2EE applications *without* it, I believe you are making a mistake.
  19. "I personally find it very nice to have the metadata in the source; it is more self-documenting and makes code easier to refactor - metadata is often a major hindrance to refactoring in J2EE applications!"

    I forgot to mention this point earlier. This is another feature of code generation I really like. Now that IDEs provide such good refactoring support, I repackage/rename classes more often since so much of the headache of changing code has been eliminated. However, you still have to update explicit references to these classes in config files. With XDoclet, you don't worry about this - it just automagically gets changed.

    Ryan
  20. <quote>
    Now that IDEs provide such good refactoring support, I repackage/rename classes more often since so much of the headache of changing code has been eliminated. However, you still have to update explicit references to these classes in config files. With XDoclet, you don't worry about this - it just automagically gets changed.


    IDEA 3.0 does find references in standard config files and change them accordingly when refactoring. Very handy for servlets, filters, and listeners, in my experience.

    Juergen
  21. I'm at a point where I can't imagine writing an EJB without tagging it up with XDoclet tags. At minimum, the basic EJB involves four files: The implementation class, a home interface, a remote interface, and a deployment descriptor. Throw other artifacts such as utility objects, value objects, local interfaces, and container-specific deployment descriptors into the mix and you start to understand why people say that J2EE is hard! Conceptually I have no problem with EJBs, but writing them by hand beats me down.

    Servlets, Struts, and JSP tag libs are much simpler than EJBs and, at first, I thought that XDoclet was overkill for them. But I've always hated working with web.xml and struts-config.xml, so I tried it, I liked it and I think I'll stick with it. Yeah, it's pretty easy to go back to writing these manually, but I really don't want to.

    I like the fact that I can write a fairly complex application and not have my IDE overwhelmed with open editors. I like the fact that any question that I have about my EJB, Servlet, or JSP tag can be answered by looking at exactly one file. I like the fact that if I must add/delete/change a method in my EJB, I don't have to touch four or more files.

    Someone said that they prefer to use their IDE for that stuff. I can respect that--Use the tool that's best for you and helps you get your work done better and faster. I have found that XDoclet is the best tool for me. One cool thing about XDoclet is that it's not an all-or-nothing tool. You can use as much or as little of XDoclet as you want and let merge points handle the rest.
  22. IDE and tags[ Go to top ]

    <quote>

    Someone said that they prefer to use their IDE for that stuff. I can respect that



    Why should it be exclusive?

    http://beust.com/ejbgen/demos

    --
    Cedric
  23. RE: IDE and tags[ Go to top ]

    Take a look at JBoss-IDE. It's an Eclipse plugin and supports XDoclet by providing @tag autocompletion and context sensitive validation. Works for all XDoclet modules, ejb/web/hibernate/jmx/whatever.

    Ara.
  24. That's kind of my point. EJB is not a good framework. Sure, it is need for some things, but creating interfaces for most if not all classes is counter productive - yes, even using xDoclet or some other code generator.

    IMHO, if you need code generator then there is an easier and simpler way.

    Yeah, sure if you need to do EJB development use code generation.
  25. Stop using compilers then
  26. Ummm[ Go to top ]

    Stop using compilers then <

    Listen, much as I like XDoclet, this idea that code generators are the same as compilers is just silly. My IDE (eclipse, and before that, VAJ) supports incremental compile. Find me a code generator that does incremental generation (quickly) and I might concede your point. In my env, the XDoclet build takes MUCH (several orders of magnitude) longer than the little piece of compile that happens when I hit ctrl-s.

    Code generation DOES slow down my test cycle. But it *might* be worth the effort if it also gains me a lot (as XDoclet does).
  27. My way of looking Lightweight & Heavyweight are as follows.

    - Sheer-size of the Run-time library doesn't have anything to with this classification.
    - Nor is the developmental complexity. It is bit easier to write a small application without using struts but does that mean using "Struts" makes it heavyweight.
    - They should be classified on the overhead involved in processing the request.

    1)Heavy: Servlet - EJBs (CMP ) - Database
    Here we have Run-time over head at
      - EJBs due to the various interceptors that the request has to pass through
      - EntityBeans and the CMPs..
    2)Medium: Servlet - Business Classes - O-R Mapping - Database
      - O-R mapping classes
    3)Light : Servlet - Business Classes - DAO - Database
      - Everything is pretty straightforward.. These are the bareminimum components that we need..


    I would appreciate if we have a equivalent stack like 3) in this Petstore implementation..

    thanks
    Murali Varadarajan