Problem Sharing Home Interfaces


EJB programming & troubleshooting: Problem Sharing Home Interfaces

  1. Problem Sharing Home Interfaces (1 messages)

    I am trying to write a set of beans that share a common remote interface. The idea is to have a set of interchangeable EJB's to enable easy plug and play in a service framework.

    Therefore, I have a package that contains EJB1 and EJB2, both using a remote interface of CommonRemote (which contains one method -- executeService) and a home interface of CommonRemoteHome.

    In VAJ 3.5, everything works fine as long as I have either EJB1 OR EJB2. When I generate the deployed code for EJB1, VAJ creates an EJSRemoteCommonRemote class that looks like this:

    * This method was generated by the VisualAge for Java EJB deployment tool.
    * Warning: Modifications will be lost when this part is regenerated.

    public java.lang.String executeService(java.lang.String arg0, com.sample.ClientProperties arg1, java.lang.String arg2) throws java.rmi.RemoteException {

    EJSDeployedSupport s = new EJSDeployedSupport();
    java.lang.String result = null;
    try {
    com.sample.EJB1 beanRef = (com.sample.EJB1)container.preInvoke(this, 0, s);
    result = beanRef.executeService(arg0, arg1, arg2);
    } catch (java.rmi.RemoteException ex) {
    } catch (Throwable ex) {
    throw new RemoteException("bean method raised unchecked exception", ex);
    } finally {
    container.postInvoke(this, 0, s);
    return result;

    When I generate deployed code for EJB2, the class above is overlaid with a version that references EJB2 instead of EJB1. In short, EJB2 now works, but EJB1 is busted.

    My question here is whether I am doing something that is just plain wrong, ot whether there is an issue in the VAJ deployment code generation tools.

    I would be interested in any opinions. My hope is that I have just done something stupid and someone will be able to point me in the right direction.

    Thanks in advance,

  2. Problem Sharing Home Interfaces[ Go to top ]

    You can't do what you want because the code generator is creating code which refers directly to the implementation class you told it to use.

    HOWEVER, you can achieve what you want but having a single EJB class, which uses some form of factory to get a "worker" object to do it's work. This factory could use some simple reflection (as startup, don't do it every time) to use a property to determine which class to serve up.

    Make all these worker objects all implemented a common interface and you're done.

    In other words, a Factory Method pattern, with an EJB calling it.

    That will achieve what you want. And if your worker code uses SQL etc, then the transactional attributes will still apply as long as you are careful in what you do.