Discussions

EJB programming & troubleshooting: ejb command pattern (deployment strategy)

  1. ejb command pattern (deployment strategy) (6 messages)

    Hi all,
    what is the right approach for deploying command pattern on both -- the client and the server.
    I could only get it to work if i deploy the implementation classes of the concterete command as part of the ejb deployment unit. The problem with that, if i need to fix a bug (or make an enhancement) in the command code, i have to redeploy the ejb with the new version of the command classes. I can't do that because i expect a lot of frequent changes of the commands versions and can't afford any system down time (it must stay up, so can't really be redeploying ejbs).
    I have a stand alon client java app that executes command and dies. If the command class version changes, i would hope that the new version will be pushed down to the server where it can successfully execute.


    Please correct me if i'm making wrong assumtions. FYI, i'm using iPlanet 6.5 with RMI/IIOP java app client.

    Threaded Messages (6)

  2. Reply[ Go to top ]

    Well,

    Dmitry, there is quite a dilemma here.

    If you wish to execute your command on a server side but intend to escape redeployment of the beans every time you change your command, in that case I can't see any possible ways to sort it out.

    I am not sure about iPlanet, but most of the AppServers allow you to redeploy beans while keeping system up. On the other hand, you could create a clone system in order to perform changes on it. You could replicate all the changes manually to your production system afterwards.

    Hope it helps.

    Alex
  3. Reply[ Go to top ]

    I was using the command pattern as an example, i think the issue is much broader. To simplify things a bit, if i have an ejb with a method that takes an intance of an interface (that itself extends a serializable) as a parameter, i thoght i don't need to deploy the implementation of that interface to the server side, only the interface that ejb will be operating on. The client on the other hand will instantiate the concrete instance of that interface and pass it as a parameter to the ejb call, since the ejb does not have the class deployed in it's local class path, it will get the actual class from the remote class loader. I thought it was one of the biggest promisses of the distributed java computing. I actually got it to work in RMI client-server application. Since i'm hiting a wall with ejb, i'm trying to figure out if ejb is didfferent then RMI client-server (i though it should not be since it's based on RMI).

    Dmitry A>

    > Well,
    >
    > Dmitry, there is quite a dilemma here.
    >
    > If you wish to execute your command on a server side but intend to escape redeployment of the beans every time you change your command, in that case I can't see any possible ways to sort it out.
    >
    > I am not sure about iPlanet, but most of the AppServers allow you to redeploy beans while keeping system up. On the other hand, you could create a clone system in order to perform changes on it. You could replicate all the changes manually to your production system afterwards.
    >
    > Hope it helps.
    >
    > Alex
  4. Reply[ Go to top ]

    I was using the command pattern as an example, i think the issue is much broader. To simplify things a bit, if i have an ejb with a method that takes an intance of an interface (that itself extends a serializable) as a parameter, i thoght i don't need to deploy the implementation of that interface to the server side, only the interface that ejb will be operating on. The client on the other hand will instantiate the concrete instance of that interface and pass it as a parameter to the ejb call, since the ejb does not have the class deployed in it's local class path, it will get the actual class from the remote class loader. I thought it was one of the biggest promisses of the distributed java computing. I actually got it to work in RMI client-server application. Since i'm hiting a wall with ejb, i'm trying to figure out if ejb is didfferent then RMI client-server (i though it should not be since it's based on RMI).

    Dmitry A>
  5. Reply[ Go to top ]

    here is the exception i'm getting if that helps:

    java.lang.IllegalAccessError

    It looks like i have to configure some sort of access permissions for dynamic class loader, in RMI it's easy.
    Any guideliens how to do it for RMI/IIOP which is used by the ejb container.
  6. Dmitry[ Go to top ]

    Interesting stuff... Really, I don't know the answer. :(
    I can just assume that it could be possible to switch AppServer to RMI/JRMP from RMI-IIOP somehow.
    But I am not sure.

    Alex
  7. So, i'm interested to here if anyone ever was able to implement classick distrubuited command pattern in EJB container, the one that does utilize the consept of dynamic class loader.
    If yes, i'd like to know what application server was used, how easy was it to configure and use, does it really dynamically pick the new version of the same command implementation without redeploying the EJB.

    Dmitry A>

    I'm using iPlanet6.5 it it was not easy so far.