Taglibs - correct location of TLD files packaged in JARs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Taglibs - correct location of TLD files packaged in JARs

Tomas Hofman
Hi folks,

we have an issue [0] where a web app with JAR packaged taglib is migrated from
Tomcat to Wildfly/EAP and the two servers are resolving tablib location
differently.

The taglib file in the JAR is located in
META-INF/resources/WEB-INF/tlds/hi.tld.

It's added to the taglib map explicitly via <taglib> element in
web-fragment.xml (in the same JAR):

         <taglib>
             <taglib-uri>/HiTag</taglib-uri>
             <taglib-location>/WEB-INF/tlds/hi.tld</taglib-location>
         </taglib>

This works in Tomcat, which takes *META-INF/resources/* as the root for
resolving <taglib-location>, and doesn't work in Wildfly, which takes
*META-INF/* as the root.

The functionality is described by JSP SPEC section 7.3 (I don't want to quote
any parts here, because I would have to quote all of it) [1]. After going
through it I think our interpretation is the correct one, though Apache think
the contrary [2].

However, would it hurt if we added META-INF/resources/ as another root to allow
both options?


[0] The issue: https://issues.jboss.org/browse/JBEAP-14757
[1] JSP spec: http://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/
[2] I wrote to Apache mailing list and Jeremy Boynes replied:

"""
Here’s how I read the spec.

JSP 7.3.3 talks about a “taglib map” using elements in the deployment
descriptor per your example. Per JSP 7.3.2 the URI is mapped to a context
relative path interpreted relative to the root of the web application.
Resources contained in a web fragment jar are located in its
/META-INF/resources directory. Tomcat/Jasper are synthesizing the effective web
application from the resources in the fragments, then resolving the URI in the
taglib map against that merged application. I think that’s a correct
interpretation of the spec.

JSP 7.3.1 refers to implicit map entries found by scanning the web
application’s jars from WEB-INF/lib.
"""

http://mail-archives.apache.org/mod_mbox/tomcat-taglibs-user/201805.mbox/%3C4E3C404C-1D9F-4292-BE77-C443C3C61671%40apache.org%3E


--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Taglibs - correct location of TLD files packaged in JARs

Tomas Hofman
Adding back the list...

So unless anyone posts any objections I will prepare a PR to that effect.

Thanks!

On 12/06/18 16:12, Remy Maucherat wrote:

> On Tue, Jun 12, 2018 at 4:06 PM, Tomas Hofman <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello Remy,
>
>     just to explain, Jean Clere mentioned you might have an opinion on this,
>     which is why I included you directly. Feel free to ignore this if you think
>     this is more for other people.
>
>
> Right now I think this is a grey area, and both ways sound reasonably
> legitimate until there's a real clarification.
>
> Rémy
>
>
>     Tomas
>
>
>     On 12/06/18 15:58, Tomas Hofman wrote:
>
>         Hi folks,
>
>         we have an issue [0] where a web app with JAR packaged taglib is
>         migrated from
>         Tomcat to Wildfly/EAP and the two servers are resolving tablib location
>         differently.
>
>         The taglib file in the JAR is located in
>         META-INF/resources/WEB-INF/tlds/hi.tld.
>
>         It's added to the taglib map explicitly via <taglib> element in
>         web-fragment.xml (in the same JAR):
>
>                    <taglib>
>                        <taglib-uri>/HiTag</taglib-uri>
>                        <taglib-location>/WEB-INF/tlds/hi.tld</taglib-location>
>                    </taglib>
>
>         This works in Tomcat, which takes *META-INF/resources/* as the root for
>         resolving <taglib-location>, and doesn't work in Wildfly, which takes
>         *META-INF/* as the root.
>
>         The functionality is described by JSP SPEC section 7.3 (I don't want to
>         quote
>         any parts here, because I would have to quote all of it) [1]. After going
>         through it I think our interpretation is the correct one, though Apache
>         think
>         the contrary [2].
>
>         However, would it hurt if we added META-INF/resources/ as another root
>         to allow
>         both options?
>
>
>         [0] The issue: https://issues.jboss.org/browse/JBEAP-14757
>         <https://issues.jboss.org/browse/JBEAP-14757>
>         [1] JSP spec:
>         http://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/
>         <http://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/>
>         [2] I wrote to Apache mailing list and Jeremy Boynes replied:
>
>         """
>         Here’s how I read the spec.
>
>         JSP 7.3.3 talks about a “taglib map” using elements in the deployment
>         descriptor per your example. Per JSP 7.3.2 the URI is mapped to a context
>         relative path interpreted relative to the root of the web application.
>         Resources contained in a web fragment jar are located in its
>         /META-INF/resources directory. Tomcat/Jasper are synthesizing the
>         effective web
>         application from the resources in the fragments, then resolving the URI
>         in the
>         taglib map against that merged application. I think that’s a correct
>         interpretation of the spec.
>
>         JSP 7.3.1 refers to implicit map entries found by scanning the web
>         application’s jars from WEB-INF/lib.
>         """
>
>         http://mail-archives.apache.org/mod_mbox/tomcat-taglibs-user/201805.mbox/%3C4E3C404C-1D9F-4292-BE77-C443C3C61671%40apache.org%3E
>         <http://mail-archives.apache.org/mod_mbox/tomcat-taglibs-user/201805.mbox/%3C4E3C404C-1D9F-4292-BE77-C443C3C61671%40apache.org%3E>
>
>
>
>     --
>     Tomas Hofman
>     Software Engineer, JBoss SET
>     Red Hat
>
>

--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev