Mark,
I understand the IDE use case, but I'm not sure that
WEB-INF/classes/META-INF/resources should be supported by the spec.
While I would very much like it that we could establish exactly the same
behaviour
for any jar from WEB-INF/lib when it is expanded into WEB-INF/classes, I
don't think
that is actually possible, at least not for the general case of N jars.
Specifically anything that uses web.xml fragments, service discovery,
manifest data, or any other name clashes is going to have problems.
I think the upside is small (and already covered by various development
modes) and the potential down side is large.
cheers
On 23 January 2015 at 10:27, Mark Thomas <markt_at_apache.org> wrote:
> 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
> >>
>
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.