geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Idea(OpenEJB/geranimo/calling a EJB from the same VM)
Date Tue, 16 Mar 2004 00:26:08 GMT
On Mon, Mar 15, 2004 at 09:25:12PM -0800, Srinath Perera wrote:
> Hi all;
> for the JSR109 implementation for geranimo I want to write a code to call a
> EJB from the
> the same VM. I do not want use the Local interface.
> (what should happen is there is a servlet running in the webcontainer that
> run in the same VM in the J2EE container. this servlet want to call the ejb
> in the
> J2EE container directly calling J2EE container methods)
> I find a way to do it inside OpenEJB like this
>     String deploymentID = . get deployment id   from request
>     DeploymentInfo deployment =
>     OpenEJB.getDeploymentInfo(deploymentID);
>     RPCContainer container =
>     (RPCContainer)deployment.getContainer();
>     container.invoke(deploymentID,callmethod,
>     args, securityIdentity);
> when Open EJB is integrated to the apache does this thing preserved. Will
> this thing work in the gernimo as well.

You'll have to change your code slightly with the new source, but
you're safe.  In my rework/merge of the old main and nova branches, I
preserved the basic "flat" invocation style as it's a must for things
like web services, corba, etc. where clients aren't necessarily
java-aware--let alone cglib-aware.

To summarize the new architecture:
  - DeploymentInfo is merged with RpcContainter and are now just EJBContainer
  - Instead of DeploymentID, it's ContainerID
  - The OpenEJB static class is being depricated (this part is in flux)

The new code:

  String containerID = ... // get container id (aka deployment id) from request
  ContainerIndex index = ContainerIndex.getInstance();
  EJBContainer container = index.getContainer(containerID);
  container.invoke(callMethod, args, primKey);

All container ids are indexed numerically, so it is possible to save
some space on the line by sending clients the index rather than the
full id.  So:
  // At some point earlier...
  ContainerIndex index = ContainerIndex.getInstance();
  int containerIndex = index.getContainerIndex(containerID);
  // send client containerIndex instead of containerID

  // Then later...
  String cotnainerIndex = ... // get container index  from request
  ContainerIndex index = ContainerIndex.getInstance();
  EJBContainer container = index.getContainer(containerIndex);
  container.invoke(callMethod, args, primKey);

That might be a smarter way to go as the nature of cotnainerID may
change--I don't think it will remain a String.

The ContainerIndex is a temporary replacement for
OpenEJB.getDeploymentInfo; that the part in flux I mentioned.
Containers are GBeans and will be registered with the kernel.  Odds
are I'll simply rework ContainerIndex to be kernel-aware so it knows
when containers come and go.

The part I haven't decided is where you get the ContainerIndex from--I
don't like the static getInstance method.  It's likely ContainerIndex
will be made a GBean as well and also registered with the kernel, then
you can get it as an injected dependency or look it up from the kernel

At any rate, all this code is in the new OpenEJB cvs. See for cvs and building


View raw message