• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread in Stateless Session Bean

 
Jes Sie
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
People,
I've got a stateless session bean which instantiates a plain java class. This class' constructor actually has a code like this: -
ClassLoader classloader = Thread.currentThread().getContextClassLoader();
InputStream inputstream = classloader.getResourceAsStream("SomePropertyFile");

I'm currently using WebLogic 6.1 Most of the time it works. But at certain times it gives a nullpointer on reading this. Is there a flaw in doing this approach that I'm not aware of? Is this some sort of runaway thread?
Any hint would be much appreciated.
 
Craig Demyanovich
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read the the EJB 1.1 specification, section 18.1.2, or the EJB 2.0 specification, section 24.1.2. From the EJB 2.0 specification: "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." As I'm still learning about J2EE and EJB every day, I offer this only as a pointer. A book (e.g., Enterprise JavaBeans by Monson-Haefel or Mastering Enterprise JavaBeans by Roman) or other JavaRanchers may be able to offer further details.
HTH,
Craig
[ August 28, 2002: Message edited by: Craig Demyanovich ]
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18153
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If all you want to do is locate Properties, you can do one of 2 things, both of which are much simpler.
1. Make the properties part of the EJB.
2. Define an EJB environment variable to pass in a filepath.
Note that the EJB spec frowns on EJBs doing file I/O, though this may be one of the more frequently-violated cases, as it has more to do with keeping the architecture clean than actually avoiding server/container/bean problems. Use of the Properties system itself is considered OK, unless someone knows something I don't.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18153
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just realize what KIND of EJB you're using. I definitely recommend against doing I/O in a stateless EJB - you're putting a "slow" operation in a "fast" component.
It would be far better in such a case to have the caller acquire the resource, pass a reference to the EJB, and have the EJB do whatever work is needed. That way you only have to read the resource when the caller needs a fresh copy instead of every time the EJB is invoked.
 
rastin purr
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,
Do you mean than ejbs are not encouraged to do any i/o related work? If so, which server side component would be best suited for it?
 
Jes Sie
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,
Yeah, I do realise it is horrible to do an I/O operation.
Originally posted by Tim Holloway:

1. Make the properties part of the EJB.
2. Define an EJB environment variable to pass in a filepath.

I'm not sure what you're talking about above. Some code snippets would be nice I understand an alternative is to use JNDI, but property file is still better.
 
Jes Sie
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tim Holloway:
I just realize what KIND of EJB you're using. I definitely recommend against doing I/O in a stateless EJB - you're putting a "slow" operation in a "fast" component.
It would be far better in such a case to have the caller acquire the resource, pass a reference to the EJB, and have the EJB do whatever work is needed. That way you only have to read the resource when the caller needs a fresh copy instead of every time the EJB is invoked.

That would be semantically incorrect. The nature of the property content are related to the persistent tier like which DB user, which JDBC, etc. Don't think the caller(which is the web client) should have this info. It has to be done during or after the session bean. Any ideas?
FYI, it is an implementation of a DAO pattern.
 
Jes Sie
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the problem is fixed....I use: -
ResourceBundle theResource = ResourceBundle.getBundle("myPropertyFile");

Interestingly, this one calls the WebLogic thread.....no wonder J2EE specs disallow our own threading. It messes up what the J2EE vendor's implementation of threads?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic