I understand where your caution comes from about the ClassLoader after reading the spec,
but when I read the Javadoc on getClass().getResource(), it sounds like it too is
locating the ClassLoader. When I did some searching, I found that Tom Marrs (Lead Author,
JBoss at Work: A Practical Guide) had the same solution as I did as late as 2006.
http://www.coderanch.com/t/89900/JBoss/reading-properties-file
I spent the last few days building up a simple set of test cases where I loaded classes
and resources from different types of ClassLoaders both inside and outside the EJB. In my
simple test case, I could not recreate the problem. I finally tracked the issue down to
the deployment descriptor. The JBoss 5 parsing of the deployment descriptor elements seems
to now include white-space characters into values.
My class looked like the following...
| @Stateless
| public class TellerEJB implements TellerLocal, TellerRemote {
| ...
| @Resource(name="daoClass")
| protected String daoClassName;
|
| @PostConstruct
| public void init() {
| log.debug("init(), daoClass=" + daoClassName);
| teller = new TellerImpl();
|
| try {
| AccountDAO dao = (AccountDAO)Thread.currentThread()
| .getContextClassLoader()
| .loadClass(daoClassName)
| .newInstance();
|
My deployment descriptor was written as follows
| ...
| <enterprise-beans>
| <session>
| <ejb-name>TellerEJB</ejb-name>
| <env-entry>
| <env-entry-name>daoClass</env-entry-name>
| <env-entry-type>java.lang.String</env-entry-type>
| <env-entry-value>xxx.jpa.JPAAccountDAO
| </env-entry-value>
| </env-entry>
| </session>
| </enterprise-beans>
| </ejb-jar>
|
Note the line break after ...DAO and the line break in the original debug output. Once I
removed the white-space from the deployment descriptor all worked.
| <enterprise-beans>
| <session>
| <ejb-name>TellerEJB</ejb-name>
| <env-entry>
| <env-entry-name>daoClass</env-entry-name>
| <env-entry-type>java.lang.String</env-entry-type>
| <env-entry-value>xxx.jpa.JPAAccountDAO</env-entry-value>
| </env-entry>
| </session>
| </enterprise-beans>
|
I've seen this same type of problem elsewhere in the processing of deployment
descriptors by JBoss 5. In one post I saw where adding export
JAVA_OPTS="-Dxb.builder.useUnorderedSequence=true" to the startup corrected the
issue. I have not yet tried that for this issue.
So, in short. I may be violating what you think is wrong with my use of
Thread.currentThread().getContextClassLoader(). However the problem in porting from JBoss
4 to JBoss 5 ended up being a whitespace interpretation change of the ejb-jar.xml between
the two versions. JBoss 5 is adding extra whitespace to the injected String variable.
Thoughts?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246592#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...