Fix and simplify handling of JSPParser classloader #7567
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matthiasblaesing
force-pushed
the
fix_jsp_parser2
branch
from
2937997 to
c7e9bad
Compare
mbien
reviewed
Jul 12, 2024
- J2EE DD API bundled javaee-api-5.jar, which seems to be unused apart from an unused import in ResourceImpl. javaee-api-5.jar can only be used to compile against, but fails usage at runtime (it does not contain the code), so is assumed to be actually be unused. The bundled javaee-api-5.jar was pulled onto the classpath when the module was in the dependencies and the missing code parts caused class loading error, which are fixed by the removal. - The web.jspparser project uses multiple demo project to check loading two were partially donated, one was not (project3). Tests relying on the removed project were removed. The other two projects were fixable replacing the missing components with fresh downloads from maven central and a pseudo tag jar build at compile time. - One test relyed on a special VM and was not executed, but did not report that.
matthiasblaesing
force-pushed
the
fix_jsp_parser2
branch
from
c7e9bad to
9bc1b7e
Compare
lkishalmi
approved these changes
Jul 14, 2024
Contributor
lkishalmi
left a comment
lkishalmi
left a comment
There was a problem hiding this comment.
Just looked through the changes, have not tested it.
If this works it seems to be fine.
| return true; | ||
| } | ||
| return false; | ||
| return JspParserAPI.TAG_MIME_TYPE.equals(fo.getMIMEType()); |
Contributor
There was a problem hiding this comment.
Could tally with the previous fo.getExt condition.
The classloader was reset after each invocation by calls to resetClassLoaders, so there is already little caching present here. The old behavior though posed a different problem: the classloaders were shared into multiple threads and calls to resetClassLoaders were not coordinated, so the "slower" thread could be faced with a closed classloader. For an URLClassLoader this means, that classes already loaded work, new classes can't be loaded. This leads to difficult to debug situations. At runtime this was observed as: Unable to read TLD "META-INF/liferay-portlet-ext.tld" from JAR file "file:/home/matthias/.m2/repository/com/liferay/portal/release.portal.api/7.4.3.94-ga94/release.portal.api-7.4.3.94-ga94.jar": org.apache.jasper.JasperException: PWC6112: Failed to load or instantiate TagExtraInfo class: com.liferay.taglib.portlet.ActionURLTei
matthiasblaesing
force-pushed
the
fix_jsp_parser2
branch
from
9bc1b7e to
bf66058
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The classloader was reset after each invocation by calls to
resetClassLoaders, so there is already little caching present here.The old behavior though posed a different problem: the classloaders were shared into multiple threads and calls to
resetClassLoaderswere not coordinated, so the "slower" thread could be faced with a closed classloader. For anURLClassLoaderthis means, that classes already loaded work, new classes can't be loaded. This leads to difficult to debug situations.At runtime this was observed as:
Leading to errors reported in JSPs.