>
>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.
Absolutely agree with it. One day you'll need to install your Cocoon
application an exotic application server (like IONA iPortal 3.0, that I am
fighting with) and you'll meet a lot of problems if you make a step away
from the specification. According to the Servlet 2.2 Specification the only
access to your application context resources (and more over - any resource)
must be performed through the getResource() call. getRealPath() can return
'null' also by the specification.
I think, that this can be fixed and must be fixed before release, because
this issue is against specification. I'd would do it myself, but I'm afraid
that I'm not much expert in C2 internals.
Regards,
Konstantin Piroumian
>
>(: 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]
