File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Doubt in�s question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Doubt in�s question" Watch "Doubt in�s question" New topic

Doubt in�s question

Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 237
The question is to identify correct programming restrictions that a Bean provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container.

One of the rigth answers is "The enterprise bean must not attempt to define a class in a package.".

I did not understand why it is rigth. Can any one explain me it ?


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
Valentin Crettaz
Gold Digger

Joined: Aug 26, 2001
Posts: 7610
This means that you cannot use the java.lang.ClassLoader.defineClass() method when writing EJBs because this would open a security hole in your application. The defineClass() method takes an array of bytes containing the bytecode of the class as well as the fully-qualified name of the class to define. The method returns a new Class object that you can instantiate to create new objects. The new class would be able to access package protected members and the author of the package (the server vendor) might not have anticipated that. This is allowed by the language under certain conditions but this defeats all OO best practices.

As an anecdote, I was once working with Swing and had a problem with the JComponent class which had several package protected members which I could not retrieve from outside the Swing package. I defined a new class within the Swing package which allowed me to get/set those "default" members for testing purposes, but this practice is really not encouraged. What this would mean for EJBs is that you would be able to define classes in container packages, and thus, interfere with the container behavior which would cause havoc if not properly done. Since all containers are built differently, you have no guarantee that your hacker bean code would run the same way if deployed in a different container. This rule has been expressed in order to ensure portability of your EJBs among the plethora of application servers available out there.

Hope this helps

[Blog] [Blogroll] [My Reviews] My Linked In
Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 237
Thx Valentin,

You explained it excellent ..

I agree. Here's the link:
subject: Doubt in�s question
jQuery in Action, 3rd edition