[jboss-user] [EJB/JBoss] - Re: PostConstruct loadClass fails when porting to JBoss 5
Andrew, * Thanks for the specifics on why the handling of deployment descriptor whitespace changed. Yes, with a more-compliant application server schema, I was adding the extra whitespace - point taken. * We are all set on the reading of a read-only resource. * Tom Marrs wrote about 3 classloaders; system, current, and thread. He ruled out use of the first 2 for known reasons and then stated why you should use the later. This is what my code is doing; access the classloader through the current Thread. anonymous wrote : | You gain access to the current Thread Context ClassLoader by calling Thread.currentThread().getContextClassLoader(). ... Use the Thread Context Class Loader for the following reasons: | * On the use of the reflection API and ClassLoader, the listed restrictions state that what I wanted to do with the ClassLoader was legal anonymous wrote : | Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example, loadClass() and invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden. | Thanks for taking the time on this. jim View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4246717#4246717 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4246717 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - Re: PostConstruct loadClass fails when porting to JBoss 5
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-nameTellerEJB/ejb-name
| env-entry
| env-entry-namedaoClass/env-entry-name
| env-entry-typejava.lang.String/env-entry-type
| env-entry-valuexxx.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-nameTellerEJB/ejb-name
| env-entry
| env-entry-namedaoClass/env-entry-name
| env-entry-typejava.lang.String/env-entry-type
| env-entry-valuexxx.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=bbop=viewtopicp=4246592#4246592
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4246592
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - Re: PostConstruct loadClass fails when porting to JBoss 5
Thank you for the reference to the specific spec requirement that explains why this is allowed to not to work. The legacy code was from a time (EJB 2.x) when dependency injection was more limited, and it may have advanced to the point that we can inject the POJO class dynamically in other ways. However... If obtaining the current classloader is illegal/non-portable, how does one read in a data file from the EJB's classpath? Is there a legal classloader we can access that will have the file Resource that can be read in as a stream? We can come up with ways to get around obtaining the classloader to dynamically load a class, but I don't currently know of a way to avoid getting the classloader for reading on streams/files. thanks, jim View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4246296#4246296 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4246296 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
