Help coderanch get a
new server
by contributing to the fundraiser
  • 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

No custom ClassLoaders in EJB - how to interpret

Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi. In EJB3.1 spec, section 21.2.2 (Programming restrictions) stands:

The enterprise bean must not attempt to create a class loader; obtain the current class loader;
set the context class loader; set security manager; create a new security manager; stop the
JVM; or change the input, output, and error streams.

Ok, so my EJB can't do it. How about classes that the EJB uses, possibly deep in the hierarchy? Do they also have this restriction? They are technically other classes, but they execute in EJB context (they can for example use the wrapping EJB's java:comp naming context).

I am asking this question as we are thinking of using groovy for ad-hoc scripting (formatting output, defining a configuration DSL for some parts and the like), and the way it works is via a custom GroovyClassLoader. If I can't create my own class loader, I can't use groovy either, which would be bad.

As a side note - do you EJB gurus comply with the restrictions? I mean, no filesystem, no class loader, no threading... Some of them make sense, some others seem overly restrictive. For example, we have a WAR that packages JPA and EJBs in WEB-INF/lib (separate jars). The servlet container can use the filesystem, there is even a special method somewhere (ServletContext?) to get the real path to a resource, but as soon as the border Servlet / EJB is crossed, I can't access files any more, even though it is the same JVM (in our case).

Evildoers! Eat my justice! And this tiny ad's justice too!
We need your help - Coderanch server fundraiser
    Bookmark Topic Watch Topic
  • New Topic