Morrison, John wrote: > Patched. Please check the version in cvs. There *must* be a better way...
How about defining the .jar locations in a configuration file accessible through getResource, perhaps also giving the user a possibility to explicitly define a directory outside the .war. Anyway, it has to be possible to use deployable archives across servlet containers, where the protocols returned by getResource can range from zip: to jndi:, even if the user is required to make some additional configurations. (: A ;) > >>-----Original Message----- >>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, 31 October 2001 4:28 pm >>To: [EMAIL PROTECTED] >>Subject: Re: classDirURL = jndi protocol?! >> >> >> >> >>"Morrison, John" a écrit : >> >>>>-----Original Message----- >>>>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] >>>>Sent: Wednesday, 31 October 2001 3:43 pm >>>>To: [EMAIL PROTECTED] >>>>Subject: Re: classDirURL = jndi protocol?! >>>> >>>> >>>> >>>> >>>>Carsten Ziegeler a écrit : >>>> >>>>>Hi John, >>>>> >>>>>first, you are not using the cocoon_20_branch. I changed only >>>>>the HEAD of the cvs. >>>>> >>>>>Now, the changes are required to get rid of the >>>>> >>getRealPath() calls >> >>>>>which will not work if you are using a war Cocoon as a >>>>> >>war file and >> >>>>>the servlet engine does not unpack it. >>>>> >>>>>As we can't use getRealPath(), we have problems with >>>>> >>building the >> >>>>>classpath anyway, as we can't scan the WEB-INF >>>>> >>directory anymore. >> >>>>>I currently see only two choices: >>>>>1) use getRealPath() and we won't run as a war file. >>>>>2) don't use getRealPath() and we can't use our own classloader. >>>>> And so Cocoon does not run in many servlet engines due to >>>>> class conflicts. >>>>> >>>>>I hope there is a third solution. We could of course do a >>>>> >>>>combination: >>>> >>>>>a) Test if getRealPath() can be used and then create our >>>>> >>>>own classloader >>>> >>>>>b) if getRealPath() is not working we hope that the >>>>> >>servlet engine >> >>>>> does not cause any class conflicts. >>>>> >>>>>So any suggestions are welcome. >>>>> >>>>>Carsten >>>>> >>>>> >>>>This is a complex problem, and I'm afraid there's no >>>>universal solution >>>>:( >>>> >>>>We cannot assume getResource() returns a "file:" URL, even if the >>>>resource is actually one. With a directory context in >>>> >>Tomcat 4 (not a >> >>>>war file), getResource("/WEB-INF/classes") returns >>>>"jndi:/localhost/cocoon/WEB-INF/classes" which obviously >>>>isn't a "file:" >>>>URL, while getRealPath("/WEB-INF/classes") returns >>>>"/path-to-webapps/cocoon/WEB-INF/classes", which is what we want. >>>> >>>>So, we should use getRealPath() where a filename is needed >>>>(i.e. a name >>>>in the file system), and getResource() everywhere else. >>>> >>>>The main (only ?) place where filenames are required is for >>>>building the >>>>classpath used by javac for sitemap/xsp compilation, since >>>>javac doesn't >>>>use the current classloader, but the classpath given on >>>> >>the command >> >>>>line. So this area *must* use getRealPath(). >>>> >>>>If getRealPath() returns null because of a non-expanded >>>> >>war file, I'm >> >>>>afraid there is no way to build a valid classpath. IIRC, >>>> >>there used to >> >>>>be in the past some additional tests in CocoonServlet for >>>>container-specific attributes in the ServletContext giving >>>>the classpath >>>>used for JSP compilation. This is the only fallback whe have >>>>to get the >>>>classpath in that case. >>>> >>>So; should I put the code back to how it was prior to the >>> >>getRealPath -> >> >>>getResource conversion or add tests for >>> >>"if(servletContextPath != null)" and >> >>>make the decision based on that? >>> >>>Can't we use the jndi protocol to get at the jar files? >>> >>> >>No, because we want to be able to list the contents of a directory. We >>should switch back to getRealPath() all classpath stuff in >>CocoonServlet. >> >> >>-- >>Sylvain Wallez >>Anyware Technologies - http://www.anyware-tech.com >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, email: [EMAIL PROTECTED] >> >> > > > ======================================================================= > Information in this email and any attachments are confidential, and may > not be copied or used by anyone other than the addressee, nor disclosed > to any third party without our permission. There is no intention to > create any legally binding contract or other commitment through the use > of this email. > > Experian Limited (registration number 653331). > Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
