> 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.
If WEB-INF/lib contains cayenne-server.jar, both PasswordReset.class and
DefaultAdhocObjectFactory.class will be loaded with the same ClassLoader and
the problem should not occur. So maybe check if cayenne-server.jar is also
exists in the shared container ClassLoader.
Andrus
On Jul 31, 2013, at 7:50 PM, Andrew Willerding <awillerd...@itsurcom.com> wrote:
> 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.
>
>
