Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Romain Manni-Bucau]

Hmm, for me you have 3 modes:

1. Plain vm -> we dont care
2. Native image generator (
https://github.com/oracle/graal/blob/901ad5cf25d145909d1eca36cbb86765697dcc0b/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/NativeImageGenerator.java#L506
so it is set)
3. Native run -> substitution works

Optional case 4 is the javaagent but this one is not needed normally for
tomcat or is a dev thing so does not need to be implicit (we can set the
property if still used but i suspect once a first flavor is generated it is
no more used and just integrated in tomcat then updated manually).

Do I miss something?

Le jeu. 23 juil. 2020 à 03:02, Filip Hanik  a écrit :

> Hi Romain,
>
> > -Original Message-
> > From: Romain Manni-Bucau 
> > Sent: Wednesday, July 22, 2020 12:48 PM
> > To: Tomcat Developers List 
> > Subject: Re: [tomcat] branch master updated: Simpler way to determine
> Graal
> > runtime
> >
> > Thinking out loud: cant you substitute it to be hardcoded to true in
> native
> > mode? This way you get the best of both.
>
> This works for when you compile it to native code. Remy was talking about
> when running under the Substrate VM as a Java application. That's when I
> experience test failures and prompted me to look into a change.
> If I understand it correctly, the substrate VM doesn't pick up those
> substitutions when running in Java mode.
>
> Filip
>
> >
> > Le mer. 22 juil. 2020 à 20:17, Filip Hanik  >  > a écrit :
> >
> >
> >   Thanks Remy,
> >
> >
> >
> >   I ran into some failures when running the test suite using the
> substrate
> > VM, but it makes more sense to adjust those tests.
> >
> >   I’ll revert these today
> >
> >
> >
> >   Filip
> >
> >
> >
> >   From: Rémy Maucherat  >  >
> > Sent: Wednesday, July 22, 2020 12:10 AM
> >   To: Tomcat Developers List  >  >
> >   Subject: Re: [tomcat] branch master updated: Simpler way to
> > determine Graal runtime
> >
> >
> >
> >   On Tue, Jul 21, 2020 at 11:16 PM  >  > wrote:
> >
> >   This is an automated email from the ASF dual-hosted git
> > repository.
> >
> >   fhanik pushed a commit to branch master
> >   in repository
> > https://gitbox.apache.org/repos/asf/tomcat.git
> >  > o
> > x.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40v
> > mware.c
> > om%7C5bb8217a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6c
> > d83d9dd62f0
> > %7C0%7C0%7C637310444856257107&sdata=T20lk9hPTLaJGtrD5ZLD3OVzkC
> > amedtpcKo2
> > V4MwXtg%3D&reserved=0>
> >
> >
> >   The following commit(s) were added to refs/heads/master by
> > this push:
> >new 098c4c8  Simpler way to determine Graal runtime
> >   098c4c8 is described below
> >
> >   commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> >   Author: Filip Hanik  >  >
> >   AuthorDate: Tue Jul 21 14:04:57 2020 -0700
> >
> >   Simpler way to determine Graal runtime
> >
> >   Also, allows to mock the behavior
> >
> > https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.h
> > t
> > ml#PROPERTY_IMAGE_CODE_KEY
> >  > w.g
> > raalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageI
> > nfo.htm
> > l%23PROPERTY_IMAGE_CODE_KEY&data=02%7C01%7Cfhanik%40vmware.co
> > m%7C5bb8217
> > a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7
> > C0%7C0%7C6
> > 37310444856267104&sdata=vHbmuRW5YP1%2B2a6romOsuaxaUHqMqF9G4
> > ob7aXlSYbY%3D
> > &reserved=0>
> >   ---
> >java/org/apache/jasper/runtime/JspRuntimeLibrary.java |
> > 16 +---
> >java/org/apache/naming/NamingContext.java |
> > 15 +--
> >java/org/apache/tomcat/util/compat/GraalCompat.java   |
> > 15 +--
> >3 files changed, 3 insertions(+), 43 deletions(-)
> >
> >   diff --git
> > a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> > b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   index cfb6e75..f27ce3b 100644
> >   ---
> > a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   +++
> > b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   @@ -56,21 +56,7 @@ import
> > org.apache.tomcat.InstanceManager;
> > */
> >public class JspRuntimeLibrary {
> >
> >   -public static final boolean GRAAL;
> >   -
> >   -static {
> >   -boolean result = false;
> >   -try {
> >   -Class nativeImageClazz =
> > Class.forName("org.graal

[Bug 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64614

--- Comment #13 from jfclere  ---
Something like no alias no wrapping and alias and FIPS warning and no wrapping?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Hi Romain,

> -Original Message-
> From: Romain Manni-Bucau 
> Sent: Wednesday, July 22, 2020 12:48 PM
> To: Tomcat Developers List 
> Subject: Re: [tomcat] branch master updated: Simpler way to determine Graal
> runtime
> 
> Thinking out loud: cant you substitute it to be hardcoded to true in native
> mode? This way you get the best of both.

This works for when you compile it to native code. Remy was talking about when 
running under the Substrate VM as a Java application. That's when I experience 
test failures and prompted me to look into a change.
If I understand it correctly, the substrate VM doesn't pick up those 
substitutions when running in Java mode.

Filip

> 
> Le mer. 22 juil. 2020 à 20:17, Filip Hanik   > a écrit :
> 
> 
>   Thanks Remy,
> 
> 
> 
>   I ran into some failures when running the test suite using the substrate
> VM, but it makes more sense to adjust those tests.
> 
>   I’ll revert these today
> 
> 
> 
>   Filip
> 
> 
> 
>   From: Rémy Maucherat   >
> Sent: Wednesday, July 22, 2020 12:10 AM
>   To: Tomcat Developers List   >
>   Subject: Re: [tomcat] branch master updated: Simpler way to
> determine Graal runtime
> 
> 
> 
>   On Tue, Jul 21, 2020 at 11:16 PM   > wrote:
> 
>   This is an automated email from the ASF dual-hosted git
> repository.
> 
>   fhanik pushed a commit to branch master
>   in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>  o
> x.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40v
> mware.c
> om%7C5bb8217a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6c
> d83d9dd62f0
> %7C0%7C0%7C637310444856257107&sdata=T20lk9hPTLaJGtrD5ZLD3OVzkC
> amedtpcKo2
> V4MwXtg%3D&reserved=0>
> 
> 
>   The following commit(s) were added to refs/heads/master by
> this push:
>new 098c4c8  Simpler way to determine Graal runtime
>   098c4c8 is described below
> 
>   commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
>   Author: Filip Hanik   >
>   AuthorDate: Tue Jul 21 14:04:57 2020 -0700
> 
>   Simpler way to determine Graal runtime
> 
>   Also, allows to mock the behavior
> 
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.h
> t
> ml#PROPERTY_IMAGE_CODE_KEY
>  w.g
> raalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageI
> nfo.htm
> l%23PROPERTY_IMAGE_CODE_KEY&data=02%7C01%7Cfhanik%40vmware.co
> m%7C5bb8217
> a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7
> C0%7C0%7C6
> 37310444856267104&sdata=vHbmuRW5YP1%2B2a6romOsuaxaUHqMqF9G4
> ob7aXlSYbY%3D
> &reserved=0>
>   ---
>java/org/apache/jasper/runtime/JspRuntimeLibrary.java |
> 16 +---
>java/org/apache/naming/NamingContext.java |
> 15 +--
>java/org/apache/tomcat/util/compat/GraalCompat.java   |
> 15 +--
>3 files changed, 3 insertions(+), 43 deletions(-)
> 
>   diff --git
> a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   index cfb6e75..f27ce3b 100644
>   ---
> a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   +++
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   @@ -56,21 +56,7 @@ import
> org.apache.tomcat.InstanceManager;
> */
>public class JspRuntimeLibrary {
> 
>   -public static final boolean GRAAL;
>   -
>   -static {
>   -boolean result = false;
>   -try {
>   -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
>   -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
>   -// Note: This will also be true for the
> Graal substrate VM
> 
> 
> 
>   As the comment says, this must also be true when running on the
> substrate VM (= building a native image) and from what I can see this is not
> the case. Basically the code paths used on Graal must be consistent.
> 
>   So it's simpler but it doesn't seem to work at this time, so you need to
> revert this commit. You could get out of this by saying the user can just set 
> the
> system property, but this makes things more error prone so it's a bad idea as
> the previous solution worked just fine.
> 
> 
> 
>   I see an enhancement to fix this as the agent would set the system
> property: https://github.com/oracle/graal/issues/2395
> 

[GitHub] [tomcat-maven-plugin] karlvr commented on a change in pull request #30: Tc9.x Initial suport for Tomact9

[GitBox]

karlvr commented on a change in pull request #30:
URL: https://github.com/apache/tomcat-maven-plugin/pull/30#discussion_r459138051



##
File path: 
tomcat9-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat9/run/RunMojo.java
##
@@ -479,18 +480,23 @@ private WebResource urlToWebResource( URL url, String 
path )
 jarFile = new JarFile( filePath );
 
 JarEntry jarEntry = jarFile.getJarEntry( 
StringUtils.removeStart( path, "/" ) );
-
+/*
 return new JarResource( this, //
 getPath(), //
 filePath, //
 
url.getPath().substring( 0, idx ), //
 jarEntry, //
 "", //
 null );
+*/
+
+JarResourceSet jr = new 
JarResourceSet(context.getResources(), getPath(), filePath, getPath());

Review comment:
   @liudongmiao I think that particular line might have gone in the merge 
from my code... if not, could you please explain what you're seeing that's 
wrong here? The `JarResourceSet` parameters are a little opaque to me, so I'd 
appreciate some more explanation!





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Jakarta EE APIs

[Martin Grigorov]

On Wed, Jul 22, 2020, 18:10 Mark Thomas  wrote:

> Hi all,
>
> We currently have implementations for all of the Jakarta APIs that ship
> with Tomcat and partial implementations for 5 additional Jakarta APIs that
> are compile time only dependencies.
>
> I was checking those partial implementations earlier today when I noticed
> the Jakarta Mail API needed updating to use generics. I started on that but
> paused when it looked like a number of new (dummy) classes would be
> required.
>
> Considering alternative options, I wondered about depending on the Jakarta
> API JARs directly. This would be a return to the 5.5.x era approach
> without  hopefully, the issue that JARs could be difficult to obtain.
>
> I have this implemented locally. It removes about 1000 lines of .java
> files (although just under 10% of them are actual code) and adds about 100
> lines of build file config and anither 50 of IDE configuration.
>
> With the Jakarta JARs being readily available in Maven Central I think the
> primary issue that led to the current approach is no longer a concern.
>
> Thoughts on switching to using the JARs directly? I can provide a


+1

PR if that is helpful.


> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Good idea, I’ll add that as a separate commit.

On Wed, Jul 22, 2020 at 13:08 Rémy Maucherat  wrote:

> On Wed, Jul 22, 2020 at 8:17 PM Filip Hanik  wrote:
>
>> Thanks Remy,
>>
>>
>>
>> I ran into some failures when running the test suite using the substrate
>> VM, but it makes more sense to adjust those tests.
>>
>> I’ll revert these today
>>
>
> I think you should leave the additional check for the system property
> since it is a good override. It would be a transition when
> https://github.com/oracle/graal/issues/2395 is fixed as well.
>
> Rémy
>
>
>>
>>
>> Filip
>>
>>
>>
>> *From:* Rémy Maucherat 
>> *Sent:* Wednesday, July 22, 2020 12:10 AM
>> *To:* Tomcat Developers List 
>> *Subject:* Re: [tomcat] branch master updated: Simpler way to determine
>> Graal runtime
>>
>>
>>
>> On Tue, Jul 21, 2020 at 11:16 PM  wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> fhanik pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>> 
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 098c4c8  Simpler way to determine Graal runtime
>> 098c4c8 is described below
>>
>> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
>> Author: Filip Hanik 
>> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>>
>> Simpler way to determine Graal runtime
>>
>> Also, allows to mock the behavior
>>
>> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
>> 
>> ---
>>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
>> +---
>>  java/org/apache/naming/NamingContext.java | 15
>> +--
>>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15
>> +--
>>  3 files changed, 3 insertions(+), 43 deletions(-)
>>
>> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> index cfb6e75..f27ce3b 100644
>> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>>   */
>>  public class JspRuntimeLibrary {
>>
>> -public static final boolean GRAAL;
>> -
>> -static {
>> -boolean result = false;
>> -try {
>> -Class nativeImageClazz =
>> Class.forName("org.graalvm.nativeimage.ImageInfo");
>> -result =
>> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
>> -// Note: This will also be true for the Graal substrate VM
>>
>>
>>
>> As the comment says, this must also be true when running on the substrate
>> VM (= building a native image) and from what I can see this is not the
>> case. Basically the code paths used on Graal must be consistent.
>>
>> So it's simpler but it doesn't seem to work at this time, so you need to
>> revert this commit. You could get out of this by saying the user can just
>> set the system property, but this makes things more error prone so it's a
>> bad idea as the previous solution worked just fine.
>>
>>
>>
>> I see an enhancement to fix this as the agent would set the system
>> property: https://github.com/oracle/graal/issues/2395
>> 
>>
>> But the Oracle folks said "no" because they can. As usual :D
>>
>>
>>
>> Rémy
>>
>>
>>
>> -} catch (ClassNotFoundException e) {
>> -// Must be Graal
>> -} catch (ReflectiveOperationException | IllegalArgumentException
>> e) {
>> -// Should never happen
>> -}
>> -GRAAL = result;
>> -}
>> +public static final boolean GRAAL =
>> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>>
>>  /**
>>   * Returns the value of the jakarta.servlet.error.exception request
>> diff --git a/java/org/apache/naming/NamingContext.java
>> b/java/org/apache/naming/NamingContext.java
>> index 0471279..40f4085 100644
>> --- a/java/org/apache/naming/Nami

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Rémy Maucherat]

On Wed, Jul 22, 2020 at 8:17 PM Filip Hanik  wrote:

> Thanks Remy,
>
>
>
> I ran into some failures when running the test suite using the substrate
> VM, but it makes more sense to adjust those tests.
>
> I’ll revert these today
>

I think you should leave the additional check for the system property since
it is a good override. It would be a transition when
https://github.com/oracle/graal/issues/2395 is fixed as well.

Rémy


>
>
> Filip
>
>
>
> *From:* Rémy Maucherat 
> *Sent:* Wednesday, July 22, 2020 12:10 AM
> *To:* Tomcat Developers List 
> *Subject:* Re: [tomcat] branch master updated: Simpler way to determine
> Graal runtime
>
>
>
> On Tue, Jul 21, 2020 at 11:16 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 098c4c8  Simpler way to determine Graal runtime
> 098c4c8 is described below
>
> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> Author: Filip Hanik 
> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>
> Simpler way to determine Graal runtime
>
> Also, allows to mock the behavior
>
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
> 
> ---
>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
> +---
>  java/org/apache/naming/NamingContext.java | 15 +--
>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
>  3 files changed, 3 insertions(+), 43 deletions(-)
>
> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> index cfb6e75..f27ce3b 100644
> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>   */
>  public class JspRuntimeLibrary {
>
> -public static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
> -// Note: This will also be true for the Graal substrate VM
>
>
>
> As the comment says, this must also be true when running on the substrate
> VM (= building a native image) and from what I can see this is not the
> case. Basically the code paths used on Graal must be consistent.
>
> So it's simpler but it doesn't seem to work at this time, so you need to
> revert this commit. You could get out of this by saying the user can just
> set the system property, but this makes things more error prone so it's a
> bad idea as the previous solution worked just fine.
>
>
>
> I see an enhancement to fix this as the agent would set the system
> property: https://github.com/oracle/graal/issues/2395
> 
>
> But the Oracle folks said "no" because they can. As usual :D
>
>
>
> Rémy
>
>
>
> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +public static final boolean GRAAL =
> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>
>  /**
>   * Returns the value of the jakarta.servlet.error.exception request
> diff --git a/java/org/apache/naming/NamingContext.java
> b/java/org/apache/naming/NamingContext.java
> index 0471279..40f4085 100644
> --- a/java/org/apache/naming/NamingContext.java
> +++ b/java/org/apache/naming/NamingContext.java
> @@ -792,20 +792,7 @@ public class NamingContext implements Context {
>  // -- Protected
> Methods
>
>
> -privat

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Romain Manni-Bucau]

Thinking out loud: cant you substitute it to be hardcoded to true in native
mode? This way you get the best of both.

Le mer. 22 juil. 2020 à 20:17, Filip Hanik  a écrit :

> Thanks Remy,
>
>
>
> I ran into some failures when running the test suite using the substrate
> VM, but it makes more sense to adjust those tests.
>
> I’ll revert these today
>
>
>
> Filip
>
>
>
> *From:* Rémy Maucherat 
> *Sent:* Wednesday, July 22, 2020 12:10 AM
> *To:* Tomcat Developers List 
> *Subject:* Re: [tomcat] branch master updated: Simpler way to determine
> Graal runtime
>
>
>
> On Tue, Jul 21, 2020 at 11:16 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 098c4c8  Simpler way to determine Graal runtime
> 098c4c8 is described below
>
> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> Author: Filip Hanik 
> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>
> Simpler way to determine Graal runtime
>
> Also, allows to mock the behavior
>
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
> 
> ---
>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
> +---
>  java/org/apache/naming/NamingContext.java | 15 +--
>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
>  3 files changed, 3 insertions(+), 43 deletions(-)
>
> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> index cfb6e75..f27ce3b 100644
> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>   */
>  public class JspRuntimeLibrary {
>
> -public static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
> -// Note: This will also be true for the Graal substrate VM
>
>
>
> As the comment says, this must also be true when running on the substrate
> VM (= building a native image) and from what I can see this is not the
> case. Basically the code paths used on Graal must be consistent.
>
> So it's simpler but it doesn't seem to work at this time, so you need to
> revert this commit. You could get out of this by saying the user can just
> set the system property, but this makes things more error prone so it's a
> bad idea as the previous solution worked just fine.
>
>
>
> I see an enhancement to fix this as the agent would set the system
> property: https://github.com/oracle/graal/issues/2395
> 
>
> But the Oracle folks said "no" because they can. As usual :D
>
>
>
> Rémy
>
>
>
> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +public static final boolean GRAAL =
> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>
>  /**
>   * Returns the value of the jakarta.servlet.error.exception request
> diff --git a/java/org/apache/naming/NamingContext.java
> b/java/org/apache/naming/NamingContext.java
> index 0471279..40f4085 100644
> --- a/java/org/apache/naming/NamingContext.java
> +++ b/java/org/apache/naming/NamingContext.java
> @@ -792,20 +792,7 @@ public class NamingContext implements Context {
>  // -- Protected
> Methods
>
>
> -private static final boolean GRAAL;
> -
> -static {
> -boolean result = fa

[tomcat] branch master updated: Revert "Simpler way to determine Graal runtime"

[fhanik]

This is an automated email from the ASF dual-hosted git repository.

fhanik pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new cb5eaa3  Revert "Simpler way to determine Graal runtime"
cb5eaa3 is described below

commit cb5eaa3925bb4649a74a3872a9fda76fc9d102b1
Author: Filip Hanik 
AuthorDate: Wed Jul 22 11:43:43 2020 -0700

Revert "Simpler way to determine Graal runtime"

This reverts commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573.

https://tomcat.markmail.org/search/?q=#query:%20list%3Aorg.apache.tomcat.dev+page:1+mid:7vo7ugmqjz2z7x5f+state:results
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16 +++-
 java/org/apache/naming/NamingContext.java | 15 ++-
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 ++-
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index f27ce3b..cfb6e75 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -56,7 +56,21 @@ import org.apache.tomcat.InstanceManager;
  */
 public class JspRuntimeLibrary {
 
-public static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+public static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = nativeImageClazz.getMethod("inImageCode").invoke(null) != 
null;
+// Note: This will also be true for the Graal substrate VM
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 /**
  * Returns the value of the jakarta.servlet.error.exception request
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 40f4085..0471279 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -792,7 +792,20 @@ public class NamingContext implements Context {
 // -- Protected Methods
 
 
-private static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+private static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 /**
  * Retrieves the named object.
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java 
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index e3cb09d..9fb835a 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -20,7 +20,20 @@ import java.io.IOException;
 
 class GraalCompat extends Jre9Compat {
 
-private static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+private static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 static boolean isSupported() {
 // This property does not exist for a native image


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

[tomcat] branch 9.0.x updated: Revert "Simpler way to determine Graal runtime"

[fhanik]

This is an automated email from the ASF dual-hosted git repository.

fhanik pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 87cbed1  Revert "Simpler way to determine Graal runtime"
87cbed1 is described below

commit 87cbed1244205fb112f421449482d02b56f6167b
Author: Filip Hanik 
AuthorDate: Wed Jul 22 11:40:14 2020 -0700

Revert "Simpler way to determine Graal runtime"

This reverts commit 6a73695fa6d024ed9fc4adeb32073cbd94309c51.

https://tomcat.markmail.org/search/?q=#query:%20list%3Aorg.apache.tomcat.dev+page:1+mid:7vo7ugmqjz2z7x5f+state:results
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16 +++-
 java/org/apache/naming/NamingContext.java | 15 ++-
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 ++-
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index d710f84..c0a7a63 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -56,7 +56,21 @@ import org.apache.tomcat.InstanceManager;
  */
 public class JspRuntimeLibrary {
 
-public static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+public static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = nativeImageClazz.getMethod("inImageCode").invoke(null) != 
null;
+// Note: This will also be true for the Graal substrate VM
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 /**
  * Returns the value of the javax.servlet.error.exception request
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 40f4085..0471279 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -792,7 +792,20 @@ public class NamingContext implements Context {
 // -- Protected Methods
 
 
-private static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+private static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 /**
  * Retrieves the named object.
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java 
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index e3cb09d..9fb835a 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -20,7 +20,20 @@ import java.io.IOException;
 
 class GraalCompat extends Jre9Compat {
 
-private static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
+private static final boolean GRAAL;
+
+static {
+boolean result = false;
+try {
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
+result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
+} catch (ClassNotFoundException e) {
+// Must be Graal
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
+}
 
 static boolean isSupported() {
 // This property does not exist for a native image


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

Re: Jakarta EE APIs

[Rémy Maucherat]

On Wed, Jul 22, 2020 at 5:10 PM Mark Thomas  wrote:

> Hi all,
>
> We currently have implementations for all of the Jakarta APIs that ship
> with Tomcat and partial implementations for 5 additional Jakarta APIs that
> are compile time only dependencies.
>
> I was checking those partial implementations earlier today when I noticed
> the Jakarta Mail API needed updating to use generics. I started on that but
> paused when it looked like a number of new (dummy) classes would be
> required.
>
> Considering alternative options, I wondered about depending on the Jakarta
> API JARs directly. This would be a return to the 5.5.x era approach
> without  hopefully, the issue that JARs could be difficult to obtain.
>
> I have this implemented locally. It removes about 1000 lines of .java
> files (although just under 10% of them are actual code) and adds about 100
> lines of build file config and anither 50 of IDE configuration.
>
> With the Jakarta JARs being readily available in Maven Central I think the
> primary issue that led to the current approach is no longer a concern.
>
> Thoughts on switching to using the JARs directly? I can provide a PR if
> that is helpful.
>

Ok, +1 to try it.

Rémy


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

RE: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Thanks Remy,

I ran into some failures when running the test suite using the substrate VM, 
but it makes more sense to adjust those tests.
I’ll revert these today

Filip

From: Rémy Maucherat 
Sent: Wednesday, July 22, 2020 12:10 AM
To: Tomcat Developers List 
Subject: Re: [tomcat] branch master updated: Simpler way to determine Graal 
runtime

On Tue, Jul 21, 2020 at 11:16 PM mailto:fha...@apache.org>> 
wrote:
This is an automated email from the ASF dual-hosted git repository.

fhanik pushed a commit to branch master
in repository 
https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 098c4c8  Simpler way to determine Graal runtime
098c4c8 is described below

commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
Author: Filip Hanik mailto:fha...@pivotal.io>>
AuthorDate: Tue Jul 21 14:04:57 2020 -0700

Simpler way to determine Graal runtime

Also, allows to mock the behavior

https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16 +---
 java/org/apache/naming/NamingContext.java | 15 +--
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
 3 files changed, 3 insertions(+), 43 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index cfb6e75..f27ce3b 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
  */
 public class JspRuntimeLibrary {

-public static final boolean GRAAL;
-
-static {
-boolean result = false;
-try {
-Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
-result = nativeImageClazz.getMethod("inImageCode").invoke(null) != 
null;
-// Note: This will also be true for the Graal substrate VM

As the comment says, this must also be true when running on the substrate VM (= 
building a native image) and from what I can see this is not the case. 
Basically the code paths used on Graal must be consistent.
So it's simpler but it doesn't seem to work at this time, so you need to revert 
this commit. You could get out of this by saying the user can just set the 
system property, but this makes things more error prone so it's a bad idea as 
the previous solution worked just fine.

I see an enhancement to fix this as the agent would set the system property: 
https://github.com/oracle/graal/issues/2395
But the Oracle folks said "no" because they can. As usual :D

Rémy

-} catch (ClassNotFoundException e) {
-// Must be Graal
-} catch (ReflectiveOperationException | IllegalArgumentException e) {
-// Should never happen
-}
-GRAAL = result;
-}
+public static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;

 /**
  * Returns the value of the jakarta.servlet.error.exception request
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 0471279..40f4085 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -792,20 +792,7 @@ public class NamingContext implements Context {
 // -- Protected Methods


-private static final boolean GRAAL;
-
-static {
-boolean result = false;
-try {
-Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
-result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
-} catch (ClassNotFoundException e) {
-// Must be Graal
-} catch (ReflectiveOperationException | Illegal

Re: Jakarta EE APIs

[Romain Manni-Bucau]

Le mer. 22 juil. 2020 à 18:29, Mark Thomas  a écrit :

> On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > Another option is to use Apache Geronimo specs (and update/create
> > missing ones - think new mail one is not yet there for ex).
>
> This is a distinct disadvantage.
>

You mean not having it handy?
Think it is 1-1 with current option except it solves the fact to have it
within tomcat.



> > Advantage would be we wouldn't lose all the work around OSGi and jpms
> > eclipse does not - and will not probably - handle (at least for the
> > first part).
>
> As compile time only JARs OSGi and JPMS are not a factor.
>
> > It also cleans up the legal work for Tomcat as a small side bonus.
>
> They are all EPLv2 licensed and compile time only so there isn't any
> legal work required.
>

Didnt check recently but think you still must bundle their license and do
some notice work.


> Mark
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 22 juil. 2020 à 17:53, Mark Thomas  > > a écrit :
> >
> > On 22/07/2020 15:53, Mark Thomas wrote:
> > > Hi all,
> > >
> > > We currently have implementations for all of the Jakarta APIs that
> > ship with Tomcat and partial implementations for 5 additional
> > Jakarta APIs that are compile time only dependencies.
> > >
> > > I was checking those partial implementations earlier today when I
> > noticed the Jakarta Mail API needed updating to use generics. I
> > started on that but paused when it looked like a number of new
> > (dummy) classes would be required.
> > >
> > > Considering alternative options, I wondered about depending on the
> > Jakarta API JARs directly. This would be a return to the 5.5.x era
> > approach without  hopefully, the issue that JARs could be difficult
> > to obtain.
> > >
> > > I have this implemented locally. It removes about 1000 lines of
> > .java files (although just under 10% of them are actual code) and
> > adds about 100 lines of build file config and anither 50 of IDE
> > configuration.
> > >
> > > With the Jakarta JARs being readily available in Maven Central I
> > think the primary issue that led to the current approach is no
> > longer a concern.
> > >
> > > Thoughts on switching to using the JARs directly? I can provide a
> > PR if that is helpful.
> >
> > For clarity, I'm only proposing to do this for Tomcat 10 where at
> least
> > one of these APIs has changes other than just a package rename. I
> don't
> > see the benefit in doing this for Tomact 9 and earlier.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > 
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > 
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

RE: [tomcat] branch master updated: Avoid reflection for default instantiation

[Filip Hanik]

Hi Christopher,
> > environments. -Class clazz =
> > Class.forName(className); -return
> > (AuthConfigFactory) clazz.getConstructor().newInstance(); + if
> > (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfig
> FactoryImpl"))
> > {
> 
> Why not use AuthConfigFactoryImpl.class.getName()? It may help in the
> future with refactoring.

[Filip Hanik] 
Trying to avoid a circular dependency. You see the javax/jakarta package should 
not import org.apache.catalina code. I should be able to execute the 
AuthConfigFactory code without needing to load 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl class. The JVM 
is smart enough that if the execution doesn't enter the if statement block, it 
won't attempt the classloading of the AuthConfigFactoryImpl class. However, if 
the AuthConfigFactoryImpl Class itself is part of the evaluation statement, it 
will be loaded.

The previous implementation also had it as a string, instead of 
AuthConfigFactoryImpl.class.getName() for the same reason.
https://github.com/apache/tomcat/blob/35dc7b9288aad4a7d70750c157543d4ff1593c98/java/jakarta/security/auth/message/config/AuthConfigFactory.java#L48-L49

This way, I can build a jakarta.security.auth.message library, that can be used 
without the org.apache.catalina library.

I need to change my commit to use the constant, instead of the duplicated 
string in the IF statement.

if 
(className.equals(DEFAULT_JASPI_AUTHCONFIGFACTORYIMPL)) {
return new 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl();
} else {
Class clazz = Class.forName(className);
return (AuthConfigFactory) 
clazz.getConstructor().newInstance();
}

> 
> - -chris 

Re: Jakarta EE APIs

[Mark Thomas]

On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> Hi Mark,
> 
> Another option is to use Apache Geronimo specs (and update/create
> missing ones - think new mail one is not yet there for ex).

This is a distinct disadvantage.

> Advantage would be we wouldn't lose all the work around OSGi and jpms
> eclipse does not - and will not probably - handle (at least for the
> first part).

As compile time only JARs OSGi and JPMS are not a factor.

> It also cleans up the legal work for Tomcat as a small side bonus.

They are all EPLv2 licensed and compile time only so there isn't any
legal work required.

Mark


> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> Le mer. 22 juil. 2020 à 17:53, Mark Thomas  > a écrit :
> 
> On 22/07/2020 15:53, Mark Thomas wrote:
> > Hi all,
> >
> > We currently have implementations for all of the Jakarta APIs that
> ship with Tomcat and partial implementations for 5 additional
> Jakarta APIs that are compile time only dependencies.
> >
> > I was checking those partial implementations earlier today when I
> noticed the Jakarta Mail API needed updating to use generics. I
> started on that but paused when it looked like a number of new
> (dummy) classes would be required.
> >
> > Considering alternative options, I wondered about depending on the
> Jakarta API JARs directly. This would be a return to the 5.5.x era
> approach without  hopefully, the issue that JARs could be difficult
> to obtain.
> >
> > I have this implemented locally. It removes about 1000 lines of
> .java files (although just under 10% of them are actual code) and
> adds about 100 lines of build file config and anither 50 of IDE
> configuration.
> >
> > With the Jakarta JARs being readily available in Maven Central I
> think the primary issue that led to the current approach is no
> longer a concern.
> >
> > Thoughts on switching to using the JARs directly? I can provide a
> PR if that is helpful.
> 
> For clarity, I'm only proposing to do this for Tomcat 10 where at least
> one of these APIs has changes other than just a package rename. I don't
> see the benefit in doing this for Tomact 9 and earlier.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> 
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> 


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

Re: JAX-RPC and Tomcat 10

[Mark Thomas]

On 21/07/2020 14:44, Romain Manni-Bucau wrote:
> Yes, was thinking to tomee in particular since it does not use tomcat as
> a lib but really as the container so if the container fails then it can
> become hard if not "disabl-able" somehow (at least with subclassing or
> something programmatic).

I don't think I am going to pursue this at this time. The benefit is
minimal and the chances it breaks something or makes things difficult
for TomEE is high.

I may come back to this in the future.

Mark


> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> Le mar. 21 juil. 2020 à 15:39, Mark Thomas  > a écrit :
> 
> On 21/07/2020 14:26, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > e) c as default + add a toggle to behave as a? (thinking to container
> > extending tomcat where this shouldn't fail probably)
> 
> So keep the attributes in ContextService and friends that record the
> JAX-RPC so they are accessible to downstream projects that still want to
> support JAX-RPC? Are there any such projects? TomEE?
> 
> Mark
> 
> 
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> >
> 
> 
> >
> >
> > Le mar. 21 juil. 2020 à 14:34, Mark Thomas  
> > >> a écrit :
> >
> >     All,
> >
> >     JAX-RPC has been removed in Jakarta EE 9.
> >
> >     Implementations are free to continue supporting it if they wish.
> >
> >     My preference would be to remove JAX-RPS support in Tomcat 10.
> >
> >     I am working on this at the moment and am wondering how to
> handle the
> >     JAX-RPC elements we can't entirely remove.
> >
> >     There is a chain of references from web-app_5_0.xsd to
> >     jakartaee_web_services_client_2_0.xsd which still has a number of
> >     JAX-RPC specific attributes defined for "service-ref":
> >
> >     - jaxrpc-mapping-file
> >     - handler
> >     - handler-chains
> >
> >     (a double check I have identified all the JAX-RPC specific
> attributes
> >     would be appreciated)
> >
> >     This appears to be a consequence of the same element being
> used for
> >     JAX-RPC and JAX-WS.
> >
> >     Assuming there is consensus to remove JAX-RPC support then the
> question
> >     arises what do we do if we observe one of the JAX-RPC specific
> >     attributes above? Possible options include:
> >
> >     a) Ignore it and carry on
> >     b) Log a warning but otherwise ignore it and carry on
> >     c) Log an error and fail the deployment
> >     d) Something else
> >
> >     I'm currently leaning towards option c.
> >
> >     Thoughts?
> >
> >     Mark
> >
> >   
>  -
> >     To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> 
> >      >
> >     For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> >      >
> >
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> 
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> 


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

Re: Jakarta EE APIs

[Romain Manni-Bucau]

Hi Mark,

Another option is to use Apache Geronimo specs (and update/create missing
ones - think new mail one is not yet there for ex).
Advantage would be we wouldn't lose all the work around OSGi and jpms
eclipse does not - and will not probably - handle (at least for the first
part).
It also cleans up the legal work for Tomcat as a small side bonus.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 juil. 2020 à 17:53, Mark Thomas  a écrit :

> On 22/07/2020 15:53, Mark Thomas wrote:
> > Hi all,
> >
> > We currently have implementations for all of the Jakarta APIs that ship
> with Tomcat and partial implementations for 5 additional Jakarta APIs that
> are compile time only dependencies.
> >
> > I was checking those partial implementations earlier today when I
> noticed the Jakarta Mail API needed updating to use generics. I started on
> that but paused when it looked like a number of new (dummy) classes would
> be required.
> >
> > Considering alternative options, I wondered about depending on the
> Jakarta API JARs directly. This would be a return to the 5.5.x era approach
> without  hopefully, the issue that JARs could be difficult to obtain.
> >
> > I have this implemented locally. It removes about 1000 lines of .java
> files (although just under 10% of them are actual code) and adds about 100
> lines of build file config and anither 50 of IDE configuration.
> >
> > With the Jakarta JARs being readily available in Maven Central I think
> the primary issue that led to the current approach is no longer a concern.
> >
> > Thoughts on switching to using the JARs directly? I can provide a PR if
> that is helpful.
>
> For clarity, I'm only proposing to do this for Tomcat 10 where at least
> one of these APIs has changes other than just a package rename. I don't
> see the benefit in doing this for Tomact 9 and earlier.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Jakarta EE APIs

[Mark Thomas]

On 22/07/2020 15:53, Mark Thomas wrote:
> Hi all,
> 
> We currently have implementations for all of the Jakarta APIs that ship with 
> Tomcat and partial implementations for 5 additional Jakarta APIs that are 
> compile time only dependencies.
> 
> I was checking those partial implementations earlier today when I noticed the 
> Jakarta Mail API needed updating to use generics. I started on that but 
> paused when it looked like a number of new (dummy) classes would be required.
> 
> Considering alternative options, I wondered about depending on the Jakarta 
> API JARs directly. This would be a return to the 5.5.x era approach without  
> hopefully, the issue that JARs could be difficult to obtain.
> 
> I have this implemented locally. It removes about 1000 lines of .java files 
> (although just under 10% of them are actual code) and adds about 100 lines of 
> build file config and anither 50 of IDE configuration.
> 
> With the Jakarta JARs being readily available in Maven Central I think the 
> primary issue that led to the current approach is no longer a concern.
> 
> Thoughts on switching to using the JARs directly? I can provide a PR if that 
> is helpful.

For clarity, I'm only proposing to do this for Tomcat 10 where at least
one of these APIs has changes other than just a package rename. I don't
see the benefit in doing this for Tomact 9 and earlier.

Mark

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

Re: [tomcat] branch master updated: Avoid reflection for default instantiation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filip,

On 7/21/20 11:22, fha...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> fhanik pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this
> push: new c08bf81  Avoid reflection for default instantiation
> c08bf81 is described below
>
> commit c08bf81f0db7742779ab0c5da45818dde8465d34 Author: Filip Hanik
>  AuthorDate: Mon Jul 13 12:43:55 2020 -0700
>
> Avoid reflection for default instantiation
>
> (Most commonly used codepath)
>
> Avoid having to load APR classes in the Connector
>
> Ensure that IntrospectionUtils can call setProperty on
> PersistentProviderRegistrations ---
> .../auth/message/config/AuthConfigFactory.java |  8 ++-
> .../jaspic/PersistentProviderRegistrations.java| 12 -
> java/org/apache/catalina/connector/Connector.java  |  8 +--
> .../apache/catalina/core/AprLifecycleListener.java | 32
> +--- java/org/apache/catalina/core/AprStatus.java   |
> 60 ++
> java/org/apache/catalina/core/StandardHost.java|  4 +-
> java/org/apache/catalina/loader/WebappLoader.java  |  4 ++
> java/org/apache/catalina/startup/Tomcat.java   |  8 ++- 8 files
> changed, 109 insertions(+), 27 deletions(-)
>
> diff --git
> a/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> b/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> index d0e1cbd..6f02fde 100644 ---
> a/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> +++
> b/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> @@ -72,8 +72,12 @@ public abstract class AuthConfigFactory { //
> this class. Note that the Thread context class loader // should not
> be used since that would trigger a memory leak // in container
> environments. -Class clazz =
> Class.forName(className); -return
> (AuthConfigFactory) clazz.getConstructor().newInstance(); +
> if
> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfig
FactoryImpl"))
> {

Why not use AuthConfigFactoryImpl.class.getName()? It may help in the
future with refactoring.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8YXgIACgkQHPApP6U8
pFgHmA/8CweFBvWtEn14ZzUZHkA/7HVaLPG6r7Y4qzkcrzJfQImYzV7E0x3NL59m
fDagGxJrxugESEKf3HLmq5VIzAlemkbPxYQ7S4KaUJVHbRW/MH9zPVzbvAVXy4Gm
CIpVF/QoXftJ9WYsMkwFFu8ZeRsUQSJ5Z4eFXmHgOzDSj42vUR7VDsFXmpoqdIpC
jp0CV9p+XyfAcvtsJXnTKKmDGFV7liH4d38mz8wNLFw1yFk8jswHeyzzy+6u9QVu
fFno1AZ67UWjeOlMz+kQ4S9n3X+irT03Qpc8+kvWDibnEDYuHivvhvROWOn4ja92
dyF+6YZxOGIf4QHwM0BHL+8IzrcodB15j7Iv0Fw9VKrJvcj55qZTerHvOkiwUDQF
1vsiqPtOEWrE4q87Y7aev3WBpRWfxQFu50IQNIAvPwiBmT9mj+3iztq46m5CTtnt
zjfdzxEMF5n74L+2u+CPIekngJ8i0RJOkq4UGrJmXpbX/82q+eN+TDws6GchRquG
3Hr2EgC3oocITMTbu+5ZjvbBVAh30VhqlOF1GwO8YSBIgvNUyPvIqZXK4Re9gjYm
BSRHl2juGFP3d1OSkdimWBkBc8MHx3QOkcCOzZYgPg3mdAq7beqKgh/DTvqQd5D8
MXGe4cgfHoOEY0X53K/qG1KXcIntRXab9Nue8GriGC9M7oMWgIM=
=48+3
-END PGP SIGNATURE-

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

Jakarta EE APIs

[Mark Thomas]

Hi all,

We currently have implementations for all of the Jakarta APIs that ship with 
Tomcat and partial implementations for 5 additional Jakarta APIs that are 
compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the 
Jakarta Mail API needed updating to use generics. I started on that but paused 
when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API 
JARs directly. This would be a return to the 5.5.x era approach without  
hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files 
(although just under 10% of them are actual code) and adds about 100 lines of 
build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the 
primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a PR if that is 
helpful.

Mark

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

[Bug 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64614

--- Comment #12 from Christopher Schultz  ---
Aren't we just "always wrapping" because it was simpler than only wrapping when
necessary? Why don't we "only" wrap when we must? I think the wrapper is only
for certain scenarios. Why not detect THOSE instead of trying to detect the
cases where un-wrapping is necessary?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64619] Regression: Removal of scratchdir fallback affects existing code

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64619

--- Comment #3 from Markus Schlegel  ---
Thanks for the clarification.
I can understand your demand for having the codebase of the maintenance
branches somewhat in sync.
Since the checkin was not associated with a issue, I thought that it was an
unforced change.

After looking into the spec given by markt, I understand that it indeed was a
bug to silently share the same working-directory across different servlet
context when javax.servlet.context.tempdir is not defined.
Having a "must-have" attribute defined in the servlet spec seems very unfortune
for me. The spec would better have made an additional method on the interface
for this, such that the change and need becomes obvious.

But finally, I will have to fix that in our code.
Nevertheless, it would have been a good practice to create an issue for this
code change and explain the reasoning for the change there (with reference to
specification). My application would still have failed to run, but it would
have been clear why.

@mgrigorov: We have different usages of Tomcat in our Application. The "normal"
WebServer/Servlet-Container usage is not affected by this issue. Another usage
uses only Jasper as a component of Tomcat to generate reports using JSP's
without being inside a real web-container. Only minor involvement of catalina
there and therefore no call to postWorkDirectory().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Complete javax -> jakarta rename.

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new f5efdad  Complete javax -> jakarta rename.
f5efdad is described below

commit f5efdadaf9c468c452dbee99831b20021f37495c
Author: Mark Thomas 
AuthorDate: Wed Jul 22 13:17:23 2020 +0100

Complete javax -> jakarta rename.
---
 build.xml  |  7 
 java/{javax => jakarta}/xml/ws/WebServiceRef.java  |  4 +--
 java/{javax => jakarta}/xml/ws/WebServiceRefs.java |  4 +--
 .../catalina/core/DefaultInstanceManager.java  |  4 +--
 res/checkstyle/javax-checkstyle.xml| 37 --
 res/checkstyle/javax-import-control.xml| 27 
 res/checkstyle/org-import-control.xml  |  1 +
 webapps/docs/changelog.xml | 11 +--
 8 files changed, 13 insertions(+), 82 deletions(-)

diff --git a/build.xml b/build.xml
index e312594..cf79946 100644
--- a/build.xml
+++ b/build.xml
@@ -624,12 +624,6 @@
 
   
 
-
-
-  
-
-  
-
 
 
   
@@ -1502,7 +1496,6 @@
   
   
   
-  
   
   
   
diff --git a/java/javax/xml/ws/WebServiceRef.java 
b/java/jakarta/xml/ws/WebServiceRef.java
similarity index 98%
rename from java/javax/xml/ws/WebServiceRef.java
rename to java/jakarta/xml/ws/WebServiceRef.java
index 28b150e..d90a037 100644
--- a/java/javax/xml/ws/WebServiceRef.java
+++ b/java/jakarta/xml/ws/WebServiceRef.java
@@ -14,9 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
-
-package javax.xml.ws;
+package jakarta.xml.ws;
 
 import java.lang.annotation.ElementType;
 import java.lang.annotation.Retention;
diff --git a/java/javax/xml/ws/WebServiceRefs.java 
b/java/jakarta/xml/ws/WebServiceRefs.java
similarity index 97%
rename from java/javax/xml/ws/WebServiceRefs.java
rename to java/jakarta/xml/ws/WebServiceRefs.java
index e4f428c..f15f98a 100644
--- a/java/javax/xml/ws/WebServiceRefs.java
+++ b/java/jakarta/xml/ws/WebServiceRefs.java
@@ -14,9 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
-
-package javax.xml.ws;
+package jakarta.xml.ws;
 
 import java.lang.annotation.ElementType;
 import java.lang.annotation.Retention;
diff --git a/java/org/apache/catalina/core/DefaultInstanceManager.java 
b/java/org/apache/catalina/core/DefaultInstanceManager.java
index efeb968..bf2993b 100644
--- a/java/org/apache/catalina/core/DefaultInstanceManager.java
+++ b/java/org/apache/catalina/core/DefaultInstanceManager.java
@@ -37,7 +37,6 @@ import java.util.Set;
 
 import javax.naming.Context;
 import javax.naming.NamingException;
-import javax.xml.ws.WebServiceRef;
 
 import jakarta.annotation.PostConstruct;
 import jakarta.annotation.PreDestroy;
@@ -45,6 +44,7 @@ import jakarta.annotation.Resource;
 import jakarta.ejb.EJB;
 import jakarta.persistence.PersistenceContext;
 import jakarta.persistence.PersistenceUnit;
+import jakarta.xml.ws.WebServiceRef;
 
 import org.apache.catalina.ContainerServlet;
 import org.apache.catalina.Globals;
@@ -91,7 +91,7 @@ public class DefaultInstanceManager implements 
InstanceManager {
 
 clazz = null;
 try {
-clazz = Class.forName("javax.xml.ws.WebServiceRef");
+clazz = Class.forName("jakarta.xml.ws.WebServiceRef");
 } catch (ClassNotFoundException cnfe) {
 // Expected
 }
diff --git a/res/checkstyle/javax-checkstyle.xml 
b/res/checkstyle/javax-checkstyle.xml
deleted file mode 100644
index bb7568c..000
--- a/res/checkstyle/javax-checkstyle.xml
+++ /dev/null
@@ -1,37 +0,0 @@
-
-
-http://www.puppycrawl.com/dtds/configuration_1_2.dtd";>
-
-  
-  
-  
-
-  
-  
-
-  
-
-  
-
-  
-
-  
-
diff --git a/res/checkstyle/javax-import-control.xml 
b/res/checkstyle/javax-import-control.xml
deleted file mode 100644
index 5f6e23f..000
--- a/res/checkstyle/javax-import-control.xml
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-http://www.puppycrawl.com/dtds/import_control_1_1.dtd";>
-
-
-  
-  
-
-  
-
\ No newline at end of file
diff --git a/res/checkstyle/org-import-control.xml 
b/res/checkstyle/org-import-control.xml
index e35985c..fc69cef 100644
--- a/res/checkstyle/org-import-control.xml
+++ b/res/checkstyle/org-import-control.xml
@@ -42,6 +42,7 @@
 
 
 
+
 
 
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 1585d5a..246c2c4 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -120,9 +120,14 @@
 packages. (markt)
   
   
-Remove the local copy of javax.transaction.xa package 
which
-is only used during compilation. The package is provided by the J

[tomcat] branch master updated: Remove the javax.transaction.xa package. It is provided by the JRE.

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 500d21d  Remove the javax.transaction.xa package. It is provided by 
the JRE.
500d21d is described below

commit 500d21d21bd52129d84839833f829ff16281472e
Author: Mark Thomas 
AuthorDate: Wed Jul 22 12:53:42 2020 +0100

Remove the javax.transaction.xa package. It is provided by the JRE.

It is only used at compile time and should be present from Java 1.4
onwards so removal is expected to be safe.
---
 java/javax/transaction/xa/XAException.java | 64 --
 java/javax/transaction/xa/XAResource.java  | 52 
 java/javax/transaction/xa/Xid.java | 28 -
 webapps/docs/changelog.xml |  5 +++
 4 files changed, 5 insertions(+), 144 deletions(-)

diff --git a/java/javax/transaction/xa/XAException.java 
b/java/javax/transaction/xa/XAException.java
deleted file mode 100644
index 2519c4e..000
--- a/java/javax/transaction/xa/XAException.java
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements.  See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package javax.transaction.xa;
-
-public class XAException extends java.lang.Exception {
-
-private static final long serialVersionUID = -8647128647842792941L;
-
-public int errorCode;
-
-public XAException() {
-super();
-}
-
-public XAException(String s) {
-super(s);
-}
-
-public XAException(int errcode) {
-super();
-errorCode = errcode;
-}
-
-public static final int XA_RBBASE = 100;
-public static final int XA_RBROLLBACK = XA_RBBASE;
-public static final int XA_RBCOMMFAIL = XA_RBBASE + 1;
-public static final int XA_RBDEADLOCK = XA_RBBASE + 2;
-public static final int XA_RBINTEGRITY = XA_RBBASE + 3;
-public static final int XA_RBOTHER = XA_RBBASE + 4;
-public static final int XA_RBPROTO = XA_RBBASE + 5;
-public static final int XA_RBTIMEOUT = XA_RBBASE + 6;
-public static final int XA_RBTRANSIENT = XA_RBBASE + 7;
-public static final int XA_RBEND = XA_RBTRANSIENT;
-public static final int XA_NOMIGRATE = 9;
-public static final int XA_HEURHAZ = 8;
-public static final int XA_HEURCOM = 7;
-public static final int XA_HEURRB = 6;
-public static final int XA_HEURMIX = 5;
-public static final int XA_RETRY = 4;
-public static final int XA_RDONLY = 3;
-public static final int XAER_ASYNC = -2;
-public static final int XAER_RMERR = -3;
-public static final int XAER_NOTA = -4;
-public static final int XAER_INVAL = -5;
-public static final int XAER_PROTO = -6;
-public static final int XAER_RMFAIL = -7;
-public static final int XAER_DUPID = -8;
-public static final int XAER_OUTSIDE = -9;
-
-}
diff --git a/java/javax/transaction/xa/XAResource.java 
b/java/javax/transaction/xa/XAResource.java
deleted file mode 100644
index c7edd36..000
--- a/java/javax/transaction/xa/XAResource.java
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements.  See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package javax.transaction.xa;
-
-public interface XAResource {
-void commit(Xid xid, boolean onePhase) throws XAException;
-
-void end(Xid xid, int flags) throws XAException;
-
-void forget(Xid xid) throws XAException;
-
-int 

[tomcat] branch 9.0.x updated: Remove the javax.transaction.xa package. It is provided by the JRE.

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 9018af8  Remove the javax.transaction.xa package. It is provided by 
the JRE.
9018af8 is described below

commit 9018af861b40137bcfa225bc1b1c74a4945f21a1
Author: Mark Thomas 
AuthorDate: Wed Jul 22 12:53:42 2020 +0100

Remove the javax.transaction.xa package. It is provided by the JRE.

It is only used at compile time and should be present from Java 1.4
onwards so removal is expected to be safe.
---
 java/javax/transaction/xa/XAException.java | 64 --
 java/javax/transaction/xa/XAResource.java  | 52 
 java/javax/transaction/xa/Xid.java | 28 -
 webapps/docs/changelog.xml |  5 +++
 4 files changed, 5 insertions(+), 144 deletions(-)

diff --git a/java/javax/transaction/xa/XAException.java 
b/java/javax/transaction/xa/XAException.java
deleted file mode 100644
index 2519c4e..000
--- a/java/javax/transaction/xa/XAException.java
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements.  See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package javax.transaction.xa;
-
-public class XAException extends java.lang.Exception {
-
-private static final long serialVersionUID = -8647128647842792941L;
-
-public int errorCode;
-
-public XAException() {
-super();
-}
-
-public XAException(String s) {
-super(s);
-}
-
-public XAException(int errcode) {
-super();
-errorCode = errcode;
-}
-
-public static final int XA_RBBASE = 100;
-public static final int XA_RBROLLBACK = XA_RBBASE;
-public static final int XA_RBCOMMFAIL = XA_RBBASE + 1;
-public static final int XA_RBDEADLOCK = XA_RBBASE + 2;
-public static final int XA_RBINTEGRITY = XA_RBBASE + 3;
-public static final int XA_RBOTHER = XA_RBBASE + 4;
-public static final int XA_RBPROTO = XA_RBBASE + 5;
-public static final int XA_RBTIMEOUT = XA_RBBASE + 6;
-public static final int XA_RBTRANSIENT = XA_RBBASE + 7;
-public static final int XA_RBEND = XA_RBTRANSIENT;
-public static final int XA_NOMIGRATE = 9;
-public static final int XA_HEURHAZ = 8;
-public static final int XA_HEURCOM = 7;
-public static final int XA_HEURRB = 6;
-public static final int XA_HEURMIX = 5;
-public static final int XA_RETRY = 4;
-public static final int XA_RDONLY = 3;
-public static final int XAER_ASYNC = -2;
-public static final int XAER_RMERR = -3;
-public static final int XAER_NOTA = -4;
-public static final int XAER_INVAL = -5;
-public static final int XAER_PROTO = -6;
-public static final int XAER_RMFAIL = -7;
-public static final int XAER_DUPID = -8;
-public static final int XAER_OUTSIDE = -9;
-
-}
diff --git a/java/javax/transaction/xa/XAResource.java 
b/java/javax/transaction/xa/XAResource.java
deleted file mode 100644
index c7edd36..000
--- a/java/javax/transaction/xa/XAResource.java
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements.  See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package javax.transaction.xa;
-
-public interface XAResource {
-void commit(Xid xid, boolean onePhase) throws XAException;
-
-void end(Xid xid, int flags) throws XAException;
-
-void forget(Xid xid) throws XAException;
-
-int ge

[Bug 64619] Regression: Removal of scratchdir fallback affects existing code

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64619

--- Comment #2 from Mark Thomas  ---
The Tomcat code base being the age and size it is, it isn't uncommon to come
across cruft while researching other issues. The decision when and how to
remove such cruft is always going to be taken on a case by case basis.

In this case it is a mandatory requirement of the Servlet specification (see
Servlet 3.1, section 4.8.1) that a ServletContext implementation provides a
temporary storage location and exposes it via the javax.servlet.context.tempdir
attribute. While the Servlet 3.1 spec applies to Tomcat 8.x, the same
requirement has existed at least as far back as Servlet 2.2 (December 1999 /
Tomcat 3).

Given the above, removal of the code intended to address a situation that
should not have existed for over 20 years and looked to be addressing pre
Tomact 3 implementations seemed reasonable.

Whether or not the clean-up should have been included in the changelog is
debatable. With hindsight, inclusion may have helped in this case. There is a
balance to strike between including everything in the changelog and not
overwhelming the changelog with trivial entries. I think there is probably a
case for moving that balance a little more towards including entries.

At this point this looks more like a specification compliance bug in the custom
ServletContext implementation rather than a Tomcat issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] 02/02: Avoid reflection for default instantiation

[Martin Grigorov]

Hi,

On Wed, Jul 22, 2020 at 2:18 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch 9.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit f4dac6846c548144799b1c3f33aba4eb320a3413
> Author: Filip Hanik 
> AuthorDate: Mon Jul 13 12:43:55 2020 -0700
>
> Avoid reflection for default instantiation
>
> (Most commonly used codepath)
>
> Avoid having to load APR classes in the Connector
>
> Ensure that IntrospectionUtils can call setProperty on
> PersistentProviderRegistrations
> ---
>  .../auth/message/config/AuthConfigFactory.java |  8 ++-
>  .../jaspic/PersistentProviderRegistrations.java|  5 +-
>  java/org/apache/catalina/connector/Connector.java  | 14 ++---
>  .../apache/catalina/core/AprLifecycleListener.java | 43 ++
>  java/org/apache/catalina/core/AprStatus.java   | 69
> ++
>  java/org/apache/catalina/core/StandardHost.java|  4 +-
>  java/org/apache/catalina/loader/WebappLoader.java  |  4 ++
>  java/org/apache/catalina/startup/Tomcat.java   |  8 ++-
>  8 files changed, 119 insertions(+), 36 deletions(-)
>
> diff --git
> a/java/javax/security/auth/message/config/AuthConfigFactory.java
> b/java/javax/security/auth/message/config/AuthConfigFactory.java
> index d98b2f2..b27235b 100644
> --- a/java/javax/security/auth/message/config/AuthConfigFactory.java
> +++ b/java/javax/security/auth/message/config/AuthConfigFactory.java
> @@ -72,8 +72,12 @@ public abstract class AuthConfigFactory {
>  // this class. Note that the Thread context
> class loader
>  // should not be used since that would
> trigger a memory leak
>  // in container environments.
> -Class clazz = Class.forName(className);
> -return (AuthConfigFactory)
> clazz.getConstructor().newInstance();
> +if
> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl"))
> {
> +return new
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl();
> +} else {
> +Class clazz = Class.forName(className);
> +return (AuthConfigFactory)
> clazz.getConstructor().newInstance();
> +}
>  }
>  });
>  } catch (PrivilegedActionException e) {
> diff --git
> a/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> b/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> index a1ba60c..cd75799 100644
> ---
> a/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> +++
> b/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> @@ -41,7 +41,7 @@ import org.xml.sax.SAXException;
>   * Utility class for the loading and saving of JASPIC persistent provider
>   * registrations.
>   */
> -final class PersistentProviderRegistrations {
> +public final class PersistentProviderRegistrations {
>
>  private static final StringManager sm =
>
>  StringManager.getManager(PersistentProviderRegistrations.class);
> @@ -233,6 +233,9 @@ final class PersistentProviderRegistrations {
>  public void addProperty(Property property) {
>  properties.put(property.getName(), property.getValue());
>  }
> +public void setProperty(String name, String value) {
> +addProperty(name, value);
> +}
>  void addProperty(String name, String value) {
>  properties.put(name, value);
>  }
> diff --git a/java/org/apache/catalina/connector/Connector.java
> b/java/org/apache/catalina/connector/Connector.java
> index b22ce95..1cc1580 100644
> --- a/java/org/apache/catalina/connector/Connector.java
> +++ b/java/org/apache/catalina/connector/Connector.java
> @@ -29,7 +29,7 @@ import org.apache.catalina.Globals;
>  import org.apache.catalina.LifecycleException;
>  import org.apache.catalina.LifecycleState;
>  import org.apache.catalina.Service;
> -import org.apache.catalina.core.AprLifecycleListener;
> +import org.apache.catalina.core.AprStatus;
>  import org.apache.catalina.util.LifecycleMBeanBase;
>  import org.apache.coyote.AbstractProtocol;
>  import org.apache.coyote.Adapter;
> @@ -80,8 +80,8 @@ public class Connector extends LifecycleMBeanBase  {
>
>
>  public Connector(String protocol) {
> -boolean apr = AprLifecycleListener.isAprAvailable() &&
> -AprLifecycleListener.getUseAprConnector();
> +boolean apr = AprStatus.isAprAvailable() &&
> +AprStatus.getUseAprConnector();
>  ProtocolHandler p = null;
>  try {
>  p = ProtocolHandler.create(protocol, apr);
> @@ -625,7 +625,7 @

Re: Jakarta EE - JASPIC TCK (nightly)

[Jean-Louis MONTEIRO]

Hi,

Small update on the progress.
Passed: 52 and Failed: 9

I had a lot of random passed/failed for quite a while and finally found the
reason yesterday.

I'd be interested in having some thoughts

AuthenticatorBase uses by default CallbackHandlerImpl

The CallbackHandlerImpl will create the GenericPrincipal for the subject
based on the supported callbacks (CallerPrincipalCallback
and GroupPrincipalCallback).

The AuthenticatorBase will pull the GenericPrincipal from the subject and
do the register.

Long story short, the TCK calls the CallbackHandlerImpl twice with the
CallerCallback and another time with CallerCallback + GroupCallback. We end
up having 2 GenericPrincipal in the subject, one with the name only and
another one with the name and roles.

JASPIC TCK
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371

See
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96

Issue is that AuthenticatorBase pulls the first one available. See
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956

It will randomly pull the GenericPrincipal with the name only or the
GenericPrincipal with the name and the roles.

I did a fork in TomEE of the CallbackHandlerImpl to merge the
GenericPrincipal in the name is the same and switched the
CallbackHandlerImpl class in the BasicAuthenticator valve.

Hope it's more or less clear ;-)
Some thoughts would be very helpfup


Le ven. 17 juil. 2020 à 18:21, Mark Thomas  a écrit :

> On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > Following up on this thread.
> > Pretty old I know. Haven't seen more recent topics on JASPIC and Jakarta
> > EE TCK.
> >
> > I tried to invest some time in TomEE to run the JASPIC TCK which is
> > fully relying on Tomcat.
> > I have counted 68 tests under the package com.sun.ts.tests.jaspic
> >
> > The wiki says 100+ so dunno where I'm missing some.
> >
> > Long story short, after some time configuring the thing, I've got
> >
> > Passed: 38
> > Failed: 30
> >
> > Anyone looked at it already since Feb 2019?
>
> I'm probably the most likely candidate and I haven't looked at it.
>
> Mark
>
>
> >
> >
> > Le lun. 11 févr. 2019 à 21:34, Mark Thomas  > > a écrit :
> >
> > All,
> >
> > I've started to look at the Jakarta EE JASPIC TCK.
> >
> > Again a nightly build so usual caveats apply.
> >
> > Progress is being tracked here:
> > https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK
> >
> > Hmm.
> >
> > This TCK seems very different to the standalone TCKs for the other
> specs
> > we implement.
> > - Deployment is significantly more complex. Rather than just WARs
> there
> >   are some JARS that need to be extracted and rename from EARs.
> > - It seems to need the RI up and running for the tests.
> >
> >
> > I'm giving up on this for now. I may come back to it at some point
> but I
> > think it is more likely that I won't.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > 
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > 
> >
> >
> >
> > --
> > Jean-Louis
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

[Bug 64619] Regression: Removal of scratchdir fallback affects existing code

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64619

mgrigorov  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from mgrigorov  ---
This change has been made first in Tomcat 10.x (master) branch and then
downported to 8.5.x to keep the codebases in sync.


Tomcat sets the attribute to the ServletContext at
org.apache.catalina.core.StandardContext#postWorkDirectory(). 

StandardContext is a facade for the implementation of ServletContext. So it
does not matter whether you use a custom impl of ServletContext or not. The
question is: Why org.apache.catalina.core.StandardContext#postWorkDirectory()
is not called in your case ?
postWorkDirectory() is called by
org.apache.catalina.core.StandardContext#startInternal()

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64619] New: Regression: Removal of scratchdir fallback affects existing code

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64619

Bug ID: 64619
   Summary: Regression: Removal of scratchdir fallback affects
existing code
   Product: Tomcat 8
   Version: 8.5.57
  Hardware: PC
Status: NEW
  Severity: minor
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: sch...@gmail.com
  Target Milestone: 

https://github.com/apache/tomcat/commit/6d7e1a00cd706654eca445989d85960cbfba83ac
assumes, that the scratchdir is always set. But this is not necessarily the
case, especially for tomcat embedded.

Adding this code change in a new mayor release along with an entry in the
changelog/releasenotes wouldn't be a problem.
But adding this change in a minor release, without notice in the changelog and
without a real need (it does not fix a bug or security issue) IS a problem. 

Users of Tomcat-embedded should be able to rely on the changelog, such that
applied security fixes can be integrated as fast as possible into the dependent
applications.
Therefore, please don't do unforced refactorings in a minor maintenance
release.

ServletContext is an interface which can have many sorts of implementations. We
use our own implementation of that interface for various reasons. You can not
rely on the assumption, that the Attribute ServletContext.TEMPDIR is always
set.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated: Add code generation for TLD rules

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 9c4b131  Add code generation for TLD rules
9c4b131 is described below

commit 9c4b1318646450b740607e38273a3438fd8e8662
Author: remm 
AuthorDate: Wed Jul 22 10:44:03 2020 +0200

Add code generation for TLD rules
---
 .../util/descriptor/tld/ImplicitTldRuleSet.java|  7 +++
 .../tomcat/util/descriptor/tld/TldRuleSet.java | 51 +-
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
index 21dfe6a..9847be5 100644
--- a/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
@@ -51,6 +51,13 @@ public class ImplicitTldRuleSet implements RuleSet {
 public void begin(String namespace, String name, Attributes 
attributes) {
 TaglibXml taglibXml = (TaglibXml) digester.peek();
 taglibXml.setJspVersion(attributes.getValue("version"));
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(taglibXml)).append(".setJspVersion(\"");
+code.append(attributes.getValue("version")).append("\");");
+code.append(System.lineSeparator());
+}
 }
 });
 digester.addCallMethod(PREFIX + "/shortname", "setShortName", 0);
diff --git a/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
index f298fd3..9af81d2 100644
--- a/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
@@ -50,6 +50,13 @@ public class TldRuleSet implements RuleSet {
 public void begin(String namespace, String name, Attributes 
attributes) {
 TaglibXml taglibXml = (TaglibXml) digester.peek();
 taglibXml.setJspVersion(attributes.getValue("version"));
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(taglibXml)).append(".setJspVersion(\"");
+code.append(attributes.getValue("version")).append("\");");
+code.append(System.lineSeparator());
+}
 }
 });
 digester.addCallMethod(PREFIX + "/shortname", "setShortName", 0);
@@ -137,10 +144,21 @@ public class TldRuleSet implements RuleSet {
 }
 
 private static class TagAttributeRule extends Rule {
+private boolean allowShortNames = false;
 @Override
 public void begin(String namespace, String name, Attributes 
attributes) throws Exception {
 TaglibXml taglibXml = (TaglibXml) 
digester.peek(digester.getCount() - 1);
-digester.push(new 
Attribute("1.2".equals(taglibXml.getJspVersion(;
+allowShortNames = "1.2".equals(taglibXml.getJspVersion());
+Attribute attribute = new Attribute(allowShortNames);
+digester.push(attribute);
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+code.append(TldRuleSet.class.getName()).append(".Attribute 
").append(digester.toVariableName(attribute)).append(" = new ");
+
code.append(TldRuleSet.class.getName()).append(".Attribute").append('(').append(Boolean.toString(allowShortNames));
+code.append(");").append(System.lineSeparator());
+}
 }
 
 @Override
@@ -148,6 +166,13 @@ public class TldRuleSet implements RuleSet {
 Attribute attribute = (Attribute) digester.pop();
 TagXml tag = (TagXml) digester.peek();
 tag.getAttributes().add(attribute.toTagAttributeInfo());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(tag)).append(".getAttributes().add(");
+
code.append(digester.toVariableName(attribute)).append(".toTagAttributeInfo());");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -286,7 +311,15 @@ public class TldRuleSet implements RuleSet {
 private static class ScriptVariableRule extends Rule {
 @Override
 public void begin(String namespace, String name, Attributes 
attributes) throws Exception {
-digester.push(new Variable());
+Variable variable = new Variable();
+digester.pu

[tomcat] branch master updated: Add code generation for TLD rules

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new d467154  Add code generation for TLD rules
d467154 is described below

commit d467154447863ffd9120f0878eeecde711e04d74
Author: remm 
AuthorDate: Wed Jul 22 10:44:03 2020 +0200

Add code generation for TLD rules
---
 .../util/descriptor/tld/ImplicitTldRuleSet.java|  7 +++
 .../tomcat/util/descriptor/tld/TldRuleSet.java | 51 +-
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
index 21dfe6a..9847be5 100644
--- a/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/tld/ImplicitTldRuleSet.java
@@ -51,6 +51,13 @@ public class ImplicitTldRuleSet implements RuleSet {
 public void begin(String namespace, String name, Attributes 
attributes) {
 TaglibXml taglibXml = (TaglibXml) digester.peek();
 taglibXml.setJspVersion(attributes.getValue("version"));
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(taglibXml)).append(".setJspVersion(\"");
+code.append(attributes.getValue("version")).append("\");");
+code.append(System.lineSeparator());
+}
 }
 });
 digester.addCallMethod(PREFIX + "/shortname", "setShortName", 0);
diff --git a/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
index 4f43a47..5a92b1f 100644
--- a/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/tld/TldRuleSet.java
@@ -50,6 +50,13 @@ public class TldRuleSet implements RuleSet {
 public void begin(String namespace, String name, Attributes 
attributes) {
 TaglibXml taglibXml = (TaglibXml) digester.peek();
 taglibXml.setJspVersion(attributes.getValue("version"));
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(taglibXml)).append(".setJspVersion(\"");
+code.append(attributes.getValue("version")).append("\");");
+code.append(System.lineSeparator());
+}
 }
 });
 digester.addCallMethod(PREFIX + "/shortname", "setShortName", 0);
@@ -137,10 +144,21 @@ public class TldRuleSet implements RuleSet {
 }
 
 private static class TagAttributeRule extends Rule {
+private boolean allowShortNames = false;
 @Override
 public void begin(String namespace, String name, Attributes 
attributes) throws Exception {
 TaglibXml taglibXml = (TaglibXml) 
digester.peek(digester.getCount() - 1);
-digester.push(new 
Attribute("1.2".equals(taglibXml.getJspVersion(;
+allowShortNames = "1.2".equals(taglibXml.getJspVersion());
+Attribute attribute = new Attribute(allowShortNames);
+digester.push(attribute);
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+code.append(TldRuleSet.class.getName()).append(".Attribute 
").append(digester.toVariableName(attribute)).append(" = new ");
+
code.append(TldRuleSet.class.getName()).append(".Attribute").append('(').append(Boolean.toString(allowShortNames));
+code.append(");").append(System.lineSeparator());
+}
 }
 
 @Override
@@ -148,6 +166,13 @@ public class TldRuleSet implements RuleSet {
 Attribute attribute = (Attribute) digester.pop();
 TagXml tag = (TagXml) digester.peek();
 tag.getAttributes().add(attribute.toTagAttributeInfo());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVariableName(tag)).append(".getAttributes().add(");
+
code.append(digester.toVariableName(attribute)).append(".toTagAttributeInfo());");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -286,7 +311,15 @@ public class TldRuleSet implements RuleSet {
 private static class ScriptVariableRule extends Rule {
 @Override
 public void begin(String namespace, String name, Attributes 
attributes) throws Exception {
-digester.push(new Variable());
+Variable variable = new Variable();
+digester.

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Rémy Maucherat]

On Tue, Jul 21, 2020 at 11:16 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 098c4c8  Simpler way to determine Graal runtime
> 098c4c8 is described below
>
> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> Author: Filip Hanik 
> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>
> Simpler way to determine Graal runtime
>
> Also, allows to mock the behavior
>
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
> ---
>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
> +---
>  java/org/apache/naming/NamingContext.java | 15 +--
>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
>  3 files changed, 3 insertions(+), 43 deletions(-)
>
> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> index cfb6e75..f27ce3b 100644
> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>   */
>  public class JspRuntimeLibrary {
>
> -public static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
> -// Note: This will also be true for the Graal substrate VM
>

As the comment says, this must also be true when running on the substrate
VM (= building a native image) and from what I can see this is not the
case. Basically the code paths used on Graal must be consistent.
So it's simpler but it doesn't seem to work at this time, so you need to
revert this commit. You could get out of this by saying the user can just
set the system property, but this makes things more error prone so it's a
bad idea as the previous solution worked just fine.

I see an enhancement to fix this as the agent would set the system
property: https://github.com/oracle/graal/issues/2395
But the Oracle folks said "no" because they can. As usual :D

Rémy


> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +public static final boolean GRAAL =
> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>
>  /**
>   * Returns the value of the jakarta.servlet.error.exception request
> diff --git a/java/org/apache/naming/NamingContext.java
> b/java/org/apache/naming/NamingContext.java
> index 0471279..40f4085 100644
> --- a/java/org/apache/naming/NamingContext.java
> +++ b/java/org/apache/naming/NamingContext.java
> @@ -792,20 +792,7 @@ public class NamingContext implements Context {
>  // -- Protected
> Methods
>
>
> -private static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +private static final boolean GRAAL =
> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>
>  /**
>   * Retrieves the named object.
> diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java
> b/java/org/apache/tomcat/util/compat/GraalCompat.java
> index 9fb835a..e3cb09d 100644
> --- a/java/org/apache/tomcat/util/compat/GraalCompat.java
> +++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
> @@ -20,20 +20,7 @@ import java.io.IOException;
>
>  class GraalCompat extends Jre9Compat {
>
> -private static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode").invoke(null));
> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +private static final boolean GRAAL =
> System.getProperty("o