EJBMaker from alphaWorks supports any J2EE server


News: EJBMaker from alphaWorks supports any J2EE server

  1. EJBMaker generates sources for CMP beans from xml deployment descriptors. Once a proprietary tool for Websphere, it now supports any J2EE server. Many have recognized the importance of such tool, including Cedrib Beust and Rickard Oberg, both of whom have developed similar tools.

    Now that it is open-vendor, perhaps we may see easier EJB developement and maintenance?

  2. <quote>
    3. Okay, but I'm using the BEA WebLogic application server. Can I still use the EJBMaker?

    Not in its current version. Once application servers handles Enterprise JavaBeans conforming to the version 2.0 specification, a generic enough tool to work on any of those servers is planned.


    Also, I'm not sure that hiding Java and exposing XML makes a lot of sense, but hey, the more tools to choose from, the more power to developers.

  3. Cedrib, oops, Cedric,

    Can I (we) see your tool? URL?

  4. http://beust.com/cedric/ejbgen
  5. Hey Cedrib,

    That was Floyd's flub; I got your name right in my original submission! (Perhaps 'b' is pronouced as 'c' in Canadian?) :-)

    Hey Kumar,

    I believe the document for EJBMaker is a little behind the product update, since the J2EE-certified note is dated just 8/23/01... I was hoping someone has or will try out this to confirm, since I'm a little to busy these days to eval! :-)

  6. I don't think EJBMaker works for 'Any J2EE server' as it is advertised. The entire document talks regarding WebSphere4 and 3.5.

    I agree with Cedric's point regarding hiding Java Code and Using just XML. I didn't quite like the Idea of using JavaDocs to generate EJB code though.

    There is another Interesting article from Tony at javaworld. This talks about using only reflection API. I Used this Idea and Wrote some Code to generate code for EJB's and Classes related to my company specific EJB patterns. I didn't try to maintain the Code or Publish it as a soultion since its being used the least even in My own company. Few reasons why its not used being:

    1. Its not a standard.
    2. The % of Time you spend writing An EJB's (The support classes reqd.) is far less compared to developing a solution.
    3. Requires additional Learning.

    Here is the Java World Arcticle from Tony:

    To Solve this problem there should be an open source tool and should be vendor neutral (as long as the tool is from a vendor it can never become vendor neutral). The Tool need to be Open Source Becasue developers can extend the tool to genreate code related to their company specific patterns. I hope one of the existing solutions will solve the problem.

  7. to provoke:

    why do not do that directly from DB schema?
    E.g. based on the table description (or view)?
  8. Middlegen (http://sourceforge.net/projects/middlegen) does exactly that.

  9. <Kumar>
    I agree with Cedric's point regarding hiding Java Code and Using just XML. I didn't quite like the Idea of using JavaDocs to generate EJB code though.

    Yes, I agree with you that putting everything in javadocs or in xml files is not a good idea. What about a balance between them?
    That's exactly what we've done in XDoclet (formerly known as EJBDoclet, the tool which Rickard Oberg originally had written and it's now being actively developed as an open source project).

    Some things are better expressed as config meta-data in source, for example ejb-name/CMP-BMP type/remote-methods, while others are not because they are more deployment-oriented, for example security role refs or servlet URL mapping (yes not only EJBs are supported but also web.xml/taglib.tld/apache-soap deployment descriptor generation from javadoc @tags). You should be able to declare what your component needs, in @ejb:bean name="MyBean" format, or in separate files. We call the second form 'merge points', your merge a file where servlet-mapping or env-entries is defined there. This is also true for classes that your derive from. For example if you derive from BaseSession class you shouldn't have to dig into the code to find out what env-entries or resources-refs it uses, you should inherit the config data also, and this one is also supported in XDoclet, if you declare a resource-ref in base class because your base class uses it, the ejb-jar.xml section for the derived class also has that resource-ref defined for it.

    For XDoclet see http://sourceforge.net/projects/xdoclet (we'll release v1.0 very soon), and for the older EJBDoclet seehttp://sourceforge.net/projects/ejbdoclet.

  10. Ara,
     Couldn't get much info regarding xdoclet. But sounds interesting though(Main reason being open source and not being a vendor based solution).

     I beleive my code need to be independent of a tool that generates the EJB's.


  11. EJB and Java code generation[ Go to top ]

    EJB and Java code generation:
    Links to products and articles are here

  12. EJB and Java code generation[ Go to top ]

    Why typing the XML file or the Bean so you can generate code? Why not generate code by reading the database schema? This is exactly what the EJBX does. EJBX is a Java based EJB 2.0 CMP Entity Bean Code Generator. The EJBX can provide a fast development toolkit for developer to generate Enterprise JavaBean 2.0 object based on the existing database, just by one simple command. This is to reduce unnecessary typo error and human mistake to generate EJB code to run on any EJB 2.0 CMP compliant servers.