I did a little digging and it appears to be a limitation of Sun's compiler. It's embedded form is invoked identically to the command line so all arguments must be passed as strings. This essentially means the logical classpath from the classloaders needs to be convertible to a delimited string. As Costin says, it is probably safest to assume all entries must be local paths as in java.class.path (see http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/classpath.html).
I'll open a bug against JBossWeb so we can track this. I think it could be tied to the DeploymentCache so that any web-based archive can be downloaded on demand and aged out when no longer required. I'd suggest requiring all non-J2SE/Servlet classes be included within the war anyway. It makes the war a standalone unit and would allow, for example, the JSPs to be pre-compiled prior to deployment. It also means the same war would work netbooted or not - the requirements are just a little stricter in general. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Thursday, December 19, 2002 6:02 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Committed support for remote deployment > scanning > > > 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 ------------------------------------------------------- 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
