WAR to WAB converter and JSPs

[Michael Freeman, modificado 6 Anos atrás.]

I am seeing a behavior from the JSP Analyzer that does not seem correct to me when converting legacy WAR apps to DXP through automated use of the WAR->WAB converter (i.e. drop the WAR in deploy directory)

When the analyzer sees a JSP including something like the following:

<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>

it (I think incorrectly) generates the following Require-Capability header in the generated WAB bundle:

osgi.extender; filter:="(&(osgi.extender=jsp.taglib)(uri=/WEB-INF/struts-tiles.tld))

While I understand that this JSP reference should probably be using a "true URI" the fact is that this kind of reference is fully legal for a JEE container and will work quite nicely at runtime if the subject TLD is in fact located at /WEB-INF/struts-tiles.tld. However this generated header causes OSGi deployment to fail ...

Is this a bug in the JSP Analyzer (i.e. should it be ignoring URIs that are relative (begin with '/')?

[David H Nebinger, modificado 6 Anos atrás.]

Did the WEB-INF/lib contain the struts/tiles taglib jar?









Come meet me at Devcon 2017 or 2017 LSNA!

[Michael Freeman, modificado 6 Anos atrás.]

Dave
Yes those TLDs are there. The problem here is that none of them expose a URI that begins with "/WEB-INF..." so the JspAnalyzer thinks it needs to generate a Require-Capability instruction for that

I think the fundamental problem here is that the JspAnalyzer needs to ignore any TLD references that are "relative path" style which by defintion need to be inside the WAR at runtime to work

[David H Nebinger, modificado 6 Anos atrás.]

Gotcha.

So switch to the standard non-local URI and you should be in business.










Come meet me at Devcon 2017 or 2017 LSNA!