On 31/07/2013 11:14 AM, Andrus Adamchik wrote:
Here is the code for DefaultAdhocObjectFactory that is the cluprit:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
classLoader = DefaultAdhocObjectFactory.class.getClassLoader();
}
try {
// fails here
return Class.forName(className, true, classLoader);
}
Looks like the PasswordReset.class is coming from some unexpected ClassLoader.
I don't have firsthand experience with Atmosphere deployments (on Tomcat or
otherwise), so not sure what happens there ClassLoader-wise. So a random
question - do you keep Cayenne jar in the same war as your PasswordReset.class?
Or if you are not using a .war, how is your deployed app structured?
Andrus
The result is the same whether I run the project from within Netbeans or
I use Netbeans to generate a war file and run it as a Tomcat webapp. I
think the answer is that Netbeans pretty much follows conventions. it
looks like this:
WEB-INF/classes - contains the classes generated from the application
including what looks like a bunch of tomcat jar files in the root of the
folder.
WEB-INF/lib - contains the necessary .jar files used to compile the
project and that I have added for the project and it appears pretty much
a copy of everything that is in the classes root folder except the
application classes.
What is really strange now is that I have been using my linux
workstation to do my work and report this issue I'm experiencing and I'm
currently out of the office so I've switched to my Windows laptop and
tried to run the same project and IT WORKS! I do not get the same
error. Until now I have not tried to run it from my laptop before.
Maybe my Netbeans setup on my linux workstation is hosed somehow. I
will reinstall it from scratch and see if that helps out. I won't be
able to do this until tomorrow. The only differences on the Windows
laptop are jdk1.7.0.21 and Tomcat 7.0.34. Netbeans is the same version
and my application code is exactly the same.
