I got stuck trying to figure why a URLsource was coming back and just ended up disabling the code. I suspect that JBoss must wrap the EAR file in some way so that request to read the files contained within it can be returned to the servlet container (Tomcat in our case).
Running Cocoon under JBoss is pretty easy; install one of the combined JBboss/Tomcat packages off the web site, make a WAR or EAR out of Cocoon, drop it into the deploy directory and away it goes... I'll try doing some more debugging but the code is pretty opaque from my perspective and I don't have a lot of time to look at the problem. > -----Original Message----- > From: Christopher Oliver [mailto:[EMAIL PROTECTED] > Sent: Friday, April 23, 2004 10:49 AM > To: [EMAIL PROTECTED] > Subject: Re: [RT] Use of flowscript or the pyramid of > contracts (was Re:[RT] Checked exceptions considered harmful) > > > There's not enough information in that bug report to determine the > problem. Can you try to debug why a URLSource (with exists() > == true) is > being returned by the source resolver for the (presumably > nonexistent) > resource "org.java"? > > I had no luck debugging this since I can't recreate the > problem (I don't > use JBoss) and because I have no idea where to find the > source code for > the classes in excalibur-sourceresolve-1.1.jar. Anyone know > where that > is? I browsed the avalon cvs but couldn't find it. > > Regards, > > Chris > > Hunsberger, Peter wrote: > > >Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > > ><snip/> > > > > > >>Now we made it easier to write flowscript than to write > >>components, now > >>we have to focus on making it easier to write components than > >>flowscript. > >> > >>How? > >> > >>Chris' magic compiler classloader is the way to go, IMHO. > >> > >> > > > >If so, then it's going to have to work in all environments. > It's still > >broken when deploying as an EAR under JBoss: > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484 > > > > > > > > > > > > > > >
