Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Doubt in Spec : EJB Restrictions

Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to EJB 2.0 spec, Pg 496 (Relating to EJB Restrictions)

� The enterprise bean must not attempt to define a class in a package.

This function is reserved for the EJB Container. Allowing the enterprise bean to perform this function
would create a security hole.

I am not at all getting the above point. What does it mean?? Does it mean that we cannot create a custom/helper class in our ejb-jar file??
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is the answer for your question:
AmitKumar Jain
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am quoting Valentin's explanation dated July 07, 2004 01:03 AM

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.

What I can't understand is that how can the class defined in this way, access the protected members?
The main question now is... whats the difference.. if I instantiate an object directly or after defining class using defineClass() ?
I am displeased. You are no longer allowed to read this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic