Ma************@ insightbb.com (Martin Zeigler) wrote:
I have been using Weblogic 5.1 for a couple of years. I currently
pass an object as a parameter to my ejbCreate method. The data in the
object could be modified by my bean and the caller needs to see these
changes. This worked fine in 5.1, but it does not work since I have
upgraded to Weblogic 7.0. The changes to the object passed as a
parameter does not make it back to the caller on the remote interface.
I assume the object is not being serialized back to the client. Does
anyone know why this behavior has changed and is there a way I can
indicate to the ejb container that I want these parameters serialized
back?
There is no "serialized back" in EJB. I haven't tried what you're
doing, but it definitely should NOT work. I would speculate that what
you are seeing is a bug in WebLogic 5.1, associated with their
optimization of "local calls to Remote Interfaces". They probably gave
your bean the reference to the actual object, which is expressly
forbidden by section 18.2.3 of the EJB 1.1 Specification:
"Specifical ly, the EJB Container is not allowed to pass
non-remote objects by reference on inter-EJB invocations
when the calling and called enterprise beans are collocated
in the same JVM. Doing so could result in the multiple beans
sharing the state of a Java object, which would break the
enterprise bean's semantics."
(In the EJB 2.0 Specification, this requirement is in section 24.2.7).
Fortunately for you, there is an easy solution: change your bean to
use a Local Interface instead of a Remote Interface (and of course,
LocalHome instead of Home Interface). This will allow the arguments to
be passed by reference*:
"An enterprise bean's local home and local interfaces are
local Java interfaces. The caller and callee enterprise
beans that make use of these local interfaces are typically
collocated in the same JVM. The EJB Container must ensure
the semantics for passing arguments across these interfaces
conforms to the standard argument passing semantics of the
Java programming language." -- EJB 2.0 Spec, Section 24.2.7
Editorial: A much better solution would be not to modify parameters,
as that is quite unexpected behavior for EJBs. An even better solution
would be not to use stateful beans at all, and rely entirely on
stateless session beans and message-driven beans.
As an aside, you probably would have gotten a better response on
comp.lang.java. beans. This newsgroup (comp.lang.java ) is not an
"official" newsgroup, and thus does not reach many sites outside of
Google Groups. The worldwide Java newsgroups are:
comp.lang.java. 3d 3D Graphics API's for the Java language
comp.lang.java. advocacy Support for and criticism of the Java System
comp.lang.java. announce Announcements re the Java System (Moderated)
comp.lang.java. beans Java software components (JavaBeans)
comp.lang.java. corba Topics relating to Java and CORBA
comp.lang.java. databases Databases, java.sql, JDBC, ODBC
comp.lang.java. gui GUI toolkits and windowing: AWT, IFC etc
comp.lang.java. help Set-up problems, catch-all first aid
comp.lang.java. machine JVM, native methods, hardware
comp.lang.java. programmer Programming in the Java language
comp.lang.java. security Security issues raised by Java
comp.lang.java. softwaretools IDEs, browsers, compilers, other tools
* for the "Java doesn't pass by reference" crowd: I know that. But you
will note that the EJB Specification uses the term "pass by
reference", and doing so makes it more obvious what is being
discussed. The distinction between "passing objects by reference" and
"passing references by value" just isn't important to this particular
discussion, mm-kay?
