Well, first, JBossWebApplicationContext is Jetty specific and I thought there was similar functionality in the in the AbstractWebContainer. This is where this logic needs to be.
Second, this code needs to copy non-file URLs down so that they can be passed to the jsp compiler. Its the web container/jsp integration layer that needs this so its this layer that has to deal with the problem, if in fact it is a problem. The question is why are the non-file URLs being stripped? Based on Costin's response it sounds like this may no longer be valid for the version of japser being used in main. Let's find this out first. We can't have different packing requirements depending on whether or not we are netbooting. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 19, 2002 2:38 PM Subject: RE: [JBoss-dev] Committed support for remote deployment scanning > The classloading model works fine - the issue is with how the classpath is > passed to the JSP compiler. > > As I understand it, not being familiar with Jetty/Jasper, Jasper uses an Ant > Javac task to compile the Java source generated from the JSP. The classpath > supplied to the Javac task is a ':' (path.separator) delimited String. This > String is generated by iterating over the context classloaders and > concatenating all their URLs together (see > JBossWebApplicationContext.getFileClassPath() and > JspRuntimeContext.initClassPath()). Any URLs that are not file: are > discarded as they cannot be converted to a local canonical path. > > Boot libraries are not copied to the local machine first so have URLs based > on HOME_URL. Libraries loaded later are copied locally so have URLs relative > to SERVER_BASE_DIR. Basically boot libraries will have file: or http: URLs > depending on where the server was booted from; all others will have file: > URLs due to the local copy. > > As a result boot libraries, even though they are in the thread's > classloader, are not passed to the JSP compiler because non-file: URLs are > stripped. > > I think the solution here is to pass everything in the classloader chain to > the JSP compiler to ensure that the compilation context will be the same as > the runtime context. I believe concatenating everything together, stripping > non-file: URLs in the process, and then splitting it apart later is asking > for trouble in the long (or maybe short) term. However, I don't know enough > about Jetty/Jasper to know if there are issues with this. > > An alternative would be for ServerLoader to copy everything local during > boot, but that leaves the problem of non-file URLs lurking (for example, if > we decide at some point not to copy everything local every time). It also > makes netboot more 'install-on-demand' rather than 'boot-from-network' but > that's just me being anal :-) ------------------------------------------------------- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
