You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes, for instance when a JSP was (manually) modified, the following error arises during JSP compilation:
File "tld:http://www.neba.io/core/1.0" not found
However, the tag library shows up in Sling's "JSP taglibs" status console: /system/console/status-jsptaglibs. This very likely related to Felix issues regarding fragment bundles.
As a workaround, the tag libraries could be moved to the API bundle and the dependencies to the core could be modeled as an OSGi service dependency, with the service interface provided by the API.
The text was updated successfully, but these errors were encountered:
With NEBA 3.1.0 this issue appeared after every reinstallation of my application package. I needed to rest AEM every time to fix this. Also refreshing or stopping/starting any bundle did not work.
With NEBA 3.2.0-SNAPSHOT (locally compiled today), the issue always appears, even after an AEM restart!
Caused by: org.apache.sling.scripting.jsp.jasper.JasperException: /apps/poll/templates/pollPage/body.jsp(1,1) The absolute uri: http://www.neba.io/core/1.0 cannot be resolved in either web.xml or the jar files deployed with this application
Btw, if you move the tld to api, you should also change the uri from .../core/1.0 to .../api/1.0, don't you think?
Could you provide more details on your test scenario, i.e. AEM version / JDK etc? I cannot reproduce this issue with AEM 5.6.1 & JDK 1.7. I have tried this with two differenc customer projects, like so:
a) Uninstall and delete the precious NEBA package
b) restart the instance to make sure there are no classloading issues later on (Felix...)
c) install the 3.2 snapshot package and start the project bundles
d) delete /var/classes to force re-compilation of JSPs against the taglib change
Subsequently, I could no longer get the issue to occur - I've both modified single JSPs directly on the instance and re-deployed template packages. Both worked fine.
Sometimes, for instance when a JSP was (manually) modified, the following error arises during JSP compilation:
However, the tag library shows up in Sling's "JSP taglibs" status console: /system/console/status-jsptaglibs. This very likely related to Felix issues regarding fragment bundles.
As a workaround, the tag libraries could be moved to the API bundle and the dependencies to the core could be modeled as an OSGi service dependency, with the service interface provided by the API.
The text was updated successfully, but these errors were encountered: