Thanks Jeff for your reply.
The custom classloader cannot be avoided :(
Yes as you have suggested, I have tried the setDefaultClassLoader
approach and it worked fine.
But as I have asked in my previous email, why is the classloader that
is used to load the resources.java is not used as the defaultLoader
before using the Thread.contextClassLoader.
Thanks,
Ravi
Jeff Butler wrote:
Simple solution - get rid of the custom classloader. The custom
classloader is likely to end up introducing hidden application server
dependencies into your code - because it is not safe to assume that all
application servers structure their classloaders the same way.
If there is some compelling reason to have a custom classloader
(do tell), then maybe this would help:
Resources.setDefaultClassLoader(yourCustomClassloader)
Jeff Butler
On 10/24/05, Ravi Krishnamurthy <[EMAIL PROTECTED]> wrote:
Hello:
I have a custom classloader that has the ejbclassloader as the parent.
The custom classloader loads all the ibatis classes but the thread
context classloader is the ejbclassloader. So when the ibatis is trying
to load the resource, I get resource not found for the sql...dtd files.
On lookig at the source code looks like in the Resources.java of
ibatis,
the getClassLoader first check the default Classloader and then the
Thread.contextClassloader. Looks like in my case, the defaultClassLoader
is null and so the context classloader (ejbclassloader) is used to
search for the resources and so things file.
Could someone give me some pointers on how to resolve this problem.
But wondering why the getClassLoader does not use the classloader that
loaded the Resources.java to search for the resources.
Please note that the ibatis classes are only visible to the
cutomclassloader and not to the ejbclassloader.
Thanks for your time,
Regards,
Ravi
|
