cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <anryo...@users.sourceforge.net>
Subject Re: classDirURL = jndi protocol?!
Date Thu, 01 Nov 2001 13:23:08 GMT
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:sylvain.wallez@anyware-tech.com]
>>Sent: Wednesday, 31 October 2001 4:28 pm
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: classDirURL = jndi protocol?!
>>
>>
>>
>>
>>"Morrison, John" a écrit :
>>
>>>>-----Original Message-----
>>>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>>>Sent: Wednesday, 31 October 2001 3:43 pm
>>>>To: cocoon-dev@xml.apache.org
>>>>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: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
> 
> 
> =======================================================================
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message