• 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
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Doubt in Spec : EJB Restrictions

 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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??
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is the answer for your question:
http://www.javaranch.com
 
AmitKumar Jain
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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() ?
 
It's hard to fight evil. The little things, like a nice sandwich, really helps. Right tiny ad?
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic