-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel,
On 5/27/16 4:53 AM, Daniel Rocha wrote: > The application that starts the servlets and initializes the > static objects:/home/project/lib/app.jar The tomcat temporary > folder "this.embedded.setBaseDir(getPath());" is located > under:/home/project/temp_tomcat/ The servlets are located > under:/home/project/webapps/servletname/ In the "servletname" > directory I have what the compiler (I am using Netbeans as the > IDE) generates under build/web directory. This means I have the > WEB-INF, META-INF and the web pages inside the directory. The > .class are inside the WEB-INF. > > Under the WEB-INF/lib of the servlets directory I have the > "app.jar" in each of them. > > So, I tried to do something and it worked. > > I put the "app.jar" inside the tomcat temporary folder > "/home/project/temp_tomcat/lib" (as a shared library) and I > deleted the "app.jar" from each servlet (WEB-INF/lib/app.jar) and > it worked. > > Can you please explain to me what really happened to start > working? Is there another way (some tomcat option) to do this > without having to put the "app.jar" inside the tomcat temporary > folder? You app.jar contains both the classes required to boot the enbedded system *and* the classes that run your web applications? If you have the web application classes referring to the "main app" classes (specifically, fetching a static value), then you will always have this problem. I recommend splitting your application into separate JAR files: one for the launcher and a second one for the web application. You might even want another one for the shared stuff. The launcher can live on its own, the shared-library can live in Tomcat's lib/ directory, and the webapp JAR can be in the WEB-INF/lib directory of the application. Any other layout will cause problems, unless you are okay with the application being one big JAR (app.jar) in Tomcat's lib/ directory. The reason for this is how Java defines classes at runtime. A (capital-C) Class is defined by the fully-qualified class name (e.g. foo.bar.MyClass) *plus* the ClassLoader that loaded it. So if you have a class available in different ClassLoaders (e.g. in both the webapp ClassLoader and the shared ClassLoader), then objects of those two Classes aren't always compatible with each other. The webapp ClassLoader is defined to perform a local-load *first*, then delegate to the parent. In the usual delegate-first class loading model, this issue wouldn't happen because the parent loader would always be preferred. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXSEy6AAoJEBzwKT+lPKRYa7MQAKbsGpfWP4lVUU0d16fFACi1 LCPj1Es9s/Z/i3bWvClyqIjzIgI8t016nLp7i444cXR2xl2rUgEy9KLbRryyV7qI 4H91dbb9Xvef/hYesq/T1FWK30VfkQAnQrDqdtoht9pKyYbXFhn8HUr+hBYIkxUb GOfT/Ge7zgekYBx+hhEtDzsXTFL0b/FGMDLAYAAq+qQbfjJEiFuA5iG4/3hrQAUa LtkmS1NDWoNSxyey4AijpomdCUrY1IrrloZayGQF+p/1Vi2Xq6gt6vEsheP+Go7M if7ub2SA47moIXUSRvPj73IK/88/OBbMbWxzA9WXkriH7fa5ZeDa1jJDrKzVk9Tx aPsqOcHrzc7RbkoJhOU9v8tXmdmTtlM+dWqpS/PPqxS/d7xWf+irzkKy+nWI1wau xWNgt7uT6TG0N/sdPC0fSBujwlyz8RRndVyVIKGHTvUr4lWK8ec8YidKdaimaJyy MmAGoZIgRUs1uP+bctBoIJN+PV+0AzXBdSu2Xqd4S5q6sfWMEM1f4p9Kg0ezewg8 puyHKdzctkdEdJDDE5oWLZh9j2lj66u9OcjgXbEF1pjMjQyfNZI2fkTzLArAqkeV JjDOJ0S6Avn4u1gEL8QmOLOZlnO18HI7bWBhsXUVDQZh+MAgtHFNlxkW5SXy4M5F CBUlKxFop9HdAwEfRDjq =vuj5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
