| Anonymous | Login | Signup for a new account | 12-17-2024 08:55 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0001027 | [Resin] | major | always | 03-30-06 08:08 | 04-05-06 17:18 | ||||
| Reporter | gwagenknecht | View Status | public | ||||||
| Assigned To | ferg | ||||||||
| Priority | normal | Resolution | fixed | ||||||
| Status | closed | Product Version | 3.0.18 | ||||||
| Summary | 0001027: class-loader not working if defined inside web-app | ||||||||
| Description |
I'm developing an Eclipse plug-in that will start Resin using the WebApp right out of the Eclipse workspace. Thus, you don't have to publish anything and can edit files from within Eclipse without restarting Eclipse. Unfortunately, I was not able to register class-loader inside the web-app element of the main Resin configuration file. Resin fails starting the WebApp because it can't find any servlet class. But if I move the class-loader definitions up to the parent host element all classes can be found by Resin without any problem. |
||||||||
| Additional Information |
<!-- configures the default host, matching any host name --> <host id="" root-directory="."> <web-app id="/test" document-directory="D:\Development\workspaces\webapp-dev\test"> <!-- this does not work --> <class-loader> <simple-loader path="D:\Development\workspaces\webapp-dev\test\build\classes\"/> </class-loader> </web-app> <!-- this works fine --> <class-loader> <simple-loader path="D:\Development\workspaces\webapp-dev\test\build\classes\"/> </class-loader> </host> |
||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0000962) ferg 03-30-06 09:43 |
The problem is a bit tricky. Resin's configuration is parsed in order with the web-app-default applied before the final <web-app>. The resin:import for the web.xml and resin-web.xml are in app-default.xml, and are therefore applied before the <web-app> is processed. In other words, the web.xml is being processed before the <web-app>, so any servlet definition in the web.xml can't use the <class-loader>. |
|
(0000965) anonymous 03-30-06 10:10 |
But the host definition with the classloader comes after the resin:import for app-default.xml. Even if I move app-default.xml behind the final web-app I still get the class not found exception. |
|
(0000966) gwagenknecht 03-30-06 10:11 |
BTW I get the following exception when using Mantis at bugs.caucho.com 500 Servlet Exception com.caucho.quercus.QuercusRuntimeException: '/var/www/hosts/bugs.caucho.com/webapps/ROOT/lang/strings_.txt' is not a valid path at com.caucho.quercus.env.Env.errorException(Env.java:2527) at com.caucho.quercus.env.Env.include(Env.java:2304) at _quercus._core._lang_0api__php.fun_lang_load(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/lang_api.php:37) at _quercus._core._lang_0api__php.fun_lang_ensure_loaded(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/lang_api.php:126) at _quercus._core._lang_0api__php.fun_lang_get_defaulted(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/lang_api.php:250) at _quercus._core._lang_0api__php$8.eval(_lang_0api__php.java:345) at com.caucho.quercus.program.CompiledFunction_3.eval(CompiledFunction_3.java:104) at com.caucho.quercus.program.AbstractFunction.eval(AbstractFunction.java:228) at _quercus._core._email_0api__php.fun_email_bug_info_to_one_user(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/email_api.php:870) at _quercus._core._email_0api__php.fun_email_generic(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/email_api.php:450) at _quercus._core._email_0api__php.fun_email_bugnote_add(var/www/hosts/bugs.caucho.com/webapps/ROOT/core/email_api.php:483) at _quercus._core._email_0api__php$28.eval(_email_0api__php.java:1185) at com.caucho.quercus.program.CompiledFunction.evalRef(CompiledFunction.java:70) at _quercus._bugnote_0add__php.execute(var/www/hosts/bugs.caucho.com/webapps/ROOT/bugnote_add.php:47) at com.caucho.quercus.page.PhpPage.executeTop(PhpPage.java:124) at com.caucho.quercus.servlet.QuercusServlet.service(QuercusServlet.java:189) at javax.servlet.http.HttpServlet.service(HttpServlet.java:92) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:106) at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:268) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492) at com.caucho.util.ThreadPool.run(ThreadPool.java:425) at java.lang.Thread.run(Thread.java:595) |
|
(0000969) ferg 03-30-06 10:59 |
Ok, I oversimplified a bit. First, the <server> block is configured. <host> data is stored unconfigured (except for things like host-name). As a <host> is deployed, the <host-default> are applied in order, followed by the <host> definition. The <web-app> are stored unconfigured (except for the id). When a <web-app> is finally deployed, the <web-app-default> are applied in order, followed by the <web-app>. So the <web-app-default> are always applied before the <web-app>, even if the <web-app> tag is before the final <web-app-default>. The cleanest solution might be adding a <web-app-prologue id="/foo"> which is applied before the web-app-default. So the <web-app> tag could be viewed as <web-app-coda>. The order might look like: <web-app-prologue id="/foo"> <web-app-default> <resin:include path="WEB-INF/web.xml"/> <resin:include path="WEB-INF/resin-web.xml"/> </web-app-default> <web-app-default> <web-app-default> <web-app id="/foo"/> You could put the class-load configuration in the web-app-prologue. (The mantis issue is known. There are still a good number of bugs in Quercus.) |
|
(0000970) gwagenknecht 03-30-06 11:03 |
Thanks for the feedback. If that it the only way that this is usable workaround. But isn't it possible to delay the loading/resolving of servlet classes until the application config has been fully consumed and the environment is set up? |
|
(0000982) ferg 03-31-06 09:08 |
In theory, yes. In practice, though, Resin would also need to delay <listener>, <filter>, etc. and it would be somewhat more complicated to explain what classes are loaded at which times. For example, a <database> would always be loaded in the early phase. |
|
(0001008) gwagenknecht 04-04-06 10:20 |
But aren't people expecting that a webapp's classpath is setup completely before any attempt is made to load class form that webapp? |
|
(0001022) ferg 04-05-06 17:18 |
server/1h14 Added <prologue> to the <web-app>. The <prologue> configuration will be applied before any web-app-default. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 03-30-06 08:08 | gwagenknecht | New Issue | |
| 03-30-06 08:22 | gwagenknecht | Issue Monitored: gwagenknecht | |
| 03-30-06 09:43 | ferg | Note Added: 0000962 | |
| 03-30-06 10:10 | anonymous | Note Added: 0000965 | |
| 03-30-06 10:11 | gwagenknecht | Note Added: 0000966 | |
| 03-30-06 10:59 | ferg | Note Added: 0000969 | |
| 03-30-06 11:03 | gwagenknecht | Note Added: 0000970 | |
| 03-31-06 09:08 | ferg | Note Added: 0000982 | |
| 04-04-06 10:20 | gwagenknecht | Note Added: 0001008 | |
| 04-05-06 17:18 | ferg | Note Added: 0001022 | |
| 04-05-06 17:18 | ferg | Assigned To | => ferg |
| 04-05-06 17:18 | ferg | Status | new => closed |
| 04-05-06 17:18 | ferg | Resolution | open => fixed |
| 04-05-06 17:18 | ferg | Fixed in Version | => 3.0.19 |
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
44 total queries executed. 33 unique queries executed. |  |
