On 23/01/2015 06:44, Shing Wai Chan wrote:
> If we don't allow META-INF/resources/WEB-INF/classes, then
> should we disallow WEB-INF/classes/META-INF/resources?
>
> I ask this as I see the following issue
> https://java.net/jira/browse/SERVLET_SPEC-22
Oddly enough I think that should be allowed. :)
There is a genuine use case for this - folks working with IDEs - and if
we blocked this it would make life difficult for those users and
generate work for the IDE developers to work around - all for no good
reason I can see.
Whether we include this in the spec (I don't see the harm) or whether we
leave up to container developers is TBD. It would make things easier for
the IDE developers if all containers implemented this the same way.
Mark
>
> Regards,
> Shing Wai Chan
>
> On 1/22/15, 9:30 AM, Mark Thomas wrote:
>> On 22/01/2015 16:07, Greg Wilkins wrote:
>>> Hi,
>>>
>>> we've had a jetty user question that came up that we thought we new the
>>> answer for sure.
>>>
>>> They have a jar file which contains a META-INF/resources directory in
>>> which they have a WEB-INF/classes directory.
>>>
>>> Our understanding of META-INF/resources is that it is only for static
>>> content that can be obtained via getResource and that it is not a place
>>> where you can put things like WEB-INF/classes and expect them to appear
>>> on the context classpath.
>> Agreed completely.
>>
>>> Our thinking is that if you allow META-INF/resources/WEB-INF/classes,
>>> then surely you would have to allow META-INF/resources/WEB-INF/lib,
>>> which could then contain jars that contain
>>> META-INF/resources/WEB-INF/lib, which contain jars that contain.... and
>>> it is turtles all the way down.
>> Indeed.
>>
>>> We were pretty sure this is correct, but have been told that tomcat at
>>> least is putting META-INF/resources/WEB-INF/classes on the contexts
>>> classpath.
>> Hmm. I was going to say "no way" but I guess it is possible this is
>> happening accidentally. I'll check and I'll be blocking it if it is.
>>
>> What Tomcat has added is a non-specification compliant extension that is
>> disabled by default that will look for WEB-INF/classes/META-INF and
>> treat that as if it were from a JAR. The use case is IDEs that unpack
>> JARs in to WEB-INF/classes rather than keeping them as JARs in
>> WEB-INF/lib. The extension enables the application to get at the static
>> resources that would have been in the JAR had the IDE not unpacked it.
>>
>> You could, if you really wanted to, configure Tomcat to map a
>> META-INF/resources/WEB-INF/classes resources dir in a JAR to
>> WEB-INF/classes in the web application but again that would be extra,
>> Tomcat specific configuration.
>>
>>> We can't see anything in the spec that suggests that
>>> META-INF/resources/WEB-INF should be scanned for classpath components.
>> Agreed. The spec could be a little clearer but the intent is certainly
>> clear. META-INF/resources is only for static content.
>>
>>> You can see the original question and our response
>>> here:https://stackoverflow.com/questions/28078902/jetty-8-can-a-web-fragment-jars-meta-inf-resources-web-inf-classes-directory/
>>>
>>>
>>> So I think we need to clarify the spec on this point one way or the
>>> other.
>> +1. The text referencing static reosurces in A.3 of the 3.1 spec should
>> really be in the main body of the spec.
>>
>> I'll get back to you shortly on Tomcat's current behaviour.
>>
>> Mark
>>