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#4246592
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246592
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
