tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
Date Mon, 05 Jan 2009 00:56:11 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084





--- Comment #13 from Konstantin Kolinko <knst.kolinko@gmail.com>  2009-01-04 16:56:09
PST ---
>From debugging the reproducer:

It appears that there are several (ca. 3) issues that pile up to produce this
effect.

Ignore my guesses about #getDependants() from comment 10. It is not related.
The proposed patch, though, may be useful.


1. First issue, the trigger:

When JspC is run with caching enabled (the default), the tag library
information, that is instances of TagLibraryInfoImpl class, is cached.

When TagLibraryInfoImpl instance is created, its constructor passes two pieces
of information to the JspCompilationContext that was used to create it.

That information is not passed if the instance is reused from the cache.

First is, ctxt.createCompiler().getPageInfo() call followed by
pageInfo.addDependant(location[0]).  -> See bug 46470 that it causes.

Second is ctxt.setTagFileJarUrl(path, jarFileUrl); call. It triggers this
issue.

When tagA.tagx is compiled (it is that tag inside a jar file) from inside of
tagB.tagx (it is the tag in WEB-INF/tags) in the reproducer, in
TagFileProcessor#loadTagFile() the following call:
ctxt.getTagFileJarUrl(tagFilePath)
for the tag file returns null.

Thus JspServletWrapper instance is created there with a null tagFileJarUrl
instead of the URL of the jar file.

(The tagFilePath argument in the ctxt.getTagFileJarUrl(tagFilePath) call is
just the path of the tag file. It does not include the name of the library ->
name collisions are expected -> bug 46471. It may have other cause, but the
concept is similar).

The TagFileProcessor#loadTagFile() method then proceeds and calls
JspServletWrapper.loadTagFile().

2. JspServletWrapper.loadTagFile() 

It calls ctxt.compile(); and ctxt.load();

The compile() method calls compiler.isOutDated() and skips compilation if that
method returns false.

In this case, because of invalid (null) tagFileJarUrl, the isOutDated() call
cannot find the source file and returns "false", because the source is not
found. The JspCompilationContext.compile() method silently returns without
compiling anything.
Is that by design? I think that it is.


Thus, compilation is skipped and we proceed to ctxt.load(). That method calls
getJspLoader(), but because compilation never occurred, the baseUrl field is
not initialized (null), and the method creates a misconfigured JasperLoader
instance.

An attempt to load a class from that JasperLoader instance results in the
NullPointerException that is observed.

Applying the patch, that I proposed earlier (attachment 23074) will result in
ClassNotFoundException been thrown instead, though there might be alternative
implementations that will achieve the same result.


Probably that NPE will occur also in some other situations, when isOutDated()
returns false due to missing source, but I have not yet tried to reproduce
that.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message