• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Two questions on the EJB programming restrictions.

 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to the EJB3.0 specification, it states a wide array of EJB programming restrictions. I am baffled by two restrictions as follows:

1. The enterprise bean must not attempt to define a class in a package
Q: What does this restriction mean? (I understand that surely we can define the EJB in its own package. How does one EJB define a class in a package?? This does not make sense to me)

2. The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol???
Q: Can somebody explain this please?

Thanks
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. The enterprise bean must not attempt to define a class in a package

I think that it's about using reflection to make classes dynamically, using java.lang.ClassLoader's defineClass and definePackage methods.


2. The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol???

I think it's about the writeObject method of the java.io.Serializable interface. The serialization specification says :

The writeObject method is used to serialize an object to the stream. An object is serialized as follows:
8. Process potential substitutions by the class of the object and/or by a subclass of ObjectInputStream.
a. If the class of an object is not an enum type and defines the appropriate writeReplace method, the method is called. Optionally, it can return a substitute object to be serialized.
b. Then, if enabled by calling the enableReplaceObject method, the replaceObject method is called to allow subclasses of ObjectOutputStream to substitute for the object being serialized. If the original object was replaced in the previous step, the replaceObject method is called with the replacement object.
If the original object was replaced by either one or both steps above, the mapping from the original object to the replacement is recorded for later use in Step 4. Then, Steps 3 through 7 are repeated on the new object.
If the replacement object is not one of the types covered by Steps 3 through 7, processing resumes using the replacement object at Step 10.
 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is helping, thanks.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic