• 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
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

EJB Classpath Query

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have an ejb, and in the ejb-jar.xml I reference a utility jar file, which seems to work fine.
I have written a small utility to load a properties file, and added this utility and a new properties file to the utility jar.
The utility uses the getResourceAsStream method to access the properties file via the system classloader, which as I understand it looks down the classpath to find the resource.
Now, from my ejb, if I try and use my utility to load my props file, it just can't find it, but I can't figure out why. Strangely, if I output the classpath to std out from the ejb, the utility jar isn't there, though that may be because it's being dynamically changed by that manifest entry.
I'm using WebLogic 8, and when I add the utility jar to the server classpath it's fine.
Anyone have any ideas what I'm doing wrong?
TIA
Dave
 
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Hewy:

The utility uses the getResourceAsStream method to access the properties file via the system classloader, which as I understand it looks down the classpath to find the resource.
Anyone have any ideas what I'm doing wrong?
TIA
Dave


Hi,
you should consider that the getResourceAsStream method you're using returns an InputStream object that belongs to java.io package, even if this works for weblogic it's agains't the ejb specs and you should avoid using it. A better approach would be to load parameters from the dd files if applicabble or change the application to make it free from using the io package.
In the ejb 2.0 specs take a look on topic 24.1.2 - Programming restrictions where it's clear about that:


An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system.
The file system APIs are not well-suited for business components to access data. Business components
should use a resource manager API, such as JDBC, to store data.


This is because the distributed nature of the ejb components as you might know.
 
Dave Hewy
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply.
I am aware of this restriction, but I'm not using this for IO in that sense.
This is purely to provide a "lookup" service so that error message codes can be converted to meaningful text strings for display. Once loaded, this won't change, and yes, I could (and probably will later) do this using a safer method, but it's going to have to do for now!
When the spec says "the enterprise bean must not....", does that also refer to any class being called by that enterprise bean? I suppose it depends on whether the code is running in the ejb container.
Does anyone have any ideas about my original query?
Dave
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Hewy:
Thanks for your reply.
When the spec says "the enterprise bean must not....", does that also refer to any class being called by that enterprise bean? I suppose it depends on whether the code is running in the ejb container.
Dave


Yes, the rule applies to all code running inside the ejb container, so if you have a class being called by the enterprise bean the restrictions apply to that class too.(Unless u're using something like a client socket or rmi to connect to a resourse outside the container, then that resource could load the property files for u).
Another problem about loading a properties file using the classloader is about another restriction for the ejb container:


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.
These functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions
could compromise security and decrease the Container�s ability to properly manage the runtime environment.

 
Dave Hewy
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mmmm - yes you're right, it's time for a rethink on that one!
Thanks - I'll have to think of another way of doing this.
On a similar (ish) subject, has anyone out there got any good strategies for handling distributed caches of data, such as parameters, which will mainly be static, but may be changed during runtime?
Thanks
Dave
 
I will open the floodgates of his own worst nightmare! All in a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic