date:20200721



markt-asf commented on a change in pull request #32:
URL: https://github.com/apache/tomcat-maven-plugin/pull/32#discussion_r458305303



##
File path: tomcat8-maven-plugin/pom.xml
##
@@ -137,12 +137,12 @@
 
   org.apache.tomcat.embed
   tomcat-embed-logging-juli
-  ${tomcat8Version}
+  ${tomcat8LoggingVersion}
 
 
   org.apache.tomcat.embed
   tomcat-embed-logging-log4j
-  ${tomcat8Version}
+  ${tomcat8LoggingVersion}
 
 

Review comment:
   These dependencies should be removed. They are no longer used in 8.5.x





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

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

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
-} 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("org.graalvm.nativeimage.imagecode") != null;
 
 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

[GitHub] [tomcat] rotty3000 commented on pull request #323: fix module names to reflect Jakarta EE origin



rotty3000 commented on pull request #323:
URL: https://github.com/apache/tomcat/pull/323#issuecomment-662054802


   I saw :)



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

[GitHub] [tomcat] markt-asf commented on pull request #323: fix module names to reflect Jakarta EE origin



markt-asf commented on pull request #323:
URL: https://github.com/apache/tomcat/pull/323#issuecomment-662032441


   Heads up. The Jakarta EE JPMS names are currently a moving target. At least 
one person thinks there is a policy that the JPMS names should not have the 
".api" on the end. I am trying to get clarification on the position because as 
far as I am aware there is no official policy. We have plenty of time so I 
suggest we wait for Jakarta EE to stabilise and then align our names with 
theirs.



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

[GitHub] [tomcat-maven-plugin] liudongmiao opened a new pull request #32: support tomcat 8.5



liudongmiao opened a new pull request #32:
URL: https://github.com/apache/tomcat-maven-plugin/pull/32


   



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: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

Just FYI, I found that if I build when the aqute-bnd and aqute-bndlib
packages are installed from Fedora (version 3.5) then the classes are *not*
included in the jar, but if I remove them and use the aqute-bnd version
that tomcat requires (version 5.1) then they are present.

On Tue, Jul 21, 2020 at 10:26 AM Raymond Auge
 wrote:

> Hey all,
>
> Thanks for looking into this. I made sure using a binary comparison tool
> that the jars did in fact contained the correct bits before and after all
> my changes.
>
> But Mark is correct that some of the previously private packages are
> actually used externally and I had some changes coming to deal with those
> (but presently I'm on vacation so thanks for handling some of those those
> Mark.)
>
> Sincerely,
> - Ray
>
> On Tue, Jul 21, 2020 at 9:51 AM Coty Sutherland 
> wrote:
>
>> 
>>
>> That looks like an issue that will need fixing in Fedora's build system.
>>> Annotation scanning and the multipart upload API will be broken if those
>>> packages are missing.
>>>
>>
>> Hm, OK. I'll look into that and I guess other changes to ensure the
>> Fedora build isn't breaking stuff. I need to figure out why the step is
>> removing the classes and fix that issue since it doesn't seem to affect our
>> binary distro :(
>>
>> Going back to the fix I applied. The JSSE package was being used
>>> externally so that change looks to be OK. The modeler.modules package
>>> was not so I'm currently leaning towards reverting that part of the
>>> change.
>>>
>>> Overall, I don't mind exposing these packages externally if necessary
>>> but I'd prefer not to expose them if we don't have to.
>>>
>>
>> I agree and I'm fine with reverting your fix (I think) and continuing
>> with the patch I've applied in Fedora to keep that working. It's noteworthy
>> to mention again though that Debian had the same issue too, so whatever the
>> issue is that's causing the classes to be removed isn't just a Fedora
>> problem.
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
>

Re: Changing the name of the default branch in our git repos

2020-07-21 Thread Violeta Georgieva

На пт, 26.06.2020 г. в 23:41 Rémy Maucherat  написа:
>
> On Fri, Jun 26, 2020 at 4:48 PM Mark Thomas  wrote:
>>
>> Hi,
>>
>> Picking up this thread again I see a range of views. "main" seems to be
>> the most popular although several folks suggested "10.0.x" and "use
>> whatever GitHub use". There was also interest in "trunk". Particularly
>> with the additional suggestion of "10.0.x" appearing in the middle of
>> the discussion, I'm not sure where consensus lies at the moment.
>
>
> I was used to trunk :)

It seems GitHub has some plans for the renaming
https://github.com/github/renaming

Violeta

>
> Rémy
>
>>
>>
>> One suggestion I particularly liked was to do the rename at the point we
>> branch 10.0.x and start on 10.1.x since we will need to be updating CI
>> and various things anyway. That is currently looking like September as
>> that is the target date for the Jakarta EE 9 release.
>>
>> I suspect that this could get tricky as I'd prefer "main" or "10.0.x",
>> could work with "trunk" but really don't want to continue with "master".
>> I imagine others have similar views in different combinations. Maybe if
>> others express their views in a similar way to the above we'll end up
>> with a natural consensus. If not, we'll have to figure something out.
>>
>> Mark
>>
>>
>>
>> On 19/06/2020 16:32, Emmanuel Bourg wrote:
>> > Le 16/06/2020 à 10:02, Mark Thomas a écrit :
>> >
>> >> Thoughts?
>> >
>> > I'd prefer the status-quo and keep "master", I've always understood
this
>> > as the 'master record' (I know it might be historically wrong) and I
>> > haven't seen evidences it has ever offended or deterred anyone from
>> > contributing.
>> >
>> > If there is a consensus to change I suggest waiting to see what GitHub
>> > plans to do. The "master" name is a de-facto standard for Git
>> > repositories, and I think we should remain consistent with the new name
>> > that will be popularized by GitHub.
>> >
>> > That said, I have a preference for "main".
>> >
>> > Emmanuel Bourg
>> >
>> > -
>> > 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

[GitHub] [tomcat-maven-plugin] liudongmiao commented on pull request #32: support tomcat 8.5



liudongmiao commented on pull request #32:
URL: 
https://github.com/apache/tomcat-maven-plugin/pull/32#issuecomment-662209229


   Thanks for review.
   
   However, I cannot make run-its works well, even tomcat7-maven-plugin doesn't 
work on my devices.



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

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



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



##
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:
   original internal path is `""`, and set to `getPath()`, please verify as 
`"/"`, or `getPath()`.





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

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

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 @@ public class Connector extends LifecycleMBeanBase  {
  * @return the Coyote protocol handler in use.
  */
 public String getProtocol() {
-boolean apr = AprLifecycleListener.getUseAprConnector();

[tomcat] branch 9.0.x updated: Parent classloader has to be resolved first.

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 77efc02  Parent classloader has to be resolved first.
77efc02 is described below

commit 77efc025aca11e63d40dd758538a436c18edf96f
Author: Filip Hanik 
AuthorDate: Tue Jul 21 16:18:09 2020 -0700

Parent classloader has to be resolved first.

missing commit.
---
 java/org/apache/catalina/loader/WebappLoader.java | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/java/org/apache/catalina/loader/WebappLoader.java 
b/java/org/apache/catalina/loader/WebappLoader.java
index 0dc64ed..95d70c2 100644
--- a/java/org/apache/catalina/loader/WebappLoader.java
+++ b/java/org/apache/catalina/loader/WebappLoader.java
@@ -507,6 +507,12 @@ public class WebappLoader extends LifecycleMBeanBase
 private WebappClassLoaderBase createClassLoader()
 throws Exception {
 
+if (parentClassLoader == null) {
+parentClassLoader = context.getParentClassLoader();
+} else {
+context.setParentClassLoader(parentClassLoader);
+}
+
 if (ParallelWebappClassLoader.class.getName().equals(loaderClass)) {
 return new ParallelWebappClassLoader(parentClassLoader);
 }
@@ -514,11 +520,6 @@ public class WebappLoader extends LifecycleMBeanBase
 Class clazz = Class.forName(loaderClass);
 WebappClassLoaderBase classLoader = null;
 
-if (parentClassLoader == null) {
-parentClassLoader = context.getParentClassLoader();
-} else {
-context.setParentClassLoader(parentClassLoader);
-}
 Class[] argTypes = { ClassLoader.class };
 Object[] args = { parentClassLoader };
 Constructor constr = clazz.getConstructor(argTypes);


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

[tomcat] 01/02: Simpler way to determine Graal runtime

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 6a73695fa6d024ed9fc4adeb32073cbd94309c51
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 c0a7a63..d710f84 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
-} 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 javax.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("org.graalvm.nativeimage.imagecode") != null;
 
 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 (5157388 -> f4dac68)

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

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


from 5157388  fix module names to reflect Java EE origin
 new 6a73695  Simpler way to determine Graal runtime
 new f4dac68  Avoid reflection for default instantiation

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../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 ++-
 .../apache/jasper/runtime/JspRuntimeLibrary.java   | 16 +
 java/org/apache/naming/NamingContext.java  | 15 +
 .../org/apache/tomcat/util/compat/GraalCompat.java | 15 +
 11 files changed, 122 insertions(+), 79 deletions(-)
 create mode 100644 java/org/apache/catalina/core/AprStatus.java


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

[GitHub] [tomcat] markt-asf commented on a change in pull request #323: fix module names to reflect Jakarta EE origin



markt-asf commented on a change in pull request #323:
URL: https://github.com/apache/tomcat/pull/323#discussion_r458009648



##
File path: res/bnd/catalina.jar.tmp.bnd
##
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+jakarta.ejb.api,\
+jakarta.mail.api,\

Review comment:
   Jakarta Mail has opted for `jakarta.mail`

##
File path: res/bnd/catalina.jar.tmp.bnd
##
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+jakarta.ejb.api,\
+jakarta.mail.api,\
+jakarta.persistence.api,\
+jakarta.xml.rpc.api,\
+jakarta.xml.ws.api'

Review comment:
   Jakarta XMl WS opted for `jakarta.xml.ws`

##
File path: res/bnd/catalina.jar.tmp.bnd
##
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+jakarta.ejb.api,\

Review comment:
   Jakarta Enterprise Beans 4.0.0-RC2  does not define a module name so I 
think we are OK with this for now.

##
File path: res/bnd/catalina.jar.tmp.bnd
##
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+jakarta.ejb.api,\
+jakarta.mail.api,\
+jakarta.persistence.api,\

Review comment:
   Jakarta Persistence has opted for `jakarta.persistence`

##
File path: res/bnd/jaspic-api.jar.tmp.bnd
##
@@ -35,9 +35,9 @@ Provide-Capability: \
 Implementation-Vendor=Apache Software Foundation
 
 -jpms-module-info: \
-jakarta.security.enterprise;\
+jakarta.security.enterprise.api;\

Review comment:
   The most recent RC (2.0.0-RC2) doesn't define a module name so this 
should be OK for now.

##
File path: res/bnd/annotations-api.jar.tmp.bnd
##
@@ -35,9 +35,9 @@ Provide-Capability: \
 Implementation-Vendor=Apache Software Foundation
 
 -jpms-module-info: \
-jakarta.annotation;\
+jakarta.annotation.api;\
 access=32;\
 version=${annotation.spec.version}
 -jpms-module-info-options: \
-jakarta.annotation;\
+jakarta.annotation.api;\
 substitute=annotations-api

Review comment:
   This change is not required. Jakarta Annotation API has chosen 
`jakarta.annotation`

##
File path: res/bnd/catalina.jar.tmp.bnd
##
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+jakarta.ejb.api,\
+jakarta.mail.api,\
+jakarta.persistence.api,\
+jakarta.xml.rpc.api,\

Review comment:
   XML RPC has been dropped in Jakarta EE 9. We'll need to clean that up in 
Tomcat. I guess this one can stay as is for now.





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

JAX-RPC and Tomcat 10

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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On 21/07/2020 12:43, Coty Sutherland wrote:
> Hi Mark,
> 
> On Tue, Jul 21, 2020 at 4:48 AM Mark Thomas  > wrote:
> 
> On 20/07/2020 18:20, Coty Sutherland wrote:
> > This commit is problematic :( It's broken some projects that depend on
> > Tomcat because now the tomcat-coyote.jar doesn't contain the
> > org.apache.tomcat.util.net .jsse or
> > org.apache.tomcat.util.modeler.modules packages which results in
> > ClassNotFoundExceptions. I haven't seen any issues with other jars
> yet.
> > The removal of those packages from the jar looks intentional, but we
> > aren't providing the classes anywhere else for users to use which is
> > causing problems. Thoughts?
> 
> Those packages are still present.
> 
> 
> It seems that removing the packages from the exported packages list
> actually removed them completely from the tomcat-coyote.jar (I
> decompiled it to look and they were not present, nor were they included
> in any other jars).

I've just checked the 9.0.37 binaries and those packages (and the
classes they contain) are present in tomcat-coyote.jar.

I saw the same when I built 10.0.x locally (before my fix).

>From where did you obtain a JAR where those classes were missing?

> Thanks for looking into it, the fix you did was the same patch that I
> added yesterday
> (https://src.fedoraproject.org/rpms/tomcat/c/a8c5ea85614dca66b492fe030a7e7cfc10cd52de?branch=master)
> :) I wish I'd proposed it upstream now, I just wasn't sure what the
> criteria was for not exporting the packages.
> 
> The packages that were pointed out to me as broken are FreeIPA server
> (https://bugzilla.redhat.com/show_bug.cgi?id=1857043) and Debian's
> libtomcat9-java package
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964433), both with
> different CNFEs.

Tx. I'm curious as whether the root cause was missing classes or missing
exports - but that depends on figuring out why the classes were missing
first.

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

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

--- Comment #8 from Christopher Schultz  ---
Seems like an awful hack.

Perhaps instead we should have a configuration attribute like
dontWrapKeyManager="true|false" and them simply do not wrap in the first place.
Or is the wrapping required for other things?

-- 
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] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On Tue, Jul 21, 2020 at 7:52 AM Mark Thomas  wrote:

> On 21/07/2020 12:43, Coty Sutherland wrote:
> > Hi Mark,
> >
> > On Tue, Jul 21, 2020 at 4:48 AM Mark Thomas  > > wrote:
> >
> > On 20/07/2020 18:20, Coty Sutherland wrote:
> > > This commit is problematic :( It's broken some projects that
> depend on
> > > Tomcat because now the tomcat-coyote.jar doesn't contain the
> > > org.apache.tomcat.util.net .jsse
> or
> > > org.apache.tomcat.util.modeler.modules packages which results in
> > > ClassNotFoundExceptions. I haven't seen any issues with other jars
> > yet.
> > > The removal of those packages from the jar looks intentional, but
> we
> > > aren't providing the classes anywhere else for users to use which
> is
> > > causing problems. Thoughts?
> >
> > Those packages are still present.
> >
> >
> > It seems that removing the packages from the exported packages list
> > actually removed them completely from the tomcat-coyote.jar (I
> > decompiled it to look and they were not present, nor were they included
> > in any other jars).
>
> I've just checked the 9.0.37 binaries and those packages (and the
> classes they contain) are present in tomcat-coyote.jar.
>
> I saw the same when I built 10.0.x locally (before my fix).
>
> From where did you obtain a JAR where those classes were missing?
>

Oh yeah, you're right. They were included in the ASF binaries, but Fedora
(and Debian I guess) built their own bits and that's where the classes came
up missing. I wasn't able to identify *why* the classes weren't present,
only that it was the OSGi step that was removing them. I thought initially
that it was because the Fedora version of aqute-bnd in use is 3.5, but I
don't see the classes in my local build from the 9.0.37 tag (using bnd 5.1)
either.


> > Thanks for looking into it, the fix you did was the same patch that I
> > added yesterday
> > (
> https://src.fedoraproject.org/rpms/tomcat/c/a8c5ea85614dca66b492fe030a7e7cfc10cd52de?branch=master
> )
> > :) I wish I'd proposed it upstream now, I just wasn't sure what the
> > criteria was for not exporting the packages.
> >
> > The packages that were pointed out to me as broken are FreeIPA server
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1857043) and Debian's
> > libtomcat9-java package
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964433), both with
> > different CNFEs.
>
> Tx. I'm curious as whether the root cause was missing classes or missing
> exports - but that depends on figuring out why the classes were missing
> first.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

Hi Mark,

On Tue, Jul 21, 2020 at 4:48 AM Mark Thomas  wrote:

> On 20/07/2020 18:20, Coty Sutherland wrote:
> > This commit is problematic :( It's broken some projects that depend on
> > Tomcat because now the tomcat-coyote.jar doesn't contain the
> > org.apache.tomcat.util.net.jsse or
> > org.apache.tomcat.util.modeler.modules packages which results in
> > ClassNotFoundExceptions. I haven't seen any issues with other jars yet.
> > The removal of those packages from the jar looks intentional, but we
> > aren't providing the classes anywhere else for users to use which is
> > causing problems. Thoughts?
>
> Those packages are still present.
>

It seems that removing the packages from the exported packages list
actually removed them completely from the tomcat-coyote.jar (I decompiled
it to look and they were not present, nor were they included in any other
jars).

> Do you mean those packages are no longer listed as exported in the OSGi
> / JPMS meta-data? The following packages are currently listed as private
> (and I assume the JPMS metadata is the same):

> org.apache.tomcat.util.bcel
> org.apache.tomcat.util.http.fileupload.impl
> org.apache.tomcat.util.http.fileupload.util.mime
> org.apache.tomcat.util.modeler.modules
> org.apache.tomcat.util.net.jsse
>
> It should be fairly easy to get that fixed.
>
> Out of curiosity, what projects are broken? I'm surprised that something
> has dependencies that deep into Tomcat's internals. Is this an OSGi
> dependency or JPMS?
>

Thanks for looking into it, the fix you did was the same patch that I added
yesterday (
https://src.fedoraproject.org/rpms/tomcat/c/a8c5ea85614dca66b492fe030a7e7cfc10cd52de?branch=master)
:) I wish I'd proposed it upstream now, I just wasn't sure what the
criteria was for not exporting the packages.

The packages that were pointed out to me as broken are FreeIPA server (
https://bugzilla.redhat.com/show_bug.cgi?id=1857043) and Debian's
libtomcat9-java package (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964433), both with
different CNFEs.

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

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

--- Comment #7 from jfclere  ---
Created attachment 37367
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37367=edit
improved? patch.

Check for FIPS to prevent regressions...

-- 
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] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On 20/07/2020 18:20, Coty Sutherland wrote:
> This commit is problematic :( It's broken some projects that depend on
> Tomcat because now the tomcat-coyote.jar doesn't contain the
> org.apache.tomcat.util.net.jsse or
> org.apache.tomcat.util.modeler.modules packages which results in
> ClassNotFoundExceptions. I haven't seen any issues with other jars yet.
> The removal of those packages from the jar looks intentional, but we
> aren't providing the classes anywhere else for users to use which is
> causing problems. Thoughts?

Those packages are still present.

Do you mean those packages are no longer listed as exported in the OSGi
/ JPMS meta-data? The following packages are currently listed as private
(and I assume the JPMS metadata is the same):

org.apache.tomcat.util.bcel
org.apache.tomcat.util.http.fileupload.impl
org.apache.tomcat.util.http.fileupload.util.mime
org.apache.tomcat.util.modeler.modules
org.apache.tomcat.util.net.jsse

It should be fairly easy to get that fixed.

Out of curiosity, what projects are broken? I'm surprised that something
has dependencies that deep into Tomcat's internals. Is this an OSGi
dependency or JPMS?

Mark

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

[tomcat] branch master updated (17dab7a -> 577d39f)

2020-07-21 Thread remm

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

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


from 17dab7a  Fix regression in fix for BZ 64540.
 add 577d39f  Add a dedicated loader for generated code

No new revisions were added by this update.

Summary of changes:
 java/org/apache/catalina/startup/Catalina.java | 59 +++---
 .../org/apache/catalina/startup/ContextConfig.java | 21 +++-
 .../catalina/startup/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/util/digester/Digester.java | 34 +
 webapps/docs/changelog.xml |  4 ++
 5 files changed, 98 insertions(+), 21 deletions(-)


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

[tomcat] branch master updated: Fix regression in fix for BZ 64540.

2020-07-21 Thread 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 17dab7a  Fix regression in fix for BZ 64540.
17dab7a is described below

commit 17dab7aa40e721c4a854bdbe468eb837ba153357
Author: Mark Thomas 
AuthorDate: Tue Jul 21 10:04:19 2020 +0100

Fix regression in fix for BZ 64540.

Export additional packages,
---
 res/bnd/tomcat-coyote.jar.tmp.bnd |  6 +++---
 webapps/docs/changelog.xml| 10 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/res/bnd/tomcat-coyote.jar.tmp.bnd 
b/res/bnd/tomcat-coyote.jar.tmp.bnd
index 6d0ee68..0f9314a 100644
--- a/res/bnd/tomcat-coyote.jar.tmp.bnd
+++ b/res/bnd/tomcat-coyote.jar.tmp.bnd
@@ -33,16 +33,16 @@ Export-Package: \
 org.apache.tomcat.util.http.parser,\
 org.apache.tomcat.util.log,\
 org.apache.tomcat.util.modeler,\
+org.apache.tomcat.util.modeler.modules,\
 org.apache.tomcat.util.net,\
+org.apache.tomcat.util.net.jsse,\
 org.apache.tomcat.util.net.openssl,\
 org.apache.tomcat.util.net.openssl.ciphers
 
 -includepackage: \
 org.apache.tomcat.util.bcel,\
 org.apache.tomcat.util.http.fileupload.impl,\
-org.apache.tomcat.util.http.fileupload.util.mime,\
-org.apache.tomcat.util.modeler.modules,\
-org.apache.tomcat.util.net.jsse
+org.apache.tomcat.util.http.fileupload.util.mime
 
 -jpms-module-info: \
 ${module.name};\
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 059bf26..7dbce3c 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -107,6 +107,16 @@
   
 
   
+  
+
+  
+Correct a regression in the fix for 64540 and include
+org.apache.tomcat.util.modeler.modules and
+org.apache.tomcat.util.net.jsse in the list of exported
+packages. (markt)
+  
+
+  
 
 
   


-
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: Fix regression in fix for BZ 64540.

2020-07-21 Thread 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 1366462  Fix regression in fix for BZ 64540.
1366462 is described below

commit 13664621a2b4c9af09641a69438b2cf411238ca4
Author: Mark Thomas 
AuthorDate: Tue Jul 21 10:04:19 2020 +0100

Fix regression in fix for BZ 64540.

Export additional packages,
---
 res/bnd/tomcat-coyote.jar.tmp.bnd |  6 +++---
 webapps/docs/changelog.xml| 10 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/res/bnd/tomcat-coyote.jar.tmp.bnd 
b/res/bnd/tomcat-coyote.jar.tmp.bnd
index 6d0ee68..0f9314a 100644
--- a/res/bnd/tomcat-coyote.jar.tmp.bnd
+++ b/res/bnd/tomcat-coyote.jar.tmp.bnd
@@ -33,16 +33,16 @@ Export-Package: \
 org.apache.tomcat.util.http.parser,\
 org.apache.tomcat.util.log,\
 org.apache.tomcat.util.modeler,\
+org.apache.tomcat.util.modeler.modules,\
 org.apache.tomcat.util.net,\
+org.apache.tomcat.util.net.jsse,\
 org.apache.tomcat.util.net.openssl,\
 org.apache.tomcat.util.net.openssl.ciphers
 
 -includepackage: \
 org.apache.tomcat.util.bcel,\
 org.apache.tomcat.util.http.fileupload.impl,\
-org.apache.tomcat.util.http.fileupload.util.mime,\
-org.apache.tomcat.util.modeler.modules,\
-org.apache.tomcat.util.net.jsse
+org.apache.tomcat.util.http.fileupload.util.mime
 
 -jpms-module-info: \
 ${module.name};\
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 11916b2..cc357a1 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -103,6 +103,16 @@
   
 
   
+  
+
+  
+Correct a regression in the fix for 64540 and include
+org.apache.tomcat.util.modeler.modules and
+org.apache.tomcat.util.net.jsse in the list of exported
+packages. (markt)
+  
+
+  
 
 
   


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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On 21/07/2020 09:47, Mark Thomas wrote:
> On 20/07/2020 18:20, Coty Sutherland wrote:
>> This commit is problematic :( It's broken some projects that depend on
>> Tomcat because now the tomcat-coyote.jar doesn't contain the
>> org.apache.tomcat.util.net.jsse or
>> org.apache.tomcat.util.modeler.modules packages which results in
>> ClassNotFoundExceptions. I haven't seen any issues with other jars yet.
>> The removal of those packages from the jar looks intentional, but we
>> aren't providing the classes anywhere else for users to use which is
>> causing problems. Thoughts?
> 
> Those packages are still present.
> 
> Do you mean those packages are no longer listed as exported in the OSGi
> / JPMS meta-data? The following packages are currently listed as private
> (and I assume the JPMS metadata is the same):
> 
> org.apache.tomcat.util.bcel
> org.apache.tomcat.util.http.fileupload.impl
> org.apache.tomcat.util.http.fileupload.util.mime
> org.apache.tomcat.util.modeler.modules
> org.apache.tomcat.util.net.jsse
> 
> It should be fairly easy to get that fixed.

I think I've fixed this. Let me know how you get on with 10.0.x / 9.0.x

Mark


> 
> Out of curiosity, what projects are broken? I'm surprised that something
> has dependencies that deep into Tomcat's internals. Is this an OSGi
> dependency or JPMS?
> 
> 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

[tomcat] branch 9.0.x updated: Add a dedicated loader for generated code

2020-07-21 Thread 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 b8669f7  Add a dedicated loader for generated code
b8669f7 is described below

commit b8669f777de284d18a55993afb0e4847a35c195b
Author: remm 
AuthorDate: Tue Jul 21 11:19:07 2020 +0200

Add a dedicated loader for generated code

This avoids dynamic classloading, and calling the classaloder for not
found xml.
---
 java/org/apache/catalina/startup/Catalina.java | 59 +++---
 .../org/apache/catalina/startup/ContextConfig.java | 21 +++-
 .../catalina/startup/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/util/digester/Digester.java | 34 +
 webapps/docs/changelog.xml |  4 ++
 5 files changed, 98 insertions(+), 21 deletions(-)

diff --git a/java/org/apache/catalina/startup/Catalina.java 
b/java/org/apache/catalina/startup/Catalina.java
index 9683df9..134a236 100644
--- a/java/org/apache/catalina/startup/Catalina.java
+++ b/java/org/apache/catalina/startup/Catalina.java
@@ -554,8 +554,30 @@ public class Catalina {
 ConfigFileLoader.setSource(new 
CatalinaBaseConfigurationSource(Bootstrap.getCatalinaBaseFile(), 
getConfigFile()));
 File file = configFile();
 
+if (useGeneratedCode && !Digester.isGeneratedCodeLoaderSet()) {
+// Load loader
+String loaderClassName = generatedCodePackage + 
".DigesterGeneratedCodeLoader";
+try {
+Digester.GeneratedCodeLoader loader =
+(Digester.GeneratedCodeLoader) 
Catalina.class.getClassLoader().loadClass(loaderClassName).newInstance();
+Digester.setGeneratedCodeLoader(loader);
+} catch (Exception e) {
+if (log.isDebugEnabled()) {
+log.info(sm.getString("catalina.noLoader", 
loaderClassName), e);
+} else {
+log.info(sm.getString("catalina.noLoader", 
loaderClassName));
+}
+// No loader so don't use generated code
+useGeneratedCode = false;
+}
+}
+
 // Init source location
 File serverXmlLocation = null;
+String xmlClassName = null;
+if (generateCode || useGeneratedCode) {
+xmlClassName = start ? generatedCodePackage + ".ServerXml" : 
generatedCodePackage + ".ServerXmlStop";
+}
 if (generateCode) {
 if (generatedCodeLocationParameter != null) {
 generatedCodeLocation = new 
File(generatedCodeLocationParameter);
@@ -575,12 +597,7 @@ public class Catalina {
 
 ServerXml serverXml = null;
 if (useGeneratedCode) {
-String xmlClassName = start ? generatedCodePackage + ".ServerXml" 
: generatedCodePackage + ".ServerXmlStop";
-try {
-serverXml = (ServerXml) 
Catalina.class.getClassLoader().loadClass(xmlClassName).newInstance();
-} catch (Exception e) {
-// Ignore, no generated code found
-}
+serverXml = (ServerXml) Digester.loadGeneratedClass(xmlClassName);
 }
 
 if (serverXml != null) {
@@ -605,6 +622,7 @@ public class Catalina {
 writer.write(digester.getGeneratedCode().toString());
 }
 digester.endGeneratingCode();
+Digester.addGeneratedClass(xmlClassName);
 }
 } catch (Exception e) {
 log.warn(sm.getString("catalina.configFail", 
file.getAbsolutePath()), e);
@@ -766,6 +784,11 @@ public class Catalina {
 log.info(sm.getString("catalina.startup", 
Long.toString(TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - t1;
 }
 
+if (generateCode) {
+// Generate loader which will load all generated classes
+generateLoader();
+}
+
 // Register shutdown hook
 if (useShutdownHook) {
 if (shutdownHook == null) {
@@ -908,6 +931,30 @@ public class Catalina {
 }
 
 
+protected void generateLoader() {
+String loaderClassName = "DigesterGeneratedCodeLoader";
+StringBuilder code = new StringBuilder();
+code.append("package 
").append(generatedCodePackage).append(";").append(System.lineSeparator());
+code.append("public class ").append(loaderClassName);
+code.append(" implements 
org.apache.tomcat.util.digester.Digester.GeneratedCodeLoader 
{").append(System.lineSeparator());
+code.append("public Object loadGeneratedCode(String className) 
{").append(System.lineSeparator());
+code.append("switch (className) {").append(System.lineSeparator());
+for (String generatedClassName : Digester.getGeneratedClasses()) {
+

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

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

--- Comment #6 from jfclere  ---







Note the ciphers list is needed for FIPS.

-- 
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

[GitHub] [tomcat] stokito commented on a change in pull request #316: Use lowercase HTML tags and attributes. Add quotes around attributes.



stokito commented on a change in pull request #316:
URL: https://github.com/apache/tomcat/pull/316#discussion_r457980335



##
File path: webapps/ROOT/index.jsp
##
@@ -25,11 +25,11 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
 
 
 
-
+
 <%=request.getServletContext().getServerInfo() %>
-
-
-
+

Review comment:
   in fact we can remove the line but the favicon.ico will be anyway 
requested by a browser. The tag makes sense when the file name is another





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: JAX-RPC and Tomcat 10

2020-07-21 Thread Romain Manni-Bucau

Hi Mark,

e) c as default + add a toggle to behave as a? (thinking to container
extending tomcat where this shouldn't fail probably)

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
>
>

Re: JAX-RPC and Tomcat 10

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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.



That looks like an issue that will need fixing in Fedora's build system.
> Annotation scanning and the multipart upload API will be broken if those
> packages are missing.
>

Hm, OK. I'll look into that and I guess other changes to ensure the Fedora
build isn't breaking stuff. I need to figure out why the step is removing
the classes and fix that issue since it doesn't seem to affect our binary
distro :(

Going back to the fix I applied. The JSSE package was being used
> externally so that change looks to be OK. The modeler.modules package
> was not so I'm currently leaning towards reverting that part of the change.
>
> Overall, I don't mind exposing these packages externally if necessary
> but I'd prefer not to expose them if we don't have to.
>

I agree and I'm fine with reverting your fix (I think) and continuing with
the patch I've applied in Fedora to keep that working. It's noteworthy to
mention again though that Debian had the same issue too, so whatever the
issue is that's causing the classes to be removed isn't just a Fedora
problem.

[Bug 64540] switch from bndwrap task to bnd task

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

--- Comment #4 from rotty3000  ---
For the record, this was not really a bug. The packages were in fact in the
jar. I confirmed with a binary check before and after the change and the jar is
unchanged except for the manifest and the module-info.class

-- 
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 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

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

--- Comment #9 from Remy Maucherat  ---
(In reply to Christopher Schultz from comment #8)
> Seems like an awful hack.
> 
> Perhaps instead we should have a configuration attribute like
> dontWrapKeyManager="true|false" and them simply do not wrap in the first
> place. Or is the wrapping required for other things?

If there's really a need to avoid wrapping when FIPS is used, then it should be
done here:
https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/net/SSLUtilBase.java#L369
(using a new abstract method to detect FIPS JSSE)
But there's probably no need for new explicit configuration, if it won't work.
And log something if wrapping was desired but cannot be done due to FIPS.

So context.getProvider().getInfo().indexOf("FIPS") != -1 is a 100% correct way
to test for FIPS ?

-- 
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: fix module names to reflect Java EE origin

2020-07-21 Thread rotty3000

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

rotty3000 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 5157388  fix module names to reflect Java EE origin
5157388 is described below

commit 515738866dc732e68121364dbaa84406f7a6d0c9
Author: Raymond Augé 
AuthorDate: Tue Jul 14 17:31:43 2020 -0400

fix module names to reflect Java EE origin

Signed-off-by: Raymond Augé 
---
 res/bnd/annotations-api.jar.tmp.bnd   |  4 ++--
 res/bnd/catalina.jar.tmp.bnd  | 20 ++--
 res/bnd/el-api.jar.tmp.bnd|  4 ++--
 res/bnd/jaspic-api.jar.tmp.bnd|  4 ++--
 res/bnd/jsp-api.jar.tmp.bnd   |  4 ++--
 res/bnd/servlet-api.jar.tmp.bnd   |  4 ++--
 res/bnd/tomcat-embed-core.jar.tmp.bnd | 20 ++--
 res/bnd/websocket-api.jar.tmp.bnd |  4 ++--
 8 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/res/bnd/annotations-api.jar.tmp.bnd 
b/res/bnd/annotations-api.jar.tmp.bnd
index e932d93..f21889d 100644
--- a/res/bnd/annotations-api.jar.tmp.bnd
+++ b/res/bnd/annotations-api.jar.tmp.bnd
@@ -35,9 +35,9 @@ Provide-Capability: \
 Specification-Version=1.3
 
 -jpms-module-info: \
-jakarta.annotation;\
+java.annotation;\
 access=32;\
 version=${annotation.spec.version}
 -jpms-module-info-options: \
-jakarta.annotation;\
+java.annotation;\
 substitute=annotations-api
diff --git a/res/bnd/catalina.jar.tmp.bnd b/res/bnd/catalina.jar.tmp.bnd
index 972745c..c3fcab1 100644
--- a/res/bnd/catalina.jar.tmp.bnd
+++ b/res/bnd/catalina.jar.tmp.bnd
@@ -55,15 +55,15 @@ Export-Package: \
 access=32;\
 version=${Bundle-Version};\
 modules='\
-jakarta.ejb-api,\
-jakarta.mail,\
-jakarta.persistence-api,\
-jakarta.xml.rpc-api,\
-java.xml.ws'
+java.persistence,\
+javax.ejb.api,\
+javax.mail.api,\
+javax.xml.rpc.api,\
+javax.xml.ws'
 -jpms-module-info-options: \
 ${module.name};substitute=catalina,\
-jakarta.ejb-api;static=true,\
-jakarta.mail;static=true,\
-jakarta.persistence-api;static=true,\
-jakarta.xml.rpc-api;static=true,\
-java.xml.ws;static=true
\ No newline at end of file
+java.persistence;static=true,\
+javax.ejb.api;static=true,\
+javax.mail.api;static=true,\
+javax.xml.rpc.api;static=true,\
+javax.xml.ws;static=true
\ No newline at end of file
diff --git a/res/bnd/el-api.jar.tmp.bnd b/res/bnd/el-api.jar.tmp.bnd
index 4c5333e..d81d961 100644
--- a/res/bnd/el-api.jar.tmp.bnd
+++ b/res/bnd/el-api.jar.tmp.bnd
@@ -34,9 +34,9 @@ Provide-Capability: \
 Implementation-Vendor='Apache Software Foundation'
 
 -jpms-module-info: \
-jakarta.el.api;\
+javax.el.api;\
 access=32;\
 version=${el.spec.version}
 -jpms-module-info-options: \
-jakarta.el.api;\
+javax.el.api;\
 substitute=el-api
diff --git a/res/bnd/jaspic-api.jar.tmp.bnd b/res/bnd/jaspic-api.jar.tmp.bnd
index 392a357..e7c44db 100644
--- a/res/bnd/jaspic-api.jar.tmp.bnd
+++ b/res/bnd/jaspic-api.jar.tmp.bnd
@@ -35,9 +35,9 @@ Provide-Capability: \
 Implementation-Vendor='Apache Software Foundation'
 
 -jpms-module-info: \
-jakarta.security.enterprise;\
+javax.security.enterprise.api;\
 access=32;\
 version=${jaspic.spec.version}
 -jpms-module-info-options: \
-jakarta.security.enterprise;\
+javax.security.enterprise.api;\
 substitute=jaspic-api
diff --git a/res/bnd/jsp-api.jar.tmp.bnd b/res/bnd/jsp-api.jar.tmp.bnd
index 4c3630e..e011d76 100644
--- a/res/bnd/jsp-api.jar.tmp.bnd
+++ b/res/bnd/jsp-api.jar.tmp.bnd
@@ -35,9 +35,9 @@ Provide-Capability: \
 Implementation-Vendor='Apache Software Foundation'
 
 -jpms-module-info: \
-jakarta.servlet.jsp;\
+javax.servlet.jsp.api;\
 access=32;\
 version=${jsp.spec.version}
 -jpms-module-info-options: \
-jakarta.servlet.jsp;\
+javax.servlet.jsp.api;\
 substitute=jsp-api
diff --git a/res/bnd/servlet-api.jar.tmp.bnd b/res/bnd/servlet-api.jar.tmp.bnd
index 463b145..8fd76bd 100644
--- a/res/bnd/servlet-api.jar.tmp.bnd
+++ b/res/bnd/servlet-api.jar.tmp.bnd
@@ -39,9 +39,9 @@ Provide-Capability: \
 Implementation-Vendor='Apache Software Foundation'
 
 -jpms-module-info: \
-jakarta.servlet;\
+javax.servlet.api;\
 access=32;\
 version=${servlet.spec.version}
 -jpms-module-info-options: \
-jakarta.servlet;\
+javax.servlet.api;\
 substitute=servlet-api
diff --git a/res/bnd/tomcat-embed-core.jar.tmp.bnd 
b/res/bnd/tomcat-embed-core.jar.tmp.bnd
index 056d9fa..a834809 100644
--- a/res/bnd/tomcat-embed-core.jar.tmp.bnd
+++ b/res/bnd/tomcat-embed-core.jar.tmp.bnd
@@ -131,15 +131,15 @@ Provide-Capability: \
 access=32;\

[GitHub] [tomcat] rotty3000 merged pull request #322: fix module names to reflect Java EE origin



rotty3000 merged pull request #322:
URL: https://github.com/apache/tomcat/pull/322


   



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: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On 21/07/2020 14:06, Coty Sutherland wrote:



> Oh yeah, you're right. They were included in the ASF binaries, but
> Fedora (and Debian I guess) built their own bits and that's where the
> classes came up missing. I wasn't able to identify *why* the classes
> weren't present, only that it was the OSGi step that was removing them.
> I thought initially that it was because the Fedora version of aqute-bnd
> in use is 3.5, but I don't see the classes in my local build from the
> 9.0.37 tag (using bnd 5.1) either.

OK. That means it isn't quite as bad as it could be.

What about the other packages in the original list? Are:

org.apache.tomcat.util.bcel
org.apache.tomcat.util.http.fileupload.impl
org.apache.tomcat.util.http.fileupload.util.mime

still present?

Mark

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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On Tue, Jul 21, 2020 at 9:15 AM Mark Thomas  wrote:

> On 21/07/2020 14:06, Coty Sutherland wrote:
>
> 
>
> > Oh yeah, you're right. They were included in the ASF binaries, but
> > Fedora (and Debian I guess) built their own bits and that's where the
> > classes came up missing. I wasn't able to identify *why* the classes
> > weren't present, only that it was the OSGi step that was removing them.
> > I thought initially that it was because the Fedora version of aqute-bnd
> > in use is 3.5, but I don't see the classes in my local build from the
> > 9.0.37 tag (using bnd 5.1) either.
>
> OK. That means it isn't quite as bad as it could be.
>
> What about the other packages in the original list? Are:
>
> org.apache.tomcat.util.bcel
> org.apache.tomcat.util.http.fileupload.impl
> org.apache.tomcat.util.http.fileupload.util.mime
>
> still present?
>

Nope.

Re: JAX-RPC and Tomcat 10

2020-07-21 Thread Romain Manni-Bucau

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).

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
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > 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
>
>

[GitHub] [tomcat] rotty3000 commented on pull request #323: fix module names to reflect Jakarta EE origin



rotty3000 commented on pull request #323:
URL: https://github.com/apache/tomcat/pull/323#issuecomment-661903666


   See updates.



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: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

On 21/07/2020 14:21, Coty Sutherland wrote:
> On Tue, Jul 21, 2020 at 9:15 AM Mark Thomas  > wrote:
> 
> On 21/07/2020 14:06, Coty Sutherland wrote:
> 
> 
> 
> > Oh yeah, you're right. They were included in the ASF binaries, but
> > Fedora (and Debian I guess) built their own bits and that's where the
> > classes came up missing. I wasn't able to identify *why* the classes
> > weren't present, only that it was the OSGi step that was removing
> them.
> > I thought initially that it was because the Fedora version of
> aqute-bnd
> > in use is 3.5, but I don't see the classes in my local build from the
> > 9.0.37 tag (using bnd 5.1) either.
> 
> OK. That means it isn't quite as bad as it could be.
> 
> What about the other packages in the original list? Are:
> 
> org.apache.tomcat.util.bcel
> org.apache.tomcat.util.http.fileupload.impl
> org.apache.tomcat.util.http.fileupload.util.mime
> 
> still present?
> 
> 
> Nope.

That looks like an issue that will need fixing in Fedora's build system.
Annotation scanning and the multipart upload API will be broken if those
packages are missing.

Going back to the fix I applied. The JSSE package was being used
externally so that change looks to be OK. The modeler.modules package
was not so I'm currently leaning towards reverting that part of the change.

Overall, I don't mind exposing these packages externally if necessary
but I'd prefer not to expose them if we don't have to.

Mark

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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

2020-07-21 Thread Raymond Auge

Hey all,

Thanks for looking into this. I made sure using a binary comparison tool
that the jars did in fact contained the correct bits before and after all
my changes.

But Mark is correct that some of the previously private packages are
actually used externally and I had some changes coming to deal with those
(but presently I'm on vacation so thanks for handling some of those those
Mark.)

Sincerely,
- Ray

On Tue, Jul 21, 2020 at 9:51 AM Coty Sutherland  wrote:

> 
>
> That looks like an issue that will need fixing in Fedora's build system.
>> Annotation scanning and the multipart upload API will be broken if those
>> packages are missing.
>>
>
> Hm, OK. I'll look into that and I guess other changes to ensure the Fedora
> build isn't breaking stuff. I need to figure out why the step is removing
> the classes and fix that issue since it doesn't seem to affect our binary
> distro :(
>
> Going back to the fix I applied. The JSSE package was being used
>> externally so that change looks to be OK. The modeler.modules package
>> was not so I'm currently leaning towards reverting that part of the
>> change.
>>
>> Overall, I don't mind exposing these packages externally if necessary
>> but I'd prefer not to expose them if we don't have to.
>>
>
> I agree and I'm fine with reverting your fix (I think) and continuing with
> the patch I've applied in Fedora to keep that working. It's noteworthy to
> mention again though that Debian had the same issue too, so whatever the
> issue is that's causing the classes to be removed isn't just a Fedora
> problem.
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

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

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

--- Comment #10 from jfclere  ---
kmf.getProvider().getInfo() also gives
"Sun JSSE provider (FIPS mode, crypto provider SunPKCS11-NSSfips"
so indexOf("FIPS") != -1 would also work there.

-- 
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: Native Image - Reflectionless Concept

2020-07-21 Thread Filip Hanik

We've had some discussions around this, mostly high level about where
this could go.

At this point, anyone strongly opposed to ship a light weight jar?

Do we feel the value is or is not there compared to the maintenance of it?

Filip

On 7/13/20 2:59 PM, Filip Hanik wrote:

for discussion, all feedback and questions welcome:

I've created a concept of having Apache Tomcat, embedded, run without
reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that can
be fine tuned to only include what is needed in a default
configuration when an embedded tomcat instance is used and configured
programatically.

Steps to run Apache Tomcat using Java 8 without reflection

1. Make sure you have native-image (from the graal installation) on
your path
2. git clone -b feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
3. cd tomcat/res/graal/
4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M

or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M

This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you can
review the solution to IntrospectionUtils.java

Goals of this concept

1. Do not break anything
2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
3. Remove reflection by introspecting classes that are currently
passed into IntrospectionUtils.set/getProperty by generating
setters/getters at build time

How it's done

1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
2. During build time, it analyses a set of known classes that are
used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:
https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1

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

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

jfclere  changed:

   What|Removed |Added

  Attachment #37364|0   |1
is obsolete||
  Attachment #37367|0   |1
is obsolete||

--- Comment #11 from jfclere  ---
Created attachment 37368
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37368=edit
patch for the 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

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