> Il giorno 3 giu 2021, alle ore 20:01, Mark Thomas <ma...@apache.org> ha
> scritto:
>
> On 03/06/2021 18:56, Pietro Braione wrote:
>>> Il giorno 31 mag 2021, alle ore 20:58, Konstantin Kolinko
>>> <knst.koli...@gmail.com> ha scritto:
>>>
>>> Citing from the NOTICE file:
>>>
>>> Java compilation software for JSP pages is provided by the Eclipse
>>> JDT Core Batch Compiler component, which is open source software.
>> Hello Konstantin, and thank you for the answer. I noticed the ecj jar in the
>> lib directory so I kind of guessed that ecj was used as a compiler. What I
>> am looking for is the Tomcat code that invokes ecj, so I can get the exact
>> ecj invocation parameters and reproduce from the command line what Tomcat
>> does. I also conjecture that, after compilation of the .java file, some kind
>> of bytecode manipulation is performed on the resulting class file, e.g., to
>> inject JSP-specific debug information as SourceDebugExtension attributes. So
>> I want to read the code and see whether this is true, in the case I need to
>> pinpoint whether the problem is in ecj or in the (possible) subsequent
>> bytecode manipulation routines.
>
> Have you tried searching the Tomcat source code for references to "jdt"?
>
> Github provides a handy on-line search so you don't even need to clone the
> repo.
>
Hello Mark, and thank you for the advice. I didn’t consider this option
probably because I usually have a rather meh experience with GitHub search, but
I was actually able to spot the incriminated code rather quickly. It turns out
that Tomcat uses the classloader context instead of a classpath string, so
before digging deeper in the code I tried putting all the jars in the lib path
in the ecj classpath. It turns out that the blame is on ecj. I will file a bug
report to the Eclipse project. I also gave a quick look at the code that
manipulates the classfile to add the SourceDebugExtension attribute
(org.apache.jasper.compiler.SmapUtil.SDEInstaller) but it doesn’t seem to touch
the attributes emitted by the compiler.
Best,
Pietro
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
