• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Doubt in EjbCertificate.com�s question

 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?

Thx,
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Eusebio Floriano
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thx Valentin,

You explained it excellent ..

Regards
reply
    Bookmark Topic Watch Topic
  • New Topic