EJB3 CallByValue=false, but acts like its true

[fisherv]

Hi,

I'm using JBoss 4.2.2, EJB3, and JDK1.5_012.

After converting some EJBs from EJB2 to EJB3, I realized that the original EJB authors had assumed a call-by-value behavior - i.e., changes to param objects made inside a call would be reflected outside the call without returning the param objects. Normally, I'd never use call-by-value in the first place with an EJB, but this is legacy code. This is working in JBoss 4.0.3SP1 with EJB2's.

Searches turned up ear-deployer.xml, which has the CallByValue attribute.
I tried both true and false values, but neither allowed the CallByValue behavior.

When the say "CallByValue", do they really mean it? Or is this just a performance optimization for the sending of the param, but doesn't actually make any changes to object params visible to the caller?

Has anyone verified that this works? Is there another value I have to set somewhere else? I would expect this ear-deployer value to affect all ejbs, but no mention of EJB2 vs EJB3 is made in the docs when discussing this config value. See:

http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/Server_Configuration_Guide/html-single/index.html

Thanks,
Vick

[jaikiran]

Are you calling the EJBs using the "remote interface" of the EJBs? As per the EJB3 Core specification 3.2.1, the parameters and return types are passed by value (which means that any changes to the parameters inside the bean will not be visible to the caller):

3.2.1 Remote Clients

The arguments and results of the methods of the remote business interface are passed by value.

Use the "local interface" to invoke the bean methods to pass the objects by reference.

[fisherv]

Thanks Kairan.

You're right - I have been using remote. I thought that this JBoss EAR deployer CallByValue option was a feature implemented above and beyond the specification - it is, isn't it?

I considered switching to local, but that just leaves the potential problem for someone else to solve down the line if remote calls are ever needed later. I'm changing the code to work as call by ref - though this may involve changes in a number of places.

I'm generally against using local for just this reason - your code may stop working if you ever change up your EJB allocation among JVMs/hosts!

[jaikiran]

I thought that this JBoss EAR deployer CallByValue option was a feature implemented above and beyond the specification - it is, isn't it?

Not sure.

I considered switching to local, but that just leaves the potential problem for someone else to solve down the line if remote calls are ever needed later. I'm changing the code to work as call by ref - though this may involve changes in a number of places.

I'm generally against using local for just this reason - your code may stop working if you ever change up your EJB allocation among JVMs/hosts!

As you rightly mention, using remote interfaces and then coding to expect that the parameters will be passed by reference was not the correct thing in the first place. I guess you will have to change the implementation to fix this.