Deploytool - Exception in generated code during compilation

Question

Hi,
I am trying to deploy a rather simple container managed application. When running it through the verifier of J2EE1.3.1 I receive no errors.
During deployment I get the following message:
"Error deploying ejb.jar: Compilation failed"
The j2ee server output shows, that the error is located in the generated code of the Bean class:
"d:\Java\j2sdkee1.3.1\repository\lap18\gnrtrTMP\AufnahmeAgent\de\faw\charite\aufnahmeagent\generated\AufnahmeAgentBean_PM.java:3: de.faw.charite.aufnahmeagent.generated.AufnahmeAgentBean_PM should be declared abstract; it does not define remove() in de.faw.charite.aufnahmeagent.generated.AufnahmeAgentBean"
How can this be my error?
The log only shows the following:
Compilation failed.
     at com.sun.ejb.codegen.GeneratorDriver.compileClasses(GeneratorDriver.java:232)
     at com.sun.ejb.codegen.GeneratorDriver.preDeploy(GeneratorDriver.java:603)
     at com.sun.enterprise.tools.deployment.backend.JarInstallerImpl.deployEjbs(JarInstallerImpl.java:707)
     at com.sun.enterprise.tools.deployment.backend.JarInstallerImpl.deployApplication(JarInstallerImpl.java:221)
     at org.omg.stub.com.sun.enterprise.tools.deployment.backend._JarInstallerImpl_Tie._invoke(Unknown Source)
     at com.sun.corba.ee.internal.corba.ServerDelegate.dispatch(ServerDelegate.java:355)
     at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:255)
     at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProcessor.java:84)
     at com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:99)
Anybody ever met anything similar?
My Setup:
NT4.0
JDK1.3.1 && JDK1.4 (tried both, made no difference)
Code:
BEAN CLASS:
public abstract class AufnahmeAgentBean
        implements AufnahmeAgentModel, ClientAgent, EntityBean {
    private AufnahmeAgentControl control;
    public void registerRMIRemote(String remoteClassName) {
        try {
            Class cls = Class.forName(remoteClassName);
            Object[] params = { getClientRMIServerAdress(),
                                getClientRMIServerName() };
            Object instance = cls.getConstructors()[0].newInstance(params);
            control.registerClient((AufnahmeAgentClientInterface)instance);
        catch(Exception ex) {
            System.err.println("Fatal RMI Error: " + ex);
    public AufnahmeAgentBean(){}
     * Called by the AgentEngine if a new AgentMessage has been sent to this.
     * @param msg the AgentMessage
    public void processMessage(AgentMessage msg) throws RemoteException {}
     * Called if a new request AgentMessage has been sent to this.
     * @param msg the AgentMessage
     * @return the result of the request
    public java.io.Serializable processRequest(AgentMessage msg) throws RemoteException{}
     *  data access methods
    public abstract String getAgentName();
    public abstract void setAgentName(String agentName);
    public void ejbRemove() {}
    public void setEntityContext(EntityContext context) { }
    public void unsetEntityContext() { }
    public void ejbActivate() { }
    public void ejbPassivate() { }
    public void ejbLoad() { }
    public void ejbStore() { }
     * Creates a new AgentServerBean instance.
     * @param serverID the id of this
    public String ejbCreate(String agentName)
            throws CreateException, RemoteException {
        setAgentName(agentName);
        AgentEngine agentEngine = new  EJBAgentEngine(EJBAgentEngine.STATIC_SERVER_ID);
        control = new AufnahmeAgentControl(getAgentName(),agentEngine, this);
        return agentName;
    public void ejbPostCreate(String agentName) {
}THE REMOTE INTERFACE
public interface AufnahmeAgent extends EJBObject {
    // The CMP methods for client connection
    String getClientRMIServerAdress() throws RemoteException;
    String getClientRMIServerName() throws RemoteException;
    void setClientRMIServerAdress(String value) throws RemoteException;
    void setClientRMIServerName(String value) throws RemoteException;
    public PatientMitPrioritaet[] getNawPatienten() throws java.rmi.RemoteException;
     public String getRTSArzt() throws java.rmi.RemoteException;
     public void setNawPatienten(PatientMitPrioritaet[] values) throws java.rmi.RemoteException;
     public void setRTSArzt(String value) throws java.rmi.RemoteException;
}

Answer 1

Hi again,
I found the error. To explain it it is necessary to state that the interfaces implemented by the Bean class are generated. Since the code already worked at a time I didn't check it, which profed a mistake.
One of the interfaces extended the EJBObject interface. Because of this the AufnahmeAgentBean thought it had to implement those methods too :-(
Well lots of time wasted, but at least I now know a bit more about the architecture of our product.
Where did you read this?? By "data access methods" do
you mean your bean's "business methods"? Again, the
container/vendor tool has no way of knowing how to
implement your beans abstract methods - only the
interface methods which it (usually) does by wrapping
your bean. The container knows which of your beans
attributes it is to manage from your bean's Deployment
Descriptor: specifically, those elements identified as
<cmp-field>, not from reflecting on your code!By data access methods I mean the following:
you got a String that shall be managed by the database. Normally, of course, one would just declare it:
protected String _foo;
when using container managed persistence you just declare the accessmethods as abstracts:
public abstract String getFoo();
public abstract void setFoo(String foo);
Thus the bean must be declared abstract.
You asked where I read that the bean is always declared abstract when it uses CMP. Right here:
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/CMP3.html
In section Differences between Container-Managed and Bean-Managed Code
No they don't, and they are not supposed to. The
remove method is part of the EJBObject definition,
and>
As I stated previously, such a declaration would not
have been the same as those in your bean's interfaces.
:)>
afaik it doesn't have to be implemented when using
container managed persistence.>
The 'ejbRemove' method in your bean doesn't ever have
to be implemented, but is does have to appear in your
bean since it's declared in the Session/EntityBean
interace. All methods in these interfaces are
container callback methods. They exist to enable the
container to manage the life of the bean. The
'remove' methods in the Home and Remote interfaces are
implemented by the vendor tool and proxy to the bean's
ejbRemove method. Calling CMPInterface.remove still
propagates a call to CMPBean.ejbRemove. In this case
ejbRemove provides your bean the opportunity to null
its members and allow garbage collection to occur more
quickly.well of course you are right... but I didn' t receive the error message because of the ejbRemove but because of the remove method, which isn't supposed to be implemented in the Bean class. Now of course we know why ;-)
Well thanks for your time, I decided to reward your invested time with five of the ten Duke Dollars ( especially since it reall was a design flaw that you couldn't find...lacking the sourcecode)
Greetings, and thanks for the help,
Markus "marksman" Hammori