Nightmare of develop EJB


EJB design: Nightmare of develop EJB

  1. Nightmare of develop EJB (3 messages)

      I use a weblogic 6.0 to develop some EJBs, and use jsp to run as the client of EJB. So both client and server run in the same application server.
      Then when I made some change on the interface, I must:
        rebuild the EJB jar
        stop the weblogic
        reset the system classpath to remove my.jar
            (which include the interface defenition of the EJB)
        replace my.jar with the new version.
        reset the system classpath to include my.jar
        start weblogic
      If I do not change the classpath, system always report the file is in used by another process.
      Although the interface definition will not always change, but, the steps is so complex, so I call it Nightmare.
      Anyone can give me some suggestion?

    PS:I must made the client be able to use EJB's interface, so I put the necessary .class files in system classpath, but the weblogic ejb compiler always report error says that the class files should not be put in classpath??

    Threaded Messages (3)

  2. Nightmare of develop EJB[ Go to top ]

    The classpath is not what is locking the file. You must have some other process which has a lock on that file (Probably the IDE which generated it, or winzip, whatever.)

    If WebLogic is running when you try to do the copy, that will kick you out.

    The classpath should have absolutely nothing to do with it though.

    EJB class files should not be on the classpath, this is very correct. If it is needed for the EJB (In other words, its one of the EJB classes, or it's a return class, or an exception) then it should be in the JAR file you use to build the EJB, not on the classpath.


  3. Nightmare of develop EJB[ Go to top ]

      I put the EJB classes in classpath for the client. If I do not do this, How can my client resolves the Remote Interface definition of the EJB?
  4. Nightmare of develop EJB[ Go to top ]

    You should not need the classes on the classpath for the EJB compiler, which was what you said was giving you a problem. You are right, your client needs the remote interface, home interface and any of the exceptions / returned data types that the bean uses on it's classpath.

    Note: it does not need the bean class to be on it's classpath, it never sees it.

    However, none of this explains why changing the classpath would suddenly make the file "not in use by another process."

    Just a thought, but is it possible that it is the time it takes you to make that change that allows whatever process was running to complete and thus release it's lock. I'm not trying to patronise you, it's just I've made similar mistakes myself and more often than not it's something really simple that is causing the problem. After all, if it's something simple, then it's easy to fix. :-)

    Does WebLogic use your JAR file as well? If so, then it will have the file locked unless you shut it down before you try to over-write it.