Community
Participate
Working Groups
The JSP 2.0 specification states that the contents of a web.xml file can affect the expected encoding of files in that web application, and then using wildcard filename specifiers so it's difficult to determine ahead of time. Currently either a content type describer has to determine the encoding based purely on the file contents or the platform can consult preferences. Without the ability to know the path of the resource being considered, I don't believe we can fully support the specification. I'm not sure if this is best solved by adding to the content describers or creating a different extension point altogether.
This bug also affects some Java EE tooling. For example, it would be impossible to define a content type for a struts-config.xml or a faces-config.xml file. This is because either file can have any filename and still be considered a struts-config.xml or a faces-config.xml file. This is because the struts-config.xml file is only really a StrutsConfigContentType when the file is referenced as an <init-param> of the web.xml file. A similar thing happens for faces-config.xml files. This problem could be solved if the IContentDescriber had access to the IResource of the file it was describing instead of just an InputStream. One additional requirement would be that the IContentType of a file can change based on resource changes happening to a file that isn't the one that's being described (in my situation, the web.xml file.) I.E. If you remove the applicable <init-param> from web.xml a previously valid StrutsConfigContentType for a file may no longer be true.
(In reply to comment #1) We could define API to programmatically add content types for files. If so, you could create a custom builder which would set dynamically content type for the file defined in web.xml.
Do you mean the builder would be storing a preference of content type for the files the same way IFile#setCharset(String, IProgressMonitor) is implemented?
(In reply to comment #3) > Do you mean the builder would be storing a preference of content type for the > files the same way IFile#setCharset(String, IProgressMonitor) is implemented? I was probably thinking about setting a content type for a file in the content type manager just for an Eclipse session.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
