Re: [tomcat-jakartaee-migration] branch master updated: Fix bug. Constant pool size is defined as u2

[Raymond Auge]

missing requirement
[org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]

Is the jakarta.inject package exported by someone (in the framework)?

I'm not sure how JIRA sets up it's OSGi runtime.

Ray

On Wed, Feb 10, 2021 at 11:42 AM Mark Thomas  wrote:

> On 10/02/2021 10:26, Mark Thomas wrote:
>
> 
>
> > I am still seeing a failure when I start Jira under Tomcat 10. I'm
> > currently investigating the root cause.
>
> I've fixed the simple issues and what I am left with is issues OSGi
> metadata. I've made some progress but hit a brick wall.
>
> Can one of the people more familiar with OSGI give me a pointer or two
> on where the metadata might need fixing to fix this error:
>
> ERROR: Bundle com.atlassian.plugin.osgi.bridge [1] Error starting
>
> file:/home/mark/jira-jakarta/atlassian-jira/WEB-INF/osgi-framework-bundles/atlassian-plugins-osgi-bridge-5.3.11.jar
> (org.osgi.framework.BundleException: Unable to resolve
> com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
> [com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
> [caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
> [6](R 6.0): missing requirement
> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
> requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
> osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))])
> org.osgi.framework.BundleException: Unable to resolve
> com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
> [com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
> [caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
> [6](R 6.0): missing requirement
> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
> requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
> osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))]
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
> at
>
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.lang.Thread.run(Thread.java:748)
>
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

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

Re: Applications setting connection specific HTTP headers

[Raymond Auge]

What about an integration point that acts as a passthrough to such changes
that let you "monitor" and/or "defend" against these operations (using
whatever policy you wish).
The default would be no-op.

- Ray

On Wed, Feb 3, 2021 at 11:15 AM Romain Manni-Bucau 
wrote:

> Le mer. 3 févr. 2021 à 17:10, Mark Thomas  a écrit :
>
> > On 03/02/2021 16:06, Romain Manni-Bucau wrote:
> > > Hi,
> > >
> > > Why not just adding a tomcat-application-fixer module (a more ugly name
> > can
> > > be relevant ;)) application could add in their WEB-INF/lib through web
> > > resource definition (ie plain context.xml config or programmatic
> > > equivalent) which would have a @WebFilter(/*, asyncSupported=true)
> which
> > > would wrap the response to do the fixes you want for these apps but it
> > > wouldnt be seen in the most common case at all (or if there is only
> this
> > > small fix it can be a default filter of tomcat, depends the number of
> > fixes
> > > and related code IMHO).
> >
> > Primarily because of the risk that wrapping the request breaks the
> > application.
> >
> > While a well-behaved app should be unaffected by a Filter adding a
> > wrapped response, we already know that these applications are not
> > well-behaved - else they wouldn't be setting these headers in the first
> > place.
> >
> > Hence I am looking at solutions further down the stack in the Tomcat
> > internals.
> >
>
> So you mean the application uses tomcat internals (like casting the
> Response/Request) but does not work on Tomcat? :s
>
> Otherwise there is no real way a filter and wrapper breaks a "broken"
> application since the application will take the wrapped instance as a
> standard servlet instance - as tomcat already do with its facade layer. The
> only constraint is to ensure the filter is first which can require another
> solution than @WebFilter but web.xml solves it.
>
>
>
> >
> > Mark
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mer. 3 févr. 2021 à 16:50, Rémy Maucherat  a
> écrit :
> > >
> > >> On Wed, Feb 3, 2021 at 1:03 PM Mark Thomas  wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> We have an open PR related to this for HTTP/2 (#277) and I am seeing
> > >>> related issues at $work with HTTP.
> > >>>
> > >>> In short, applications are doing things like:
> > >>>
> > >>> response.setHeader("Transfer-Encoding", "chunked");
> > >>>
> > >>> which, as you'd expect is causing problems if:
> > >>> - Tomcat doesn't chunk the response
> > >>> - Tomcat does chunk the response, adds its own "chunked" value and
> the
> > >>>   user agent rightly objects to "chunked" appearing twice
> > >>>
> > >>> And so on.
> > >>>
> > >>> I'd like to put something into Tomcat to address this.
> > >>>
> > >>> I think it should be disabled by default so correctly written
> > >>> applications pay a very small penalty. Along the lines of
> > >>>
> > >>> if (someSetting != null) {
> > >>> // Do header checks
> > >>> }
> > >>>
> > >>> In terms of options I think we need:
> > >>> - something representing the current, allow anything, behaviour
> > >>> - an option to log (with a stack trace so the offending code can be
> > >>>   identified) attempts to set such headers
> > >>> - an option to ignore attempts to set such headers
> > >>>
> > >>> Do we need an option that throws an exception if there is an attempt
> to
> > >>> set such headers?
> > >>>
> > >>> Do we need an option to control which headers and which values will
> > >>> trigger this behaviour? This would make the configuration rather more
> > >>> complex. You'd need to be able to set multiple combinations of
> header,
> > >>> value and action.
> > >>>
> > >>> Is adding debug (no stacktrace) and trace (with stacktrace) logging
> to
> > >>> addHeader() sufficient? For identifying faulty code this helps but it
> > >>> doesn't provide a way to work-around the problem. For that you need
> > >>> something that blocks the adding of the header.
> > >>>
> > >>> I'm still considering what might be the best way to fix this. Hence
> the
> > >>> brain dump above. Thoughts?
> > >>>
> > >>
> > >> There has been some debate about this before, and you did add quite a
> > bit
> > >> of code to catch things that would break the protocol. So it seems
> this
> > >> would go above and beyond, and attempt to catch *anything* that could
> > make
> > >> a response non compliant with the underlying protocol ?
> > >>
> > >> Rémy
> > >>
> > >>
> > >>>
> > >>> Mark
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > >>> For additional commands, 

Re: [VOTE] Release Apache Tomcat 10.0.0-M9

[Raymond Auge]

On Tue, Oct 6, 2020 at 9:38 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M9 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0-M8 are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0-M9/
> The Maven staging repo is:
>
> https://repository.apache.org/content/repositories/orgapachetomcatrepo-1280/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M9
> 6f143d19d151620cd0bfe9ec2ffa429e36ad0e45
>
> The proposed 10.0.0-M9 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0-M9
>

- Ray

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

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

Re: [VOTE] Release Apache Tomcat 8.5.59

[Raymond Auge]

On Tue, Oct 6, 2020 at 1:34 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.59 release is now available for voting.
>
> The notable changes compared to the 8.5.58 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Deprecate the JDBCRealm.
>
> - Ensure that none of the methods on a ServletContext instance always
>   fail when running under a SecurityManager. Pull request provided by
>   Kyle Stiemann.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.59/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1282/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.59
> c042ec71219dbde3e1ce0381ce5be0801120d0fa
>
> The proposed 8.5.59 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.59
>

- Ray

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

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

Re: [VOTE] Release Apache Tomcat 9.0.39

[Raymond Auge]

On Tue, Oct 6, 2020 at 10:49 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.39 release is now available for voting.
>
> The notable changes compared to the 9.0.38 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.39/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1281/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.39
> 6989c4e9360b4f9443862968c15a95d17f264321
>
> The proposed 9.0.39 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.39
>

- Ray

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

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

Re: [tomcat] 01/03: Fix 64751 - Correct JPMS descriptor for embedded

[Raymond Auge]

Nice fix @markt!

This was in my stack of changes from earlier work when we got blocked on
finalizing module naming.

- Ray

On Fri, Sep 18, 2020 at 4:14 PM  wrote:

> 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
>
> commit 57463377fdc13556f80d8ac8f524dbf9684ca377
> Author: Mark Thomas 
> AuthorDate: Fri Sep 18 18:44:07 2020 +0100
>
> Fix 64751 - Correct JPMS descriptor for embedded
> ---
>  build.xml| 3 ++-
>  java/org/apache/juli/logging/LogFactory.java | 3 +++
>  res/checkstyle/org-import-control.xml| 1 +
>  res/ide-support/eclipse/eclipse.classpath| 1 +
>  res/ide-support/idea/tomcat.iml  | 9 +
>  res/ide-support/netbeans/project.xml | 2 +-
>  webapps/docs/changelog.xml   | 4 
>  7 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/build.xml b/build.xml
> index b165c5f..4badeed 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -225,6 +225,7 @@
>
>
>
> +
>  
>  
>  
> @@ -1596,7 +1597,7 @@
>  
>
> -depends="build-manifests,setup-bnd,compile" >
> +depends="build-manifests,setup-bnd,compile,package" >
>
>  
>
> diff --git a/java/org/apache/juli/logging/LogFactory.java
> b/java/org/apache/juli/logging/LogFactory.java
> index 3cd4562..56c805a 100644
> --- a/java/org/apache/juli/logging/LogFactory.java
> +++ b/java/org/apache/juli/logging/LogFactory.java
> @@ -21,6 +21,8 @@ import java.nio.file.FileSystems;
>  import java.util.ServiceLoader;
>  import java.util.logging.LogManager;
>
> +import aQute.bnd.annotation.spi.ServiceConsumer;
> +
>  /**
>   * This is a modified LogFactory that uses a simple {@link ServiceLoader}
> based
>   * discovery mechanism with a default of using JDK based logging. An
> @@ -61,6 +63,7 @@ import java.util.logging.LogManager;
>   * @author Costin Manolache
>   * @author Richard A. Sitze
>   */
> +@ServiceConsumer(value=org.apache.juli.logging.Log.class)
>  public class LogFactory {
>
>  private static final LogFactory singleton = new LogFactory();
> diff --git a/res/checkstyle/org-import-control.xml
> b/res/checkstyle/org-import-control.xml
> index fc69cef..a67ffa2 100644
> --- a/res/checkstyle/org-import-control.xml
> +++ b/res/checkstyle/org-import-control.xml
> @@ -37,6 +37,7 @@
>
>
>
> +  
>
>  
>  
> diff --git a/res/ide-support/eclipse/eclipse.classpath
> b/res/ide-support/eclipse/eclipse.classpath
> index 216c5d4..73e459e 100644
> --- a/res/ide-support/eclipse/eclipse.classpath
> +++ b/res/ide-support/eclipse/eclipse.classpath
> @@ -29,5 +29,6 @@
>   path="TOMCAT_LIBS_BASE/hamcrest-2.2/hamcrest-2.2.jar"/>
>   path="TOMCAT_LIBS_BASE/cglib-3.3.0/cglib-nodep-3.3.0.jar"/>
>   path="TOMCAT_LIBS_BASE/objenesis-3.1/objenesis-3.1.jar"/>
> + path="TOMCAT_LIBS_BASE/bnd-5.1.1/biz.aQute.bnd-5.1.1.jar"/>
>  
>  
> diff --git a/res/ide-support/idea/tomcat.iml
> b/res/ide-support/idea/tomcat.iml
> index 7d3e246..22834db 100644
> --- a/res/ide-support/idea/tomcat.iml
> +++ b/res/ide-support/idea/tomcat.iml
> @@ -110,6 +110,15 @@
>  
>
>  
> +
> +  
> +
> +   url="jar://$TOMCAT_BUILD_LIBS$/bnd-5.1.1/biz.aQute.bnd-5.1.1.jar!/" />
> +
> +
> +
> +  
> +
>
>
>  
> diff --git a/res/ide-support/netbeans/project.xml
> b/res/ide-support/netbeans/project.xml
> index 084b8f5..a78164c 100644
> --- a/res/ide-support/netbeans/project.xml
> +++ b/res/ide-support/netbeans/project.xml
> @@ -178,7 +178,7 @@
>  -->
>  
>  java
> - mode="compile">${base.path}/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar:${base.path}/wsdl4j-1.6.3/wsdl4j-1.6.3.jar:${base.path}/ecj-4.15/ecj-4.15.jar:${ant.includes}/
> + mode="compile">${base.path}/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar:${base.path}/wsdl4j-1.6.3/wsdl4j-1.6.3.jar:${base.path}/ecj-4.15/ecj-4.15.jar:${base.path}/bnd-5.1.1/biz.aQute.bnd-5.1.1.jar:${ant.includes}/
>  1.7
>  
>  
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index f1d7a76..26605a0 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -71,6 +71,10 @@
>  Allow using the utility executor for annotation scanning. Patch
>  provided by Jatin Kamnani. (remm)
>
> +  
> +64751: Correct the JPMS module descriptor so the
> embedded
> +JARs may be used with JPMS. (markt)
> +  
>  
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* 
 (@rotty3000)

Re: [VOTE] Release Apache Tomcat 9.0.38

[Raymond Auge]

> > [x] Stable - go ahead and release as 9.0.38
>

+1

- Ray

Re: [VOTE] Release Apache Tomcat 10.0.0-M8

[Raymond Auge]

> [x] Alpha  - go ahead and release as 10.0.0-M8

+1

- Ray

Re: security.txt

[Raymond Auge]

On Tue, Sep 1, 2020 at 2:38 PM Mark Thomas  wrote:

> On 01/09/2020 18:01, Christopher Schultz wrote:
> > All,
> >
> > I'd like to propose that we publish a security.txt[1] file on our web
> > site under /.well-known/security.txt and /security.txt
> >
> > This file contains information we all already know, but it's in
> > obviously "proprietary" locations on our web site and might not easily
> > be found by someone who maybe doesn't speak English, etc.
> >
> > Here's my proposed content:
> >
> > Contact: secur...@tomcat.apache.org
> > Contact:
> > https://tomcat.apache.org/security.html#Reporting_New_Security_Problems_
> > with_Apache_Tomcat
> > Acknowledgments: https://tomcat.apache.org/security.html
> > Preferred-Languages: en
> > Canonical: https://tomcat.apache.org/.well-known/security.txt
> > Hiring: https://tomcat.apache.org/getinvolved.html
> >
> > If there are no objections, I'll add it to the site repo, soon.
>
> +1
>
> > What's the best way to make sure that the same file ends up in
> > /.well-known/security.txt and /security.txt? Can git link them
> > together or something like that?
>
> The site is in svn.
>
> A rewrite rule?
>

As in https://svn.apache.org/repos/asf/tomcat/site/trunk/xdocs/.htaccess

- Ray


>
> Mark
>
> >
> > -chris
> >
> > [1] https://securitytxt.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
>
>

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

Re: Jakarta EE APIs

[Raymond Auge]

+1

- Ray

On Wed., Jul. 22, 2020, 5:29 p.m. Martin Grigorov, 
wrote:

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

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

Re: Native Image - Reflectionless Concept

[Raymond Auge]

Xml-less Tomcat would also be very useful for OSGi http whiteboard
implementation which I'd like to work on in the coming months.

So I +1 more programmatic API.

Just let's not forget about tear down. So many APIs completely ignore a
tear down lifecycle.

- Ray

On Mon, Jul 20, 2020, 12:16 Romain Manni-Bucau, 
wrote:

> I think a xml-less tomcat is awaited since servlet 3 - graal or not - but
> agree risk is a bit higher.
> That said path is different so wonder if skipping a temp solution can not
> be worth after all for the community.
>
> Le lun. 20 juil. 2020 à 17:58, Filip Hanik  a écrit :
>
>>
>> On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:
>>
>>
>>
>> Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :
>>
>>> Thanks for chiming in:
>>> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>>>
>>> Hi everyone,
>>>
>>> I think the generation is the sanest option since code stay clean but it
>>> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
>>> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>>>
>>> That's always an option, but it would become an external artifact and
>>> easily end up out of sync.
>>>
>>
>> Was thinking to keep the dumper in tomcat code base and the plugin to
>> consume it so it would stay in sync, but agree it is a small risk.
>>
>>
>>> This build phase would dump the descriptors in plain java and would load
>>> them with an unique - ie single for the whole webapp - plain SPI -
>>> ServiceLoader - maybe?
>>>
>>> The goal of this artifact was to reduce the size and classes from a full
>>> tomcat (already available in tomcat-embed-core), down to a code base where
>>> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>>>
>>> This kind of build tool assumes you have all the runtime state in the
>>> build - which is typically the case for graalvm - so you can completely
>>> dump StandardContext state after start phase there and just reload it from
>>> the precomputed model.
>>> Only trick is about file paths which must either be recomputed or be
>>> configurable to another base but it does not sound crazy.
>>>
>>> The less tool-ed option would be to extract all "reflectionfull" code in
>>> methods and use graalvm substitutions to drop them and use plain java
>>> instead (with a good naming convention, it can be generated as well).
>>> Keeps the duplication but at least the main code stays clean and
>>> optimizations stays together.
>>>
>>> That's pretty much what we're doing right now. Many of these feel like
>>> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
>>> loaded initialized at startup)
>>>
>>
>> Reviewing the hacks, all can be done cleanly if extracted in methods.
>> Pushing the logic next step - I don't know if worth it but trying to use
>> this picture to explain:
>>
>> 1. A noxml module can be done with protected methods/extension-points for
>> XML loading - even usable in java standalone mode
>> 2. Current tomcat can extend noxml module
>> 3. Graal can be based on 1
>>
>> This would benefit both jvm and graal users at the end.
>> Today 1 is possible with some hacks on tomcat embedded but it is highly
>> not natural so this can be an opportunity to make it a feature maybe?
>>
>> I believe that tomcat-embed-programmatic is a viable interim solution,
>> it's a low risk. The question for you, and the rest of the community, is
>> the reward itself enough? ie, is it worth it?
>>
>> There is some talk about making "native-ness" part of the Java itself,
>> and that could change a lot of assumptions. Making it a feature,
>> refactoring code to satisfy 1, is a bit more intrusive at this point in
>> time. I believe it introduces more risk than reward.
>>
>>
>> Filip
>>
>>
>>
>>
>>> Filip
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>>
>>> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a
>>> écrit :
>>>
 On Mon, Jul 13, 2020 at 11: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
>  

Re: [tomcat] branch 9.0.x updated: Fix BZ 64548 - generate JPMS metadata

[Raymond Auge]

I'll make the change today.

Thanks all,
- Ray

On Mon, Jul 13, 2020, 07:37 Martin Grigorov,  wrote:

>
>
> On Mon, Jul 13, 2020 at 1:02 PM Mark Thomas  wrote:
>
>> There are some Java EE / Jakarta EE issues here.
>>
>> Tomcat 10 is Jakarta EE.
>> Tomcat 9 is Java EE.
>>
>> There should not be any references to Jakarta in Tomcat 9. This needs to
>> be fixed before the next Tomcat 9 release.
>>
>> I don't think there are definitive JPMS names for the Java EE 8 modules
>> as Java EE 8 pre-dates Java 9 where JPMS was introduced. I'm not sure of
>> the best way to handle this. Options that come to mind are:
>> a) no JPMS info at all
>> b) align it with the JAR file names (i.e. replicate what would happen by
>>default)
>> c) Use the Jakarta EE 9 names but with javax.* rather than jakarta.*
>>
>
> c) sounds the best to me
> Many people use Tomcat 9 (as the current stable version) with newer JDKs.
>
>
>>
>> Mark
>>
>>
>> On 11/07/2020 03:42, rotty3...@apache.org wrote:
>> > 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 39e7478  Fix BZ 64548 - generate JPMS metadata
>> > 39e7478 is described below
>> >
>> > commit 39e74780c4292d51b544620e59124c2dfb1b9ab8
>> > Author: Raymond Augé 
>> > AuthorDate: Fri Jun 19 22:25:54 2020 -0400
>> >
>> > Fix BZ 64548 - generate JPMS metadata
>> >
>> > Signed-off-by: Raymond Augé 
>> > ---
>> >  res/bnd/annotations-api.jar.tmp.bnd| 10 +-
>> >  res/bnd/build-defaults.bnd |  4 +++-
>> >  res/bnd/catalina-ha.jar.tmp.bnd| 10 +-
>> >  res/bnd/catalina-ssi.jar.tmp.bnd   |  8 
>> >  res/bnd/catalina-storeconfig.jar.tmp.bnd   | 10 +-
>> >  res/bnd/catalina-tribes.jar.tmp.bnd| 10 +-
>> >  res/bnd/catalina.jar.tmp.bnd   | 20 +++-
>> >  res/bnd/el-api.jar.tmp.bnd |  8 
>> >  res/bnd/jasper-el.jar.tmp.bnd  | 10 +-
>> >  res/bnd/jasper.jar.tmp.bnd | 11 ++-
>> >  res/bnd/jaspic-api.jar.tmp.bnd | 10 +-
>> >  res/bnd/jsp-api.jar.tmp.bnd|  8 
>> >  res/bnd/servlet-api.jar.tmp.bnd|  8 
>> >  res/bnd/tomcat-api.jar.tmp.bnd |  8 
>> >  res/bnd/tomcat-coyote.jar.tmp.bnd  | 10 +-
>> >  res/bnd/tomcat-dbcp.jar.tmp.bnd|  9 -
>> >  res/bnd/tomcat-embed-core.jar.tmp.bnd  | 19 ++-
>> >  res/bnd/tomcat-embed-el.jar.tmp.bnd|  9 -
>> >  res/bnd/tomcat-embed-jasper.jar.tmp.bnd|  9 -
>> >  res/bnd/tomcat-embed-websocket.jar.tmp.bnd | 11 +--
>> >  res/bnd/tomcat-jni.jar.tmp.bnd | 10 +-
>> >  res/bnd/tomcat-juli.jar.tmp.bnd| 10 +-
>> >  res/bnd/tomcat-util-scan.jar.tmp.bnd   | 10 +-
>> >  res/bnd/tomcat-util.jar.tmp.bnd| 10 +-
>> >  res/bnd/tomcat-websocket.jar.tmp.bnd   | 10 +-
>> >  res/bnd/websocket-api.jar.tmp.bnd  | 10 +-
>> >  webapps/docs/changelog.xml |  3 +++
>> >  27 files changed, 243 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/res/bnd/annotations-api.jar.tmp.bnd
>> b/res/bnd/annotations-api.jar.tmp.bnd
>> > index 19db9f4..09151bf 100644
>> > --- a/res/bnd/annotations-api.jar.tmp.bnd
>> > +++ b/res/bnd/annotations-api.jar.tmp.bnd
>> > @@ -32,4 +32,12 @@ Provide-Capability: \
>> >  Implementation-Version=1.3.${annotation.revision};\
>> >  Specification-Title='Common Annotations';\
>> >  Specification-Vendor='Oracle Corporation';\
>> > -Specification-Version=1.3
>> > \ No newline at end of file
>> > +Specification-Version=1.3
>> > +
>> > +-jpms-module-info: \
>> > +jakarta.annotation;\
>> > +access=32;\
>> > +version=${annotation.spec.version}
>> > +-jpms-module-info-options: \
>> > + jakarta.annotation;\
>> > + substitute=annotations-api
>>
>> Should not reference Jakarta
>>
>> > diff --git a/res/bnd/catalina.jar.tmp.bnd b/res/bnd/catalina.jar.tmp.bnd
>> > index dc94c42..972745c 100644
>> > --- a/res/bnd/catalina.jar.tmp.bnd
>> > +++ b/res/bnd/catalina.jar.tmp.bnd
>> > @@ -48,4 +48,22 @@ Export-Package: \
>> >  org.apache.catalina
>> >
>> >  -includepackage: \
>> > -org.apache.naming.factory.webservices
>> > \ No newline at end of file
>> > +org.apache.naming.factory.webservices
>> > +
>> > +-jpms-module-info: \
>> > +${module.name};\
>> > +access=32;\
>> > +version=${Bundle-Version};\
>> > +modules='\
>> > +jakarta.ejb-api,\
>> > +jakarta.mail,\
>> > +jakarta.persistence-api,\
>> > +jakarta.xml.rpc-api,\
>> > +java.xml.ws'

Re: [ANN] New committer: Raymond Augé

[Raymond Auge]

Thank you all.

Sincerely,
- Ray


On Thu, Jul 2, 2020, 11:45 Romain Manni-Bucau, 
wrote:

> Congrats Ray, well deserved!
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 2 juil. 2020 à 17:39, Coty Sutherland  a
> écrit :
>
>> Congrats and welcome!
>>
>> On Thu, Jul 2, 2020 at 10:40 AM Mark Thomas  wrote:
>>
>>> On behalf of the Tomcat committers I am pleased to announce that
>>> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>>>
>>> Please join me in welcoming him.
>>>
>>> Kind regards,
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>

Re: Release tagging

[Raymond Auge]

Hey Mark,

I'm sorry I got sidetracked with other things but would it be possible to
wait for the final JPMS/OSGi PRs if I promise to have them by the end of
this week?

I would love for that to be part of the 10.0.x tag but I understand if
that's not possible.

- Ray

On Tue, Jun 30, 2020 at 12:50 PM Mark Thomas  wrote:

> Hi all,
>
> It isn't quite the start of July but my release prep didn't take quite
> as long as I thought it might and the code base looks to be in a good
> state to tag. Therefore, I plan to start the July releases with a 10.0.x
> tag shortly.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

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

Re: flaky HTTP2 test

[Raymond Auge]

Understood, sorry for the noise.

- Ray

On Thu, Jun 25, 2020, 02:27 Rémy Maucherat,  wrote:

> On Thu, Jun 25, 2020 at 3:28 AM Raymond Auge 
> wrote:
>
>> Sorry folks, but here are two more intermittent Http2 test failures:
>>
>> 2020-06-25T01:09:24.3494270Z[concat] Testsuites with failed tests:
>> 2020-06-25T01:09:24.3496415Z[concat] 
>> TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
>> 2020-06-25T01:09:24.3497981Z[concat] 
>> TEST-org.apache.coyote.http2.TestHttp2Section_6_1.NIO2.txt
>>
>> Full log:
>> https://gist.github.com/rotty3000/5fd2d101fab664707f024d3d3110bf86
>>
>> One benefit of running tests as quickly and often as possible is catching
>> these kinds of flaky tests.
>>
>> For reference https://github.com/rotty3000/tomcat/actions
>>
>
> You do not need to send an email every time a test fails. It's interesting
> and all, but until a test fails locally rather reliably I'm not actually
> going to do much about it.
>
> Rémy
>
>
>>
>> - Ray
>>
>>
>> On Wed, Jun 24, 2020 at 11:56 AM Raymond Auge 
>> wrote:
>>
>>> Sorry about that. I've copied the entire build log here
>>>
>>> https://gist.github.com/rotty3000/475d92ece3f41123e7092ab31ce30f53
>>>
>>> Hopefully you can see that one?
>>>
>>> - Ray
>>>
>>> On Wed, Jun 24, 2020 at 11:35 AM Eduardo Quintanilla <
>>> equintani...@bnext.mx> wrote:
>>>
>>>> The link does not work.
>>>>
>>>> HTTP Status: 400
>>>> Response: {"count":11,"value":"Uri expired"}
>>>>
>>>> Eduardo Quintanilla
>>>> Software Developer
>>>>
>>>> From: Raymond Auge 
>>>> Sent: miércoles, 24 de junio de 2020 10:29 a. m.
>>>> To: Tomcat Developers List 
>>>> Subject: Re: flaky HTTP2 test
>>>>
>>>> You'll notice that in the same run that test passed on JDK 14 and 15-ea.
>>>>
>>>> - Ray
>>>>
>>>> On Wed, Jun 24, 2020 at 11:26 AM Raymond Auge >>> raymond.a...@liferay.com> wrote:
>>>> See
>>>> https://pipelines.actions.githubusercontent.com/hQhYuytC86T1GsTs7qTvThq2ESqStTSskvOzwdA12PGOh7ZWVy/_apis/pipelines/1/runs/14/signedlogcontent/7?urlExpires=2020-06-24T15%3A25%3A51.1449322Z=HMACV1=O2PyO3WhK3FTDVz3t1sTeAGHP7IOlnynp8PZIfw%2BsOQ%3D
>>>>
>>>> and search for "Running org.apache.coyote.http2.TestHttp2Limits"
>>>>
>>>> - Ray
>>>>
>>>> On Wed, Jun 24, 2020 at 11:15 AM Mark Thomas <mailto:ma...@apache.org>
>>>> wrote:
>>>> On 24/06/2020 15:56, Raymond Auge wrote:
>>>> > Hey all,
>>>> >
>>>> > The test
>>>> > org.apache.coyote.http2.TestHttp2Limits
>>>> > seems to be flaky.
>>>>
>>>> Haven't seen any issues with it recently either locally or with on of
>>>> the other CI systems.
>>>>
>>>> Do you have a log from a failure case?
>>>>
>>>> Mark
>>>>
>>>> >
>>>> > I'm playing with github actions as per
>>>> > https://github.com/apache/tomcat/pull/307
>>>> > and I've observed that this test arbitrarily passes or fails.
>>>> >
>>>> > For now I will filter it out of my POC but I figured it might be
>>>> > relevant to someone :)
>>>> >
>>>> > Sincerely,
>>>> > --
>>>> > *Raymond Augé*
>>>> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>> > Senior Software Architect *Liferay, Inc.*
>>>> > <http://www.liferay.com> (@Liferay)
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: mailto:dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: mailto:dev-h...@tomcat.apache.org
>>>>
>>>>
>>>> --
>>>> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
>>>> Senior Software Architect http://www.liferay.com (@Liferay)
>>>>
>>>>
>>>> --
>>>> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
>>>> Senior Software Architect http://www.liferay.com (@Liferay)
>>>>
>>>>
>>>> The information transmitted is intended onl

Re: flaky HTTP2 test

[Raymond Auge]

Sorry folks, but here are two more intermittent Http2 test failures:

2020-06-25T01:09:24.3494270Z[concat] Testsuites with failed tests:
2020-06-25T01:09:24.3496415Z[concat]
TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
2020-06-25T01:09:24.3497981Z[concat]
TEST-org.apache.coyote.http2.TestHttp2Section_6_1.NIO2.txt

Full log: https://gist.github.com/rotty3000/5fd2d101fab664707f024d3d3110bf86

One benefit of running tests as quickly and often as possible is catching
these kinds of flaky tests.

For reference https://github.com/rotty3000/tomcat/actions

- Ray


On Wed, Jun 24, 2020 at 11:56 AM Raymond Auge 
wrote:

> Sorry about that. I've copied the entire build log here
>
> https://gist.github.com/rotty3000/475d92ece3f41123e7092ab31ce30f53
>
> Hopefully you can see that one?
>
> - Ray
>
> On Wed, Jun 24, 2020 at 11:35 AM Eduardo Quintanilla <
> equintani...@bnext.mx> wrote:
>
>> The link does not work.
>>
>> HTTP Status: 400
>> Response: {"count":11,"value":"Uri expired"}
>>
>> Eduardo Quintanilla
>> Software Developer
>>
>> From: Raymond Auge 
>> Sent: miércoles, 24 de junio de 2020 10:29 a. m.
>> To: Tomcat Developers List 
>> Subject: Re: flaky HTTP2 test
>>
>> You'll notice that in the same run that test passed on JDK 14 and 15-ea.
>>
>> - Ray
>>
>> On Wed, Jun 24, 2020 at 11:26 AM Raymond Auge > raymond.a...@liferay.com> wrote:
>> See
>> https://pipelines.actions.githubusercontent.com/hQhYuytC86T1GsTs7qTvThq2ESqStTSskvOzwdA12PGOh7ZWVy/_apis/pipelines/1/runs/14/signedlogcontent/7?urlExpires=2020-06-24T15%3A25%3A51.1449322Z=HMACV1=O2PyO3WhK3FTDVz3t1sTeAGHP7IOlnynp8PZIfw%2BsOQ%3D
>>
>> and search for "Running org.apache.coyote.http2.TestHttp2Limits"
>>
>> - Ray
>>
>> On Wed, Jun 24, 2020 at 11:15 AM Mark Thomas <mailto:ma...@apache.org>
>> wrote:
>> On 24/06/2020 15:56, Raymond Auge wrote:
>> > Hey all,
>> >
>> > The test
>> > org.apache.coyote.http2.TestHttp2Limits
>> > seems to be flaky.
>>
>> Haven't seen any issues with it recently either locally or with on of
>> the other CI systems.
>>
>> Do you have a log from a failure case?
>>
>> Mark
>>
>> >
>> > I'm playing with github actions as per
>> > https://github.com/apache/tomcat/pull/307
>> > and I've observed that this test arbitrarily passes or fails.
>> >
>> > For now I will filter it out of my POC but I figured it might be
>> > relevant to someone :)
>> >
>> > Sincerely,
>> > --
>> > *Raymond Augé*
>> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> > Senior Software Architect *Liferay, Inc.*
>> > <http://www.liferay.com> (@Liferay)
>>
>>
>> -
>> To unsubscribe, e-mail: mailto:dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: mailto:dev-h...@tomcat.apache.org
>>
>>
>> --
>> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
>> Senior Software Architect http://www.liferay.com (@Liferay)
>>
>>
>> --
>> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
>> Senior Software Architect http://www.liferay.com (@Liferay)
>>
>>
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain confidential and/or privileged
>> material. Any review, retransmission, dissemination or other use of, or
>> taking of any action in reliance upon, this information by persons or
>> entities other than the intended recipient is prohibited. If you received
>> this in error, please contact the sender and delete the material from any
>> computer.
>> La información transmitida está destinada únicamente a la persona o
>> entidad a quien que va dirigida y puede contener información confidencial
>> y/o material privilegiado. Cualquier revisión, retransmisión, difusión u
>> otros usos, o cualquier acción tomada por personas o entidades distintas al
>> destinatario basándose en esta información está prohibida. Si usted recibe
>> este mensaje por error, por favor contacte al remitente y elimine el
>> material de cualquier computadora.
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: flaky HTTP2 test

[Raymond Auge]

Sorry about that. I've copied the entire build log here

https://gist.github.com/rotty3000/475d92ece3f41123e7092ab31ce30f53

Hopefully you can see that one?

- Ray

On Wed, Jun 24, 2020 at 11:35 AM Eduardo Quintanilla 
wrote:

> The link does not work.
>
> HTTP Status: 400
> Response: {"count":11,"value":"Uri expired"}
>
> Eduardo Quintanilla
> Software Developer
>
> From: Raymond Auge 
> Sent: miércoles, 24 de junio de 2020 10:29 a. m.
> To: Tomcat Developers List 
> Subject: Re: flaky HTTP2 test
>
> You'll notice that in the same run that test passed on JDK 14 and 15-ea.
>
> - Ray
>
> On Wed, Jun 24, 2020 at 11:26 AM Raymond Auge  raymond.a...@liferay.com> wrote:
> See
> https://pipelines.actions.githubusercontent.com/hQhYuytC86T1GsTs7qTvThq2ESqStTSskvOzwdA12PGOh7ZWVy/_apis/pipelines/1/runs/14/signedlogcontent/7?urlExpires=2020-06-24T15%3A25%3A51.1449322Z=HMACV1=O2PyO3WhK3FTDVz3t1sTeAGHP7IOlnynp8PZIfw%2BsOQ%3D
>
> and search for "Running org.apache.coyote.http2.TestHttp2Limits"
>
> - Ray
>
> On Wed, Jun 24, 2020 at 11:15 AM Mark Thomas <mailto:ma...@apache.org>
> wrote:
> On 24/06/2020 15:56, Raymond Auge wrote:
> > Hey all,
> >
> > The test
> > org.apache.coyote.http2.TestHttp2Limits
> > seems to be flaky.
>
> Haven't seen any issues with it recently either locally or with on of
> the other CI systems.
>
> Do you have a log from a failure case?
>
> Mark
>
> >
> > I'm playing with github actions as per
> > https://github.com/apache/tomcat/pull/307
> > and I've observed that this test arbitrarily passes or fails.
> >
> > For now I will filter it out of my POC but I figured it might be
> > relevant to someone :)
> >
> > Sincerely,
> > --
> > *Raymond Augé*
> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> > Senior Software Architect *Liferay, Inc.*
> > <http://www.liferay.com> (@Liferay)
>
>
> -
> To unsubscribe, e-mail: mailto:dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:dev-h...@tomcat.apache.org
>
>
> --
> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
> Senior Software Architect http://www.liferay.com (@Liferay)
>
>
> --
> http://www.liferay.com/web/raymond.auge/profile (@rotty3000)
> Senior Software Architect http://www.liferay.com (@Liferay)
>
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
> La información transmitida está destinada únicamente a la persona o
> entidad a quien que va dirigida y puede contener información confidencial
> y/o material privilegiado. Cualquier revisión, retransmisión, difusión u
> otros usos, o cualquier acción tomada por personas o entidades distintas al
> destinatario basándose en esta información está prohibida. Si usted recibe
> este mensaje por error, por favor contacte al remitente y elimine el
> material de cualquier computadora.
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: flaky HTTP2 test

[Raymond Auge]

You'll notice that in the same run that test passed on JDK 14 and 15-ea.

- Ray

On Wed, Jun 24, 2020 at 11:26 AM Raymond Auge 
wrote:

> See
> https://pipelines.actions.githubusercontent.com/hQhYuytC86T1GsTs7qTvThq2ESqStTSskvOzwdA12PGOh7ZWVy/_apis/pipelines/1/runs/14/signedlogcontent/7?urlExpires=2020-06-24T15%3A25%3A51.1449322Z=HMACV1=O2PyO3WhK3FTDVz3t1sTeAGHP7IOlnynp8PZIfw%2BsOQ%3D
>
> and search for "Running org.apache.coyote.http2.TestHttp2Limits"
>
> - Ray
>
> On Wed, Jun 24, 2020 at 11:15 AM Mark Thomas  wrote:
>
>> On 24/06/2020 15:56, Raymond Auge wrote:
>> > Hey all,
>> >
>> > The test
>> > org.apache.coyote.http2.TestHttp2Limits
>> > seems to be flaky.
>>
>> Haven't seen any issues with it recently either locally or with on of
>> the other CI systems.
>>
>> Do you have a log from a failure case?
>>
>> Mark
>>
>> >
>> > I'm playing with github actions as per
>> > https://github.com/apache/tomcat/pull/307
>> > and I've observed that this test arbitrarily passes or fails.
>> >
>> > For now I will filter it out of my POC but I figured it might be
>> > relevant to someone :)
>> >
>> > Sincerely,
>> > --
>> > *Raymond Augé*
>> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> > Senior Software Architect *Liferay, Inc.*
>> > <http://www.liferay.com> (@Liferay)
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: flaky HTTP2 test

[Raymond Auge]

See
https://pipelines.actions.githubusercontent.com/hQhYuytC86T1GsTs7qTvThq2ESqStTSskvOzwdA12PGOh7ZWVy/_apis/pipelines/1/runs/14/signedlogcontent/7?urlExpires=2020-06-24T15%3A25%3A51.1449322Z=HMACV1=O2PyO3WhK3FTDVz3t1sTeAGHP7IOlnynp8PZIfw%2BsOQ%3D

and search for "Running org.apache.coyote.http2.TestHttp2Limits"

- Ray

On Wed, Jun 24, 2020 at 11:15 AM Mark Thomas  wrote:

> On 24/06/2020 15:56, Raymond Auge wrote:
> > Hey all,
> >
> > The test
> > org.apache.coyote.http2.TestHttp2Limits
> > seems to be flaky.
>
> Haven't seen any issues with it recently either locally or with on of
> the other CI systems.
>
> Do you have a log from a failure case?
>
> Mark
>
> >
> > I'm playing with github actions as per
> > https://github.com/apache/tomcat/pull/307
> > and I've observed that this test arbitrarily passes or fails.
> >
> > For now I will filter it out of my POC but I figured it might be
> > relevant to someone :)
> >
> > Sincerely,
> > --
> > *Raymond Augé*
> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> > Senior Software Architect *Liferay, Inc.*
> > <http://www.liferay.com> (@Liferay)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

flaky HTTP2 test

[Raymond Auge]

Hey all,

The test
org.apache.coyote.http2.TestHttp2Limits
seems to be flaky.

I'm playing with github actions as per
https://github.com/apache/tomcat/pull/307
and I've observed that this test arbitrarily passes or fails.

For now I will filter it out of my POC but I figured it might be relevant
to someone :)

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

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

Oh thank goodness! I was worried!

Sincerely,
- Ray

On Tue, Jun 23, 2020 at 5:19 PM Filip Hanik  wrote:

>
> On 6/23/20 1:58 PM, Raymond Auge wrote:
>
> Further review of your error seems to indicate you are not using the
> specified version of bnd. Have you overridden this in your build.properties
> file?
>
> The regex in bnd 5.1.1 release is
> `((\(|\[)\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?,\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?(\]|\)))|\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?`
>
>
> Thank you Ray, that was it!
>
> Filip
>
>
>
> - Ray
>
> On Tue, Jun 23, 2020 at 4:05 PM Raymond Auge 
> wrote:
>
>>
>>
>>
>> On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik  wrote:
>>>>
>>>>> cd res/maven
>>>>>
>>>> ant -f mvn-pub.xml generic-install
>>>>>
>>>>
>>>>
>> I also ran this in the HEAD 9.0.x branch before your change
>> (919183b438e1a2f0004082c69e34accc0c3e2f16) without error.
>>
>> - Ray
>>
>>
>>> I usually run
>>>>
>>>> ant clean deploy  embed
>>>>
>>>> Also I've added github actions build at least in my master fork that
>>>> you can see is building on ubuntu and windows here
>>>> https://github.com/rotty3000/tomcat/actions/runs/145316145
>>>>
>>>> I'll test the instructions you've given next.
>>>>
>>>> - ray
>>>>
>>>>
>>>>> Is that last command working for you?
>>>>>
>>>>> The error I'm getting is:
>>>>>
>>>>> package:
>>>>>   [jar] Building jar:
>>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>>>>
>>>>> add-osgi:
>>>>>  [echo] add-osgi
>>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>>>> true
>>>>>   [bnd] 1 ERRORS
>>>>>   [bnd]  Invalid value for Bundle-Version,
>>>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>>>   [bnd]
>>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
>>>>> bnd failed
>>>>>   [bnd] at
>>>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>>>   [bnd] at
>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>>
>>>>> Filip
>>>>>
>>>>>
>>>>> - Ray
>>>>>
>>>>> On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Raymond Auge 
>>>>>> *Sent:* Tuesday, June 23, 2020 12:17 PM
>>>>>> *To:* Tomcat Developers List 
>>>>>> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling
>>>>>> error
>>>>>>
>>>>>>
>>>>>>
>>>>>> k, so travis config is borked.. I should add github actions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don’t think Travis tests artifact generation
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Ray
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge <
>>>>>> raymond.a...@liferay.com> wrote:
>>>>>>
>>>>>> 
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>  (@rotty3000)
>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>>>  (@Liferay)
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>  (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>>  (@Liferay)
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>  (@Liferay)
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

Further review of your error seems to indicate you are not using the
specified version of bnd. Have you overridden this in your build.properties
file?

The regex in bnd 5.1.1 release is
`((\(|\[)\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?,\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?(\]|\)))|\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?`

- Ray

On Tue, Jun 23, 2020 at 4:05 PM Raymond Auge 
wrote:

>
>
>
> On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik  wrote:
>>>
>>>> cd res/maven
>>>>
>>> ant -f mvn-pub.xml generic-install
>>>>
>>>
>>>
> I also ran this in the HEAD 9.0.x branch before your change
> (919183b438e1a2f0004082c69e34accc0c3e2f16) without error.
>
> - Ray
>
>
>> I usually run
>>>
>>> ant clean deploy  embed
>>>
>>> Also I've added github actions build at least in my master fork that you
>>> can see is building on ubuntu and windows here
>>> https://github.com/rotty3000/tomcat/actions/runs/145316145
>>>
>>> I'll test the instructions you've given next.
>>>
>>> - ray
>>>
>>>
>>>> Is that last command working for you?
>>>>
>>>> The error I'm getting is:
>>>>
>>>> package:
>>>>   [jar] Building jar:
>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>>>
>>>> add-osgi:
>>>>  [echo] add-osgi
>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>>> true
>>>>   [bnd] 1 ERRORS
>>>>   [bnd]  Invalid value for Bundle-Version,
>>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>>   [bnd]
>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
>>>> bnd failed
>>>>   [bnd] at
>>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>>   [bnd] at
>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>
>>>> Filip
>>>>
>>>>
>>>> - Ray
>>>>
>>>> On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Raymond Auge 
>>>>> *Sent:* Tuesday, June 23, 2020 12:17 PM
>>>>> *To:* Tomcat Developers List 
>>>>> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling
>>>>> error
>>>>>
>>>>>
>>>>>
>>>>> k, so travis config is borked.. I should add github actions.
>>>>>
>>>>>
>>>>>
>>>>> I don’t think Travis tests artifact generation
>>>>>
>>>>>
>>>>>
>>>>> - Ray
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
>>>>> wrote:
>>>>>
>>>>> 
>>>>>
>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>  (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>>  (@Liferay)
>>>>
>>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>  (@Liferay)
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik  wrote:
>>
>>> cd res/maven
>>>
>> ant -f mvn-pub.xml generic-install
>>>
>>
>>
I also ran this in the HEAD 9.0.x branch before your change
(919183b438e1a2f0004082c69e34accc0c3e2f16) without error.

- Ray


> I usually run
>>
>> ant clean deploy  embed
>>
>> Also I've added github actions build at least in my master fork that you
>> can see is building on ubuntu and windows here
>> https://github.com/rotty3000/tomcat/actions/runs/145316145
>>
>> I'll test the instructions you've given next.
>>
>> - ray
>>
>>
>>> Is that last command working for you?
>>>
>>> The error I'm getting is:
>>>
>>> package:
>>>   [jar] Building jar:
>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>>
>>> add-osgi:
>>>  [echo] add-osgi
>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>> true
>>>   [bnd] 1 ERRORS
>>>   [bnd]  Invalid value for Bundle-Version,
>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>   [bnd]
>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
>>> bnd failed
>>>   [bnd] at
>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>   [bnd] at
>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>
>>> Filip
>>>
>>>
>>> - Ray
>>>
>>> On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Raymond Auge 
>>>> *Sent:* Tuesday, June 23, 2020 12:17 PM
>>>> *To:* Tomcat Developers List 
>>>> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error
>>>>
>>>>
>>>>
>>>> k, so travis config is borked.. I should add github actions.
>>>>
>>>>
>>>>
>>>> I don’t think Travis tests artifact generation
>>>>
>>>>
>>>>
>>>> - Ray
>>>>
>>>>
>>>>
>>>> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
>>>> wrote:
>>>>
>>>> 
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>  (@Liferay)
>>>
>>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

On Tue, Jun 23, 2020 at 3:57 PM Raymond Auge 
wrote:

>
>
> On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik  wrote:
>
>>
>> On 6/23/20 12:38 PM, Raymond Auge wrote:
>>
>> `ant test` transitively invokes `deploy` target which builds the
>> artifacts.
>>
>> You'll want to run the following commands that are currently failing for
>> me
>>
>> ant clean
>> ant
>> ant test-compile
>> ant embed
>>
> FYI

ant (alone) is just ant deploy so to save yourself some time just invoke
all those in one go:

ant clean deploy test-compile embed

- Ray


>
>> cd res/maven
>> ant -f mvn-pub.xml generic-install
>>
>
> I usually run
>
> ant clean deploy  embed
>
> Also I've added github actions build at least in my master fork that you
> can see is building on ubuntu and windows here
> https://github.com/rotty3000/tomcat/actions/runs/145316145
>
> I'll test the instructions you've given next.
>
> - ray
>
>
>> Is that last command working for you?
>>
>> The error I'm getting is:
>>
>> package:
>>   [jar] Building jar:
>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>>
>> add-osgi:
>>  [echo] add-osgi
>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>> true
>>   [bnd] 1 ERRORS
>>   [bnd]  Invalid value for Bundle-Version,
>> ${version_cleanup;9.0.0-native-image-dev} does not match
>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>   [bnd]
>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
>> bnd failed
>>   [bnd] at
>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>   [bnd] at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>
>> Filip
>>
>>
>> - Ray
>>
>> On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:
>>
>>>
>>>
>>>
>>>
>>> *From:* Raymond Auge 
>>> *Sent:* Tuesday, June 23, 2020 12:17 PM
>>> *To:* Tomcat Developers List 
>>> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error
>>>
>>>
>>>
>>> k, so travis config is borked.. I should add github actions.
>>>
>>>
>>>
>>> I don’t think Travis tests artifact generation
>>>
>>>
>>>
>>> - Ray
>>>
>>>
>>>
>>> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
>>> wrote:
>>>
>>> 
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik  wrote:

>
> On 6/23/20 12:38 PM, Raymond Auge wrote:
>
> `ant test` transitively invokes `deploy` target which builds the artifacts.
>
> You'll want to run the following commands that are currently failing for me
>
> ant clean
> ant
> ant test-compile
> ant embed
>
> cd res/maven
> ant -f mvn-pub.xml generic-install
>

I usually run

ant clean deploy embed

Also I've added github actions build at least in my master fork that you
can see is building on ubuntu and windows here
https://github.com/rotty3000/tomcat/actions/runs/145316145

I'll test the instructions you've given next.

- ray


> Is that last command working for you?
>
> The error I'm getting is:
>
> package:
>   [jar] Building jar:
> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
>
> add-osgi:
>  [echo] add-osgi
> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
> true
>   [bnd] 1 ERRORS
>   [bnd]  Invalid value for Bundle-Version,
> ${version_cleanup;9.0.0-native-image-dev} does not match
> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>   [bnd]
> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
> bnd failed
>   [bnd] at
> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>   [bnd] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>
> Filip
>
>
> - Ray
>
> On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:
>
>>
>>
>>
>>
>> *From:* Raymond Auge 
>> *Sent:* Tuesday, June 23, 2020 12:17 PM
>> *To:* Tomcat Developers List 
>> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error
>>
>>
>>
>> k, so travis config is borked.. I should add github actions.
>>
>>
>>
>> I don’t think Travis tests artifact generation
>>
>>
>>
>> - Ray
>>
>>
>>
>> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
>> wrote:
>>
>> 
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

`ant test` transitively invokes `deploy` target which builds the artifacts.

- Ray

On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik  wrote:

>
>
>
>
> *From:* Raymond Auge 
> *Sent:* Tuesday, June 23, 2020 12:17 PM
> *To:* Tomcat Developers List 
> *Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error
>
>
>
> k, so travis config is borked.. I should add github actions.
>
>
>
> I don’t think Travis tests artifact generation
>
>
>
> - Ray
>
>
>
> On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
> wrote:
>
> 
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

k, so travis config is borked.. I should add github actions.

- Ray

On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
wrote:

>
>
> On Tue, Jun 23, 2020 at 3:09 PM Raymond Auge 
> wrote:
>
>> Also, at the root of 9.0.x I hard coded the value of:
>>
>
> of course I meant HEAD (caed3194b48ccbbac0572417b0e60807683a8690)
>
> I'm not sure what you're missing. But it builds in CI does it not?
>
> - Ray
>
>
>>
>> Bundle-Version: ${version_cleanup;9.0.0-native-image-dev}
>>
>> and the result was no error and bundles have:
>>
>> Bundle-Version: 9.0.0.native-image-dev
>>
>> - Ray
>>
>> On Tue, Jun 23, 2020 at 3:02 PM Raymond Auge 
>> wrote:
>>
>>> See https://bz.apache.org/bugzilla/show_bug.cgi?id=64498
>>>
>>> On Tue, Jun 23, 2020 at 2:57 PM Raymond Auge 
>>> wrote:
>>>
>>>> This is not a good fix. This is the same problem we had before with
>>>> incompatible version syntax in OSGi.
>>>>
>>>> - Ray
>>>>
>>>> On Tue, Jun 23, 2020 at 2:54 PM  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
>>>>>
>>>>>
>>>>> The following commit(s) were added to refs/heads/9.0.x by this push:
>>>>>  new caed319  Fixes OSGI bundling error
>>>>> caed319 is described below
>>>>>
>>>>> commit caed3194b48ccbbac0572417b0e60807683a8690
>>>>> Author: Filip Hanik 
>>>>> AuthorDate: Tue Jun 23 11:53:08 2020 -0700
>>>>>
>>>>> Fixes OSGI bundling error
>>>>>
>>>>> add-osgi:
>>>>>  [echo] add-osgi
>>>>>
>>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/output/build/lib/annotations-api.jar
>>>>> true
>>>>>   [bnd] 1 ERRORS
>>>>>   [bnd]  Invalid value for Bundle-Version,
>>>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>>>   [bnd]
>>>>>
>>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/res/bnd/annotations-api.jar.tmp.bnd:
>>>>> bnd failed
>>>>>   [bnd] at
>>>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>>   [bnd] at
>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>>>> Source)
>>>>>   [bnd] at
>>>>>
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>>>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>>>>   [bnd] at
>>>>> org.apache.tools.ant.Target.execute(Target.java:449)
>>>>>   [bnd] at
>>>>> org.apache.tools.ant.Target.performTasks(Target.java:470)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>>>>>   [bnd] at
>>>>> org.apache.tools.ant.Project.executeTargets(Project.java:1254)
>>>>>   [bnd] at
>>>>> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
>>>>>   [bnd] at
>>>>>
>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>>   [bnd] at
>>

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

On Tue, Jun 23, 2020 at 3:09 PM Raymond Auge 
wrote:

> Also, at the root of 9.0.x I hard coded the value of:
>

of course I meant HEAD (caed3194b48ccbbac0572417b0e60807683a8690)

I'm not sure what you're missing. But it builds in CI does it not?

- Ray


>
> Bundle-Version: ${version_cleanup;9.0.0-native-image-dev}
>
> and the result was no error and bundles have:
>
> Bundle-Version: 9.0.0.native-image-dev
>
> - Ray
>
> On Tue, Jun 23, 2020 at 3:02 PM Raymond Auge 
> wrote:
>
>> See https://bz.apache.org/bugzilla/show_bug.cgi?id=64498
>>
>> On Tue, Jun 23, 2020 at 2:57 PM Raymond Auge 
>> wrote:
>>
>>> This is not a good fix. This is the same problem we had before with
>>> incompatible version syntax in OSGi.
>>>
>>> - Ray
>>>
>>> On Tue, Jun 23, 2020 at 2:54 PM  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
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/9.0.x by this push:
>>>>  new caed319  Fixes OSGI bundling error
>>>> caed319 is described below
>>>>
>>>> commit caed3194b48ccbbac0572417b0e60807683a8690
>>>> Author: Filip Hanik 
>>>> AuthorDate: Tue Jun 23 11:53:08 2020 -0700
>>>>
>>>> Fixes OSGI bundling error
>>>>
>>>> add-osgi:
>>>>  [echo] add-osgi
>>>>
>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/output/build/lib/annotations-api.jar
>>>> true
>>>>   [bnd] 1 ERRORS
>>>>   [bnd]  Invalid value for Bundle-Version,
>>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>>   [bnd]
>>>>
>>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/res/bnd/annotations-api.jar.tmp.bnd:
>>>> bnd failed
>>>>   [bnd] at
>>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>>   [bnd] at
>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>   [bnd] at
>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>>> Source)
>>>>   [bnd] at
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>>>   [bnd] at
>>>>
>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>>>   [bnd] at
>>>> org.apache.tools.ant.Target.execute(Target.java:449)
>>>>   [bnd] at
>>>> org.apache.tools.ant.Target.performTasks(Target.java:470)
>>>>   [bnd] at
>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>>>>   [bnd] at
>>>>
>>>> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>>>>   [bnd] at
>>>> org.apache.tools.ant.Project.executeTargets(Project.java:1254)
>>>>   [bnd] at
>>>> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
>>>>   [bnd] at
>>>>
>>>> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
>>>>   [bnd] at
>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>>   [bnd] at
>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>>> Source)
>>>>   [bnd] at
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>>>   [bnd] at
>>>>
>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>>>   [bnd] at org.apache.tools.ant.Task.perform(Task.ja

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

Also, at the root of 9.0.x I hard coded the value of:

Bundle-Version: ${version_cleanup;9.0.0-native-image-dev}

and the result was no error and bundles have:

Bundle-Version: 9.0.0.native-image-dev

- Ray

On Tue, Jun 23, 2020 at 3:02 PM Raymond Auge 
wrote:

> See https://bz.apache.org/bugzilla/show_bug.cgi?id=64498
>
> On Tue, Jun 23, 2020 at 2:57 PM Raymond Auge 
> wrote:
>
>> This is not a good fix. This is the same problem we had before with
>> incompatible version syntax in OSGi.
>>
>> - Ray
>>
>> On Tue, Jun 23, 2020 at 2:54 PM  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
>>>
>>>
>>> The following commit(s) were added to refs/heads/9.0.x by this push:
>>>  new caed319  Fixes OSGI bundling error
>>> caed319 is described below
>>>
>>> commit caed3194b48ccbbac0572417b0e60807683a8690
>>> Author: Filip Hanik 
>>> AuthorDate: Tue Jun 23 11:53:08 2020 -0700
>>>
>>> Fixes OSGI bundling error
>>>
>>> add-osgi:
>>>  [echo] add-osgi
>>>
>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/output/build/lib/annotations-api.jar
>>> true
>>>   [bnd] 1 ERRORS
>>>   [bnd]  Invalid value for Bundle-Version,
>>> ${version_cleanup;9.0.0-native-image-dev} does not match
>>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>>   [bnd]
>>>
>>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/res/bnd/annotations-api.jar.tmp.bnd:
>>> bnd failed
>>>   [bnd] at
>>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>>   [bnd] at
>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>   [bnd] at
>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>> Source)
>>>   [bnd] at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>>   [bnd] at
>>>
>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>>   [bnd] at
>>> org.apache.tools.ant.Target.execute(Target.java:449)
>>>   [bnd] at
>>> org.apache.tools.ant.Target.performTasks(Target.java:470)
>>>   [bnd] at
>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>>>   [bnd] at
>>>
>>> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>>>   [bnd] at
>>> org.apache.tools.ant.Project.executeTargets(Project.java:1254)
>>>   [bnd] at
>>> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
>>>   [bnd] at
>>> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
>>>   [bnd] at
>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>   [bnd] at
>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>> Source)
>>>   [bnd] at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>>   [bnd] at
>>>
>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>>   [bnd] at java.util.Vector.forEach(Vector.java:1249)
>>>   [bnd] at
>>> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67)
>>>   [bnd] at
>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>>   [bnd] at
>>> sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>>> Source)
>>>   [bnd] at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

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

On Tue, Jun 23, 2020 at 2:57 PM Raymond Auge 
wrote:

> This is not a good fix. This is the same problem we had before with
> incompatible version syntax in OSGi.
>
> - Ray
>
> On Tue, Jun 23, 2020 at 2:54 PM  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
>>
>>
>> The following commit(s) were added to refs/heads/9.0.x by this push:
>>  new caed319  Fixes OSGI bundling error
>> caed319 is described below
>>
>> commit caed3194b48ccbbac0572417b0e60807683a8690
>> Author: Filip Hanik 
>> AuthorDate: Tue Jun 23 11:53:08 2020 -0700
>>
>> Fixes OSGI bundling error
>>
>> add-osgi:
>>  [echo] add-osgi
>>
>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/output/build/lib/annotations-api.jar
>> true
>>   [bnd] 1 ERRORS
>>   [bnd]  Invalid value for Bundle-Version,
>> ${version_cleanup;9.0.0-native-image-dev} does not match
>> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>>   [bnd]
>>
>> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/res/bnd/annotations-api.jar.tmp.bnd:
>> bnd failed
>>   [bnd] at
>> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>>   [bnd] at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>>   [bnd] at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>   [bnd] at
>>
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>   [bnd] at
>> org.apache.tools.ant.Target.execute(Target.java:449)
>>   [bnd] at
>> org.apache.tools.ant.Target.performTasks(Target.java:470)
>>   [bnd] at
>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>>   [bnd] at
>>
>> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>>   [bnd] at
>> org.apache.tools.ant.Project.executeTargets(Project.java:1254)
>>   [bnd] at
>> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
>>   [bnd] at
>> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
>>   [bnd] at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>>   [bnd] at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>   [bnd] at
>>
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>   [bnd] at java.util.Vector.forEach(Vector.java:1249)
>>   [bnd] at
>> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67)
>>   [bnd] at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>>   [bnd] at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>>   [bnd] at
>>
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>>   [bnd] at
>>
>> org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:391)
>>   [bnd] at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>>   [bnd] at
>>
>> sun.reflect.Delegat

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Raymond Auge]

This is not a good fix. This is the same problem we had before with
incompatible version syntax in OSGi.

- Ray

On Tue, Jun 23, 2020 at 2:54 PM  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
>
>
> The following commit(s) were added to refs/heads/9.0.x by this push:
>  new caed319  Fixes OSGI bundling error
> caed319 is described below
>
> commit caed3194b48ccbbac0572417b0e60807683a8690
> Author: Filip Hanik 
> AuthorDate: Tue Jun 23 11:53:08 2020 -0700
>
> Fixes OSGI bundling error
>
> add-osgi:
>  [echo] add-osgi
>
> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/output/build/lib/annotations-api.jar
> true
>   [bnd] 1 ERRORS
>   [bnd]  Invalid value for Bundle-Version,
> ${version_cleanup;9.0.0-native-image-dev} does not match
> [0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
>   [bnd]
>
> /development/pivotal/cloudfoundry/spring-projects/graal/tomcat/res/bnd/annotations-api.jar.tmp.bnd:
> bnd failed
>   [bnd] at
> aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
>   [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
>   [bnd] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
>   [bnd] at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>   [bnd] at
>
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>   [bnd] at org.apache.tools.ant.Target.execute(Target.java:449)
>   [bnd] at
> org.apache.tools.ant.Target.performTasks(Target.java:470)
>   [bnd] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>   [bnd] at
>
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>   [bnd] at
> org.apache.tools.ant.Project.executeTargets(Project.java:1254)
>   [bnd] at
> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
>   [bnd] at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
>   [bnd] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
>   [bnd] at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>   [bnd] at
>
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>   [bnd] at java.util.Vector.forEach(Vector.java:1249)
>   [bnd] at
> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67)
>   [bnd] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
>   [bnd] at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>   [bnd] at
>
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>   [bnd] at
>
> org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:391)
>   [bnd] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
>   [bnd] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
>   [bnd] at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   [bnd] at java.lang.reflect.Method.invoke(Method.java:498)
>   [bnd] at
>
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
>   [bnd] at org.apache.tools.ant.Task.perform(Task.java:350)
>   [bnd] at org.apache.tools.ant.Target.execute(Target.java:449)
>   [bnd] at
> org.apache.tools.ant.Target.performTasks(Target.java:470)
>   [bnd] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
>   [bnd] at
> org.apache.tools.ant.Project.executeTarget(Project.java:1364)
>   [bnd] at
>
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>   [bnd] at
> 

Re: smoke tests for the runtime

[Raymond Auge]

On Tue, Jun 23, 2020 at 10:54 AM Mark Thomas  wrote:

> On 23/06/2020 14:04, Raymond Auge wrote:
> > Hey all,
> >
> > Is there a set of tests that run against a real tomcat runtime anywhere
> > in the project already? I haven't found any and I'd like to put
> > something together that would run against base configurations of Tomcat
> > running in JPMS and OSGi modes.
>
> If I want a trivial smoke test I play the snake game from the examples
> across a couple of browsers.
>

This is what I've been doing, going through several of the examples to
assure they don't blow up :D


>
> If you want something more comprehensive you could use the Servlet TCK
> or the JSP TCK although getting them set up can be non-trivial.
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>
> That would work for 9.0.x or 10.0.x as long as you use the right TCK
> version.
>

Interesting, a little heavier than I hoped but maybe a trimmed version of
this could be used.


>
> Another option I often use is Jira. Download the eval version, build the
> WAR (I don't think you can download a WAR directly but it has been a
> while) and see if Jira starts.
>
> That is only going to work for Tomcat 9 at this point.
>

That's a bigger limitation than I like since I'm specifically wishing to
make sure both master and 9.0.x continue to work.

Thanks Mark! I'll consider this.

- Ray


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

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

smoke tests for the runtime

[Raymond Auge]

Hey all,

Is there a set of tests that run against a real tomcat runtime anywhere in
the project already? I haven't found any and I'd like to put something
together that would run against base configurations of Tomcat running in
JPMS and OSGi modes.

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

Re: JPMS module names

[Raymond Auge]

On Tue, Jun 16, 2020 at 10:43 AM Mark Thomas  wrote:

> On 16/06/2020 15:00, Raymond Auge wrote:
> > Hey folks,
> >
> > I've extrapolated what I found as basis for a rule to create module
> > names and this is what I've come up with:
> >
> > module.name <http://module.name>:
> org.apache.${replace;${Bundle-Name};-;.}
> >
> > that is:
> > - take the `Bundle-Name` value (which appears to have a consistent
> format)
> > - replace dashes with dots
> > - prefix with "org.apache."
> >
> > The result is:
> >
> > org.apache.tomcat.api
> > org.apache.tomcat.catalina
> > org.apache.tomcat.catalina.ant
> > org.apache.tomcat.catalina.ha
> > org.apache.tomcat.coyote
> > org.apache.tomcat.dbcp
> > org.apache.tomcat.jasper
> > org.apache.tomcat.jasper.el
> > org.apache.tomcat.jni
> > org.apache.tomcat.juli
> > org.apache.tomcat.ssi
> > org.apache.tomcat.storeconfig
> > org.apache.tomcat.tribes
> > org.apache.tomcat.util
> > org.apache.tomcat.util.scan
> > org.apache.tomcat.websocket
>

Are we at least fine with the tomcat module names? (notice I did miss
tomcat-jdbc which has a special build that I still need to work on).


> >
> > For the spec API I've used the official names pulled from each spec
> project:
> >
> > jakarta.annotation
> > jakarta.el.api
> > jakarta.security.enterprise
> > jakarta.servlet
> > jakarta.servlet.jsp
> > jakarta.websocket.api
> >
> > Does that look correct?
>
> A couple of the spec ones look inconsistent. The naming guidance for
> Jakarta is:
> https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
>
> I don't think the Jakarta PMC has made a final decision on JMPS rules or
> even if a JPMS name is required. I have proposed that as a general rule
> each project uses the OSGi Bundle-SymbolicName with any "-" characters
> replaced by "." as the JPMS module name.
>
> I'd expect at least JSP and servlet to switch to that format by the time
> of the Jakarta EE 9 release.
>

I will adjust and follow your proposal for the time being then.

- Ray


>
> JPMS name feels like a bit of a moving target at this point.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

JPMS module names

[Raymond Auge]

Hey folks,

I've extrapolated what I found as basis for a rule to create module names
and this is what I've come up with:

module.name: org.apache.${replace;${Bundle-Name};-;.}

that is:
- take the `Bundle-Name` value (which appears to have a consistent format)
- replace dashes with dots
- prefix with "org.apache."

The result is:

org.apache.tomcat.api
org.apache.tomcat.catalina
org.apache.tomcat.catalina.ant
org.apache.tomcat.catalina.ha
org.apache.tomcat.coyote
org.apache.tomcat.dbcp
org.apache.tomcat.jasper
org.apache.tomcat.jasper.el
org.apache.tomcat.jni
org.apache.tomcat.juli
org.apache.tomcat.ssi
org.apache.tomcat.storeconfig
org.apache.tomcat.tribes
org.apache.tomcat.util
org.apache.tomcat.util.scan
org.apache.tomcat.websocket

For the spec API I've used the official names pulled from each spec project:

jakarta.annotation
jakarta.el.api
jakarta.security.enterprise
jakarta.servlet
jakarta.servlet.jsp
jakarta.websocket.api

Does that look correct?

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

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

[Raymond Auge]

+1 for main

On Tue, Jun 16, 2020 at 8:00 AM Coty Sutherland  wrote:

>
> On Tue, Jun 16, 2020 at 4:02 AM Mark Thomas  wrote:
>
>> All,
>>
>> You may have seen the recent discussions both inside and outside the ASF
>> about the user of "master" as the name of the default git branch. If you
>> haven't, the short version is that the name can be traced back to
>> master/slave and its associations with human slavery.
>>
>> I'd like to propose that the Apache Tomcat project renames the master
>> branch in all of the project repositories.
>>
>> I think there are two front runners for the new name:
>>
>> - main - this looks to be the name GitHub and a number of OSS projects
>>  will be switching to
>>
>> - trunk - reflects the Subversion heritage of both the project and the
>>   ASF
>>
>> Other options I have seen suggested include "default", "dev", "develop".
>> Other suggestions welcome.
>>
>> Personally, I am leaning towards main as that looks to be the choice of
>> the majority and using the majority choice will make it (a little bit)
>> easier for new community members to find their way around the project.
>>
>> In terms of impact, changing the name is going to break stuff. It is
>> really creating a new branch and deleting the old one.
>>
>> Deleting a branch triggers the automatic closure of github PRs against
>> that branch. However if we create "$new_branch" we can edit the PRs to
>> use "$new_branch" before we delete master. Given the small number of
>> open PRs that is easily done.
>>
>> CI systems will need to be updated (buildbot, gump). That should be
>> relatively simple.
>>
>> Docs will need to be updated (relatively simple).
>>
>> Committers and contributors will rebase any local branches to $new_branch
>>
>> Having thought about what is involved, renaming the default branch
>> doesn't look as problematic as I thought it might be. This looks like
>> something that could be done in around an hour for all our repos.
>>
>> Thoughts?
>>
>
> I'm +1 for main
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

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

Re: Tomcat running fully on JPMS

[Raymond Auge]

And just now got it running fully on OSGi (with a small bootup shim, a.k.a.
bundle).

- Ray

On Mon, Jun 15, 2020 at 9:58 AM Raymond Auge 
wrote:

> There's a slew of changes still needed, but at least it's not a
> pie-in-the-sky-like effort.
>
> - Ray
>
> On Mon, Jun 15, 2020 at 9:33 AM Mark Thomas  wrote:
>
>> On 15/06/2020 01:56, Raymond Auge wrote:
>> > Hey all,
>> >
>> > I couldn't resist but to let you know that today I run tomcat 10 fully
>> > on JPMS (and the webapp examples seemed to all work fine):
>>
>> Nice.
>>
>> I was expecting it to be rather more disruptive than it turned out to
>> be. Thanks for sharing your JPMS/OSGI expertise.
>>
>> Mark
>>
>>
>> >
>> > bin]$ /usr/lib/jvm/zulu-11-amd64/bin/java \
>> >> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources \
>> >> -p .:../lib/ \
>> >> --add-modules org.apache.tomcat.jasper \
>> >> --module
>> org.apache.tomcat.catalina/org.apache.catalina.startup.Bootstrap start
>> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
>> > addClusterRuleSet
>> > INFO: Cluster RuleSet not found due to
>> > [java.lang.ClassNotFoundException:
>> > org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
>> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
>> > addClusterRuleSet
>> > INFO: Cluster RuleSet not found due to
>> > [java.lang.ClassNotFoundException:
>> > org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Server version name:   Apache Tomcat/10.0.0-M7-dev
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Server built:  Jun 14 2020 13:51:24 UTC
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Server version number: 10.0.0.0
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: OS Name:   Linux
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: OS Version:5.3.0-59-generic
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Architecture:  amd64
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Java Home: /usr/lib/jvm/zulu-11-amd64
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: JVM Version:   11.0.7+10-LTS
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: JVM Vendor:Azul Systems, Inc.
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: CATALINA_BASE: /home/rotty/projects/tomcat/output/build
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: CATALINA_HOME: /home/rotty/projects/tomcat/output/build
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Command line argument:
>> > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Command line argument: --module-path=.:../lib/
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Command line argument: --add-modules=org.apache.tomcat.jasper
>> > Jun. 14, 2020 8:51:30 P.M.
>> > org.apache.catalina.startup.VersionLoggerListener log
>> > INFO: Command line argument:
>> -Djdk.module.main=org.apache.tomcat.catalina
>> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.AprLifecycleListener
>> > lifecycleEvent
>> > INFO: The Apache Tomcat Native library which allows using OpenSSL was
>> > not found on the java.library.path:
>> > [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib]
>> > Jun. 14, 2020 8:51:30 P.M. org.apache.coyote.AbstractProtocol init
>> > INFO: Initializing ProtocolHandler ["http-nio-8080"]
>> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Ca

Re: Tomcat running fully on JPMS

[Raymond Auge]

There's a slew of changes still needed, but at least it's not a
pie-in-the-sky-like effort.

- Ray

On Mon, Jun 15, 2020 at 9:33 AM Mark Thomas  wrote:

> On 15/06/2020 01:56, Raymond Auge wrote:
> > Hey all,
> >
> > I couldn't resist but to let you know that today I run tomcat 10 fully
> > on JPMS (and the webapp examples seemed to all work fine):
>
> Nice.
>
> I was expecting it to be rather more disruptive than it turned out to
> be. Thanks for sharing your JPMS/OSGI expertise.
>
> Mark
>
>
> >
> > bin]$ /usr/lib/jvm/zulu-11-amd64/bin/java \
> >> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources \
> >> -p .:../lib/ \
> >> --add-modules org.apache.tomcat.jasper \
> >> --module
> org.apache.tomcat.catalina/org.apache.catalina.startup.Bootstrap start
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
> > addClusterRuleSet
> > INFO: Cluster RuleSet not found due to
> > [java.lang.ClassNotFoundException:
> > org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
> > addClusterRuleSet
> > INFO: Cluster RuleSet not found due to
> > [java.lang.ClassNotFoundException:
> > org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Server version name:   Apache Tomcat/10.0.0-M7-dev
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Server built:  Jun 14 2020 13:51:24 UTC
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Server version number: 10.0.0.0
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: OS Name:   Linux
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: OS Version:5.3.0-59-generic
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Architecture:  amd64
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Java Home: /usr/lib/jvm/zulu-11-amd64
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: JVM Version:   11.0.7+10-LTS
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: JVM Vendor:Azul Systems, Inc.
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: CATALINA_BASE: /home/rotty/projects/tomcat/output/build
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: CATALINA_HOME: /home/rotty/projects/tomcat/output/build
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Command line argument:
> > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Command line argument: --module-path=.:../lib/
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Command line argument: --add-modules=org.apache.tomcat.jasper
> > Jun. 14, 2020 8:51:30 P.M.
> > org.apache.catalina.startup.VersionLoggerListener log
> > INFO: Command line argument: -Djdk.module.main=org.apache.tomcat.catalina
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.AprLifecycleListener
> > lifecycleEvent
> > INFO: The Apache Tomcat Native library which allows using OpenSSL was
> > not found on the java.library.path:
> > [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib]
> > Jun. 14, 2020 8:51:30 P.M. org.apache.coyote.AbstractProtocol init
> > INFO: Initializing ProtocolHandler ["http-nio-8080"]
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina load
> > INFO: Server initialization in [449] milliseconds
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.StandardService
> > startInternal
> > INFO: Starting service [Catalina]
> > Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.StandardEngine
> > startInternal
> > INFO: Starting Servlet engine: [Apache Tomcat/10.0.0-M7-dev]
> > Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.startup.HostConfig
> > deployDirectory
> > INFO: Deploying web applicati

Tomcat running fully on JPMS

[Raymond Auge]

Hey all,

I couldn't resist but to let you know that today I run tomcat 10 fully on
JPMS (and the webapp examples seemed to all work fine):

bin]$ /usr/lib/jvm/zulu-11-amd64/bin/java \
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources \
> -p .:../lib/ \
> --add-modules org.apache.tomcat.jasper \
> --module org.apache.tomcat.catalina/org.apache.catalina.startup.Bootstrap
start
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException:
org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina
addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException:
org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Server version name:   Apache Tomcat/10.0.0-M7-dev
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Server built:  Jun 14 2020 13:51:24 UTC
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Server version number: 10.0.0.0
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: OS Name:   Linux
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: OS Version:5.3.0-59-generic
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Architecture:  amd64
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Java Home: /usr/lib/jvm/zulu-11-amd64
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: JVM Version:   11.0.7+10-LTS
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: JVM Vendor:Azul Systems, Inc.
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_BASE: /home/rotty/projects/tomcat/output/build
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_HOME: /home/rotty/projects/tomcat/output/build
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument:
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: --module-path=.:../lib/
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: --add-modules=org.apache.tomcat.jasper
Jun. 14, 2020 8:51:30 P.M.
org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: -Djdk.module.main=org.apache.tomcat.catalina
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: The Apache Tomcat Native library which allows using OpenSSL was not
found on the java.library.path:
[/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib]
Jun. 14, 2020 8:51:30 P.M. org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-nio-8080"]
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.startup.Catalina load
INFO: Server initialization in [449] milliseconds
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.StandardService
startInternal
INFO: Starting service [Catalina]
Jun. 14, 2020 8:51:30 P.M. org.apache.catalina.core.StandardEngine
startInternal
INFO: Starting Servlet engine: [Apache Tomcat/10.0.0-M7-dev]
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory
[/home/rotty/projects/tomcat/output/build/webapps/ROOT]
Jun. 14, 2020 8:51:31 P.M.
org.apache.tomcat.util.descriptor.DigesterFactory locationFor
WARNING: The XML schema [web-fragment_5_0.xsd] could not be found. This is
very likely to break XML validation if XML validation is enabled.
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deployment of web application directory
[/home/rotty/projects/tomcat/output/build/webapps/ROOT] has finished in
[184] ms
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory
[/home/rotty/projects/tomcat/output/build/webapps/examples]
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: attributeAdded('StockTicker',
'async.Stockticker@1bdf8190')
Jun. 14, 2020 8:51:31 P.M. org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deployment of web application directory

Re: Bootstrap classloader hierarchy and split packages

[Raymond Auge]

Ok, I guess you can ignore this question because I think the conclusion is
that bootstrap cannot be used in JPMS at all.

I have figured out a boot process-ish and I can see things a little more
clearly now.

- Ray

On Sat, Jun 13, 2020 at 9:12 PM Raymond Auge 
wrote:

> Forgive me if this is a well worn topic.
>
> - Ray
>
> On Sat, Jun 13, 2020 at 8:58 PM Raymond Auge 
> wrote:
>
>> Hello Tomcat Devs,
>>
>> Is it expected that when Bootstrap.init() invokes
>> "org.apache.catalina.startup.Catalina"'s constructor (which it finds in
>> catalina.jar) via reflection through catalinaLoader that some of the
>> classes in the package org.apache.catalina.startup, originating in
>> bootstrap.jar, are still used by classes loaded by the new classloader?
>>
>> The result is that there are now two jars in runtime loaded by two
>> separate containers sharing classes from the same package.
>>
>> I just want to make sure this is by choice and not accidental because
>> this is going to cause problems for both JPMS and OSGi and I need to figure
>> out how to deal with it. The first thing that might need to happen is that
>> bootstrap may need to export some of it's packages which will certainly
>> result in a split package scenario (since other modules already provide
>> those same packages). As you can guess in both module systems split
>> packages are a challenge.
>>
>> Thx
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: Bootstrap classloader hierarchy and split packages

[Raymond Auge]

Forgive me if this is a well worn topic.

- Ray

On Sat, Jun 13, 2020 at 8:58 PM Raymond Auge 
wrote:

> Hello Tomcat Devs,
>
> Is it expected that when Bootstrap.init() invokes
> "org.apache.catalina.startup.Catalina"'s constructor (which it finds in
> catalina.jar) via reflection through catalinaLoader that some of the
> classes in the package org.apache.catalina.startup, originating in
> bootstrap.jar, are still used by classes loaded by the new classloader?
>
> The result is that there are now two jars in runtime loaded by two
> separate containers sharing classes from the same package.
>
> I just want to make sure this is by choice and not accidental because this
> is going to cause problems for both JPMS and OSGi and I need to figure out
> how to deal with it. The first thing that might need to happen is that
> bootstrap may need to export some of it's packages which will certainly
> result in a split package scenario (since other modules already provide
> those same packages). As you can guess in both module systems split
> packages are a challenge.
>
> Thx
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Bootstrap classloader hierarchy and split packages

[Raymond Auge]

Hello Tomcat Devs,

Is it expected that when Bootstrap.init() invokes
"org.apache.catalina.startup.Catalina"'s constructor (which it finds in
catalina.jar) via reflection through catalinaLoader that some of the
classes in the package org.apache.catalina.startup, originating in
bootstrap.jar, are still used by classes loaded by the new classloader?

The result is that there are now two jars in runtime loaded by two separate
containers sharing classes from the same package.

I just want to make sure this is by choice and not accidental because this
is going to cause problems for both JPMS and OSGi and I need to figure out
how to deal with it. The first thing that might need to happen is that
bootstrap may need to export some of it's packages which will certainly
result in a split package scenario (since other modules already provide
those same packages). As you can guess in both module systems split
packages are a challenge.

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

Re: Bootstrap and modules

[Raymond Auge]

Please see updated https://github.com/apache/tomcat/pull/296

- Ray

On Sat, Jun 13, 2020 at 3:35 PM Raymond Auge 
wrote:

> Hey Mark, I tested those changes and they solve the packaging issue for
> both jpms and OSGi.
>
> I'll update the pr to reflect the change later today I hope.
>
> I did encounter some further jpms related issues but those were beyond
> packaging and need other questions answered before moving forward.
>
> - Ray
>
> On Sat, Jun 13, 2020, 12:49 Mark Thomas,  wrote:
>
>> On 13/06/2020 03:53, Raymond Auge wrote:
>> > Actually Bootstrap has a comment
>> >
>> > // Copied from ExceptionUtils since that class is not visible during
>> start
>> >
>> > So it seems like perhaps the change should be ported.
>>
>> Agreed. So if we do that and make the other changes I outlined where
>> does that leave things from a JPMS / OSGi point of view?
>>
>> Mark
>>
>>
>> >
>> >  - Ray
>> >
>> > On Fri, Jun 12, 2020 at 10:45 PM Raymond Auge > > <mailto:raymond.a...@liferay.com>> wrote:
>> >
>> > There is one difference between
>> >
>> > org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable)
>> >
>> > and
>> >
>> > org.apache.catalina.startup.Bootstrap.handleThrowable(Throwable)
>> >
>> > that is that ExceptionUtils also swallows StackOverflowError while
>> > Bootstrap does not.
>> > Should that be ported over or is it a deal breaker? An option would
>> > be to add an additional method to Bootstrap that behaves like
>> > ExceptionUtils.
>> >
>> > - Ray
>> >
>> >
>> > On Fri, Jun 12, 2020 at 9:27 AM Mark Thomas > > <mailto:ma...@apache.org>> wrote:
>> >
>> > On 12/06/2020 14:15, Raymond Auge wrote:
>> > > Hey Mark,
>> > >
>> > > I'll have to get back to this convo in a day or so.
>> > >
>> > > I'll test your theory but at first glance it sounds like going
>> > in the
>> > > right direction.
>> >
>> > No rush. I'd rather take time and get this right.
>> >
>> > Thanks,
>> >
>> > Mark
>> >
>> >
>> > >
>> > > - Ray
>> > >
>> > > On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas > > <mailto:ma...@apache.org>
>> > > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> wrote:
>> > >
>> > > On 11/06/2020 21:59, Mark Thomas wrote:
>> > > > On 11/06/2020 21:24, Raymond Auge wrote:
>> > > >> This can totally be fixed in configuration. There is no
>> > problem.
>> > > I just
>> > > >> wanted to make sure that in doing so we wouldn't just
>> > be pushing some
>> > > >> dirt under the rug so to speak.
>> > > >
>> > > > I'm concerned we might be doing exactly that now we are
>> > heading into a
>> > > > JPMS world and this seems like an opportunity to pause
>> > and see if
>> > > there
>> > > > is a better way.
>> > > >
>> > > > I've yet to get my head around JPMS and I might be
>> > mis-remembering
>> > > some
>> > > > of the things I have read.
>> > > >
>> > > > bootstrap.jar has everything it needs to start, create
>> > the class
>> > > loader
>> > > > hierarchy, switch to the catalinaLoader (which can see
>> > all the JARs
>> > > > rather than just bootstrap.jar and tomcat-juli.jar) and
>> > then continue
>> > > > with start-up.
>> > > >
>> > > > It does things this way because the class loader
>> > hierarchy and the
>> > > > configuration of the class loaders is configurable. So
>> > we can't
>> > > just put
>> > > > everything on the 

Re: Bootstrap and modules

[Raymond Auge]

Hey Mark, I tested those changes and they solve the packaging issue for
both jpms and OSGi.

I'll update the pr to reflect the change later today I hope.

I did encounter some further jpms related issues but those were beyond
packaging and need other questions answered before moving forward.

- Ray

On Sat, Jun 13, 2020, 12:49 Mark Thomas,  wrote:

> On 13/06/2020 03:53, Raymond Auge wrote:
> > Actually Bootstrap has a comment
> >
> > // Copied from ExceptionUtils since that class is not visible during
> start
> >
> > So it seems like perhaps the change should be ported.
>
> Agreed. So if we do that and make the other changes I outlined where
> does that leave things from a JPMS / OSGi point of view?
>
> Mark
>
>
> >
> >  - Ray
> >
> > On Fri, Jun 12, 2020 at 10:45 PM Raymond Auge  > <mailto:raymond.a...@liferay.com>> wrote:
> >
> > There is one difference between
> >
> > org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable)
> >
> > and
> >
> > org.apache.catalina.startup.Bootstrap.handleThrowable(Throwable)
> >
> > that is that ExceptionUtils also swallows StackOverflowError while
> > Bootstrap does not.
> > Should that be ported over or is it a deal breaker? An option would
> > be to add an additional method to Bootstrap that behaves like
> > ExceptionUtils.
> >
> > - Ray
> >
> >
> > On Fri, Jun 12, 2020 at 9:27 AM Mark Thomas  > <mailto:ma...@apache.org>> wrote:
> >
> > On 12/06/2020 14:15, Raymond Auge wrote:
> > > Hey Mark,
> > >
> > > I'll have to get back to this convo in a day or so.
> > >
> > > I'll test your theory but at first glance it sounds like going
> > in the
> > > right direction.
> >
> > No rush. I'd rather take time and get this right.
> >
> > Thanks,
> >
> > Mark
> >
> >
> > >
> > > - Ray
> > >
> > > On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas  > <mailto:ma...@apache.org>
> > > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> wrote:
> > >
> > > On 11/06/2020 21:59, Mark Thomas wrote:
> > > > On 11/06/2020 21:24, Raymond Auge wrote:
> > > >> This can totally be fixed in configuration. There is no
> > problem.
> > > I just
> > > >> wanted to make sure that in doing so we wouldn't just
> > be pushing some
> > > >> dirt under the rug so to speak.
> > > >
> > > > I'm concerned we might be doing exactly that now we are
> > heading into a
> > > > JPMS world and this seems like an opportunity to pause
> > and see if
> > > there
> > > > is a better way.
> > > >
> > > > I've yet to get my head around JPMS and I might be
> > mis-remembering
> > > some
> > > > of the things I have read.
> > > >
> > > > bootstrap.jar has everything it needs to start, create
> > the class
> > > loader
> > > > hierarchy, switch to the catalinaLoader (which can see
> > all the JARs
> > > > rather than just bootstrap.jar and tomcat-juli.jar) and
> > then continue
> > > > with start-up.
> > > >
> > > > It does things this way because the class loader
> > hierarchy and the
> > > > configuration of the class loaders is configurable. So
> > we can't
> > > just put
> > > > everything on the class path before starting the JVM.
> > > >
> > > > Any static analysis of bootstrap.jar is always going to
> > show it having
> > > > dependencies that won't be visible until Tomcat starts
> > and the
> > > > catalinaLoader is up and running. To what extent does
> > this cause
> > > > complications for JPMS and/or OSGi?
> > > >
> > > > Is this completely manageabl

Re: Bootstrap and modules

[Raymond Auge]

Actually Bootstrap has a comment

// Copied from ExceptionUtils since that class is not visible during start

So it seems like perhaps the change should be ported.

 - Ray

On Fri, Jun 12, 2020 at 10:45 PM Raymond Auge 
wrote:

> There is one difference between
>
> org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable)
>
> and
>
> org.apache.catalina.startup.Bootstrap.handleThrowable(Throwable)
>
> that is that ExceptionUtils also swallows StackOverflowError while
> Bootstrap does not.
> Should that be ported over or is it a deal breaker? An option would be to
> add an additional method to Bootstrap that behaves like ExceptionUtils.
>
> - Ray
>
>
> On Fri, Jun 12, 2020 at 9:27 AM Mark Thomas  wrote:
>
>> On 12/06/2020 14:15, Raymond Auge wrote:
>> > Hey Mark,
>> >
>> > I'll have to get back to this convo in a day or so.
>> >
>> > I'll test your theory but at first glance it sounds like going in the
>> > right direction.
>>
>> No rush. I'd rather take time and get this right.
>>
>> Thanks,
>>
>> Mark
>>
>>
>> >
>> > - Ray
>> >
>> > On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas > > <mailto:ma...@apache.org>> wrote:
>> >
>> > On 11/06/2020 21:59, Mark Thomas wrote:
>> > > On 11/06/2020 21:24, Raymond Auge wrote:
>> > >> This can totally be fixed in configuration. There is no problem.
>> > I just
>> > >> wanted to make sure that in doing so we wouldn't just be pushing
>> some
>> > >> dirt under the rug so to speak.
>> > >
>> > > I'm concerned we might be doing exactly that now we are heading
>> into a
>> > > JPMS world and this seems like an opportunity to pause and see if
>> > there
>> > > is a better way.
>> > >
>> > > I've yet to get my head around JPMS and I might be mis-remembering
>> > some
>> > > of the things I have read.
>> > >
>> > > bootstrap.jar has everything it needs to start, create the class
>> > loader
>> > > hierarchy, switch to the catalinaLoader (which can see all the
>> JARs
>> > > rather than just bootstrap.jar and tomcat-juli.jar) and then
>> continue
>> > > with start-up.
>> > >
>> > > It does things this way because the class loader hierarchy and the
>> > > configuration of the class loaders is configurable. So we can't
>> > just put
>> > > everything on the class path before starting the JVM.
>> > >
>> > > Any static analysis of bootstrap.jar is always going to show it
>> having
>> > > dependencies that won't be visible until Tomcat starts and the
>> > > catalinaLoader is up and running. To what extent does this cause
>> > > complications for JPMS and/or OSGi?
>> > >
>> > > Is this completely manageable with configuration? If it is, I
>> > think I'd
>> > > lean towards a configuration based solution primarily for
>> backwards
>> > > compatibility reasons. What are the arguments against this
>> approach?
>> > >
>> > > If this completely manageable with configuration are there any
>> > > particular classes that are causing more than their fair share of
>> pain
>> > > where a small packaging change would provide a relatively large
>> > benefit?
>> >
>> > Sorry. More thoughts occurred to me as I looked at the PRs again.
>> >
>> > If we created o.a.c.startup.Constants, defined the constants
>> required by
>> > the bootstrap classes there and then referenced those from
>> o.a.c.Globals
>> > would that help?
>> >
>> > Is it Tool's use of ExceptionUtils that is causing that class to be
>> > needed? If so would making Bootstrap.handleThrowable() package
>> private
>> > and using that instead help?
>> >
>> > Mark
>> >
>> > >
>> > > Mark
>> > >
>> > >
>> > >>
>> > >> :)
>> > >>
>> > >> - Ray
>> > >>
>> > >> On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge
>> > mailto:raymond.a...@liferay.com>
>> > &g

Re: Bootstrap and modules

[Raymond Auge]

There is one difference between

org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable)

and

org.apache.catalina.startup.Bootstrap.handleThrowable(Throwable)

that is that ExceptionUtils also swallows StackOverflowError while
Bootstrap does not.
Should that be ported over or is it a deal breaker? An option would be to
add an additional method to Bootstrap that behaves like ExceptionUtils.

- Ray


On Fri, Jun 12, 2020 at 9:27 AM Mark Thomas  wrote:

> On 12/06/2020 14:15, Raymond Auge wrote:
> > Hey Mark,
> >
> > I'll have to get back to this convo in a day or so.
> >
> > I'll test your theory but at first glance it sounds like going in the
> > right direction.
>
> No rush. I'd rather take time and get this right.
>
> Thanks,
>
> Mark
>
>
> >
> > - Ray
> >
> > On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas  > <mailto:ma...@apache.org>> wrote:
> >
> > On 11/06/2020 21:59, Mark Thomas wrote:
> > > On 11/06/2020 21:24, Raymond Auge wrote:
> > >> This can totally be fixed in configuration. There is no problem.
> > I just
> > >> wanted to make sure that in doing so we wouldn't just be pushing
> some
> > >> dirt under the rug so to speak.
> > >
> > > I'm concerned we might be doing exactly that now we are heading
> into a
> > > JPMS world and this seems like an opportunity to pause and see if
> > there
> > > is a better way.
> > >
> > > I've yet to get my head around JPMS and I might be mis-remembering
> > some
> > > of the things I have read.
> > >
> > > bootstrap.jar has everything it needs to start, create the class
> > loader
> > > hierarchy, switch to the catalinaLoader (which can see all the JARs
> > > rather than just bootstrap.jar and tomcat-juli.jar) and then
> continue
> > > with start-up.
> > >
> > > It does things this way because the class loader hierarchy and the
> > > configuration of the class loaders is configurable. So we can't
> > just put
> > > everything on the class path before starting the JVM.
> > >
> > > Any static analysis of bootstrap.jar is always going to show it
> having
> > > dependencies that won't be visible until Tomcat starts and the
> > > catalinaLoader is up and running. To what extent does this cause
> > > complications for JPMS and/or OSGi?
> > >
> > > Is this completely manageable with configuration? If it is, I
> > think I'd
> > > lean towards a configuration based solution primarily for backwards
> > > compatibility reasons. What are the arguments against this
> approach?
> > >
> > > If this completely manageable with configuration are there any
> > > particular classes that are causing more than their fair share of
> pain
> > > where a small packaging change would provide a relatively large
> > benefit?
> >
> > Sorry. More thoughts occurred to me as I looked at the PRs again.
> >
> > If we created o.a.c.startup.Constants, defined the constants
> required by
> > the bootstrap classes there and then referenced those from
> o.a.c.Globals
> > would that help?
> >
> > Is it Tool's use of ExceptionUtils that is causing that class to be
> > needed? If so would making Bootstrap.handleThrowable() package
> private
> > and using that instead help?
> >
> > Mark
> >
> > >
> > > Mark
> > >
> > >
> > >>
> > >> :)
> > >>
> > >> - Ray
> > >>
> > >> On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge
> > mailto:raymond.a...@liferay.com>
> > >> <mailto:raymond.a...@liferay.com
> > <mailto:raymond.a...@liferay.com>>> wrote:
> > >>
> > >> To be clear, it's not necessarily having _all of a package_.
> It's
> > >> more about all the reachable class references. For instance
> jdeps
> > >> looks at classes and finds any reachable references. So does
> > bnd for
> > >> calculating OSGi metadata.
> > >>
> > >> So the issue is not really about packages, it's about having
> > missing
> > >> class references and whether those should be elided in
> > >> 

Re: Bootstrap and modules

[Raymond Auge]

Hey Mark,

I'll have to get back to this convo in a day or so.

I'll test your theory but at first glance it sounds like going in the right
direction.

- Ray

On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas  wrote:

> On 11/06/2020 21:59, Mark Thomas wrote:
> > On 11/06/2020 21:24, Raymond Auge wrote:
> >> This can totally be fixed in configuration. There is no problem. I just
> >> wanted to make sure that in doing so we wouldn't just be pushing some
> >> dirt under the rug so to speak.
> >
> > I'm concerned we might be doing exactly that now we are heading into a
> > JPMS world and this seems like an opportunity to pause and see if there
> > is a better way.
> >
> > I've yet to get my head around JPMS and I might be mis-remembering some
> > of the things I have read.
> >
> > bootstrap.jar has everything it needs to start, create the class loader
> > hierarchy, switch to the catalinaLoader (which can see all the JARs
> > rather than just bootstrap.jar and tomcat-juli.jar) and then continue
> > with start-up.
> >
> > It does things this way because the class loader hierarchy and the
> > configuration of the class loaders is configurable. So we can't just put
> > everything on the class path before starting the JVM.
> >
> > Any static analysis of bootstrap.jar is always going to show it having
> > dependencies that won't be visible until Tomcat starts and the
> > catalinaLoader is up and running. To what extent does this cause
> > complications for JPMS and/or OSGi?
> >
> > Is this completely manageable with configuration? If it is, I think I'd
> > lean towards a configuration based solution primarily for backwards
> > compatibility reasons. What are the arguments against this approach?
> >
> > If this completely manageable with configuration are there any
> > particular classes that are causing more than their fair share of pain
> > where a small packaging change would provide a relatively large benefit?
>
> Sorry. More thoughts occurred to me as I looked at the PRs again.
>
> If we created o.a.c.startup.Constants, defined the constants required by
> the bootstrap classes there and then referenced those from o.a.c.Globals
> would that help?
>
> Is it Tool's use of ExceptionUtils that is causing that class to be
> needed? If so would making Bootstrap.handleThrowable() package private
> and using that instead help?
>
> Mark
>
> >
> > Mark
> >
> >
> >>
> >> :)
> >>
> >> - Ray
> >>
> >> On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge  >> <mailto:raymond.a...@liferay.com>> wrote:
> >>
> >> To be clear, it's not necessarily having _all of a package_. It's
> >> more about all the reachable class references. For instance jdeps
> >> looks at classes and finds any reachable references. So does bnd for
> >> calculating OSGi metadata.
> >>
> >> So the issue is not really about packages, it's about having missing
> >> class references and whether those should be elided in
> >> configuration, or simple fixed in packaging (which again does not
> >> necessarily mean full packages :)
> >>
> >> - Ray
> >>
> >> On Thu, Jun 11, 2020 at 3:20 PM Rémy Maucherat  >> <mailto:r...@apache.org>> wrote:
> >>
> >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas  >> <mailto:ma...@apache.org>> wrote:
> >>
> >> Hi,
> >>
> >> As discussed in PR#298 [1], properly/fully/correctly
> >> supporting JPMS /
> >> OSGi gets trickier than necessary with the bootstrap JAR
> >> because of the
> >> way we currently package it with the minimum that it needs
> >> and duplicate
> >> some classes.
> >>
> >> My simplistic understanding is that having all of a Java
> >> package in a
> >> single JAR makes JPMS and OSGi a lot simpler. Further, our
> >> current
> >> approach may not be 100% compatible with one or both of
> them.
> >>
> >> The trade-offs involved here are:
> >> - having all of a package in a JAR simplifies JPMS and OSGi
> >> - We want to keep the bootstrap JAR small (is this much of a
> >> concern?)
> >> - We don't want duplicate code (maintenance overhead)
> >

Re: Bootstrap and modules

[Raymond Auge]

This can totally be fixed in configuration. There is no problem. I just
wanted to make sure that in doing so we wouldn't just be pushing some dirt
under the rug so to speak.

:)

- Ray

On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge 
wrote:

> To be clear, it's not necessarily having _all of a package_. It's more
> about all the reachable class references. For instance jdeps looks at
> classes and finds any reachable references. So does bnd for calculating
> OSGi metadata.
>
> So the issue is not really about packages, it's about having missing class
> references and whether those should be elided in configuration, or simple
> fixed in packaging (which again does not necessarily mean full packages :)
>
> - Ray
>
> On Thu, Jun 11, 2020 at 3:20 PM Rémy Maucherat  wrote:
>
>> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas  wrote:
>>
>>> Hi,
>>>
>>> As discussed in PR#298 [1], properly/fully/correctly supporting JPMS /
>>> OSGi gets trickier than necessary with the bootstrap JAR because of the
>>> way we currently package it with the minimum that it needs and duplicate
>>> some classes.
>>>
>>> My simplistic understanding is that having all of a Java package in a
>>> single JAR makes JPMS and OSGi a lot simpler. Further, our current
>>> approach may not be 100% compatible with one or both of them.
>>>
>>> The trade-offs involved here are:
>>> - having all of a package in a JAR simplifies JPMS and OSGi
>>> - We want to keep the bootstrap JAR small (is this much of a concern?)
>>> - We don't want duplicate code (maintenance overhead)
>>> - Bootstrap uses various utility functions from the Tomcat code base
>>>
>>> I'm wondering if there is a better approach we could adopt that makes
>>> JPMS / OSGi simpler without compromising too much on the other
>>> trade-offs.
>>>
>>> The sort of thing I have in mind is:
>>> - move everything out of o.a.c.startup that doesn't need to be there to
>>>   either some new package (name TBD) or an existing package
>>>
>>
>> That means way too many risky changes IMO, the listeners in the startup
>> package are often extended to add features so they need to remain in the
>> catalina.startup package.
>>
>>
>>> - create an o.a.c.startup.util package and, during the build process,
>>>   copy and package rename any utility classes the remaining classes in
>>>   o.a.c.startup depend on
>>>
>>
>> Good idea, when I read your requirements, I thought about package
>> renaming. So I think we could use package renaming for everything that
>> bootstrap.jar has to a tomcat.bootstrap or catalina.bootstrap package.
>>
>> Rémy
>>
>>
>>>
>>> The end result should be a nice clean mapping of packages to JARs.
>>>
>>> Thoughts?
>>>
>>> Mark
>>>
>>>
>>>
>>> [1] https://github.com/apache/tomcat/pull/298
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Re: Bootstrap and modules

[Raymond Auge]

To be clear, it's not necessarily having _all of a package_. It's more
about all the reachable class references. For instance jdeps looks at
classes and finds any reachable references. So does bnd for calculating
OSGi metadata.

So the issue is not really about packages, it's about having missing class
references and whether those should be elided in configuration, or simple
fixed in packaging (which again does not necessarily mean full packages :)

- Ray

On Thu, Jun 11, 2020 at 3:20 PM Rémy Maucherat  wrote:

> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas  wrote:
>
>> Hi,
>>
>> As discussed in PR#298 [1], properly/fully/correctly supporting JPMS /
>> OSGi gets trickier than necessary with the bootstrap JAR because of the
>> way we currently package it with the minimum that it needs and duplicate
>> some classes.
>>
>> My simplistic understanding is that having all of a Java package in a
>> single JAR makes JPMS and OSGi a lot simpler. Further, our current
>> approach may not be 100% compatible with one or both of them.
>>
>> The trade-offs involved here are:
>> - having all of a package in a JAR simplifies JPMS and OSGi
>> - We want to keep the bootstrap JAR small (is this much of a concern?)
>> - We don't want duplicate code (maintenance overhead)
>> - Bootstrap uses various utility functions from the Tomcat code base
>>
>> I'm wondering if there is a better approach we could adopt that makes
>> JPMS / OSGi simpler without compromising too much on the other trade-offs.
>>
>> The sort of thing I have in mind is:
>> - move everything out of o.a.c.startup that doesn't need to be there to
>>   either some new package (name TBD) or an existing package
>>
>
> That means way too many risky changes IMO, the listeners in the startup
> package are often extended to add features so they need to remain in the
> catalina.startup package.
>
>
>> - create an o.a.c.startup.util package and, during the build process,
>>   copy and package rename any utility classes the remaining classes in
>>   o.a.c.startup depend on
>>
>
> Good idea, when I read your requirements, I thought about package
> renaming. So I think we could use package renaming for everything that
> bootstrap.jar has to a tomcat.bootstrap or catalina.bootstrap package.
>
> Rémy
>
>
>>
>> The end result should be a nice clean mapping of packages to JARs.
>>
>> Thoughts?
>>
>> Mark
>>
>>
>>
>> [1] https://github.com/apache/tomcat/pull/298
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

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

Re: Improving OSGi/bnd build and much more...

[Raymond Auge]

Thanks for the feedback. I'll look at each point carefully.

I can report though that tests are looking relatively good. Only a few
failures:

TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt:Tests
run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt:Tests
run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt:Tests
run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt:Tests
run: 86, Failures: 10, Errors: 0, Skipped: 1, Time elapsed: 0.283 sec
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt:Tests
run: 86, Failures: 10, Errors: 0, Skipped: 1, Time elapsed: 0.287 sec
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt:Tests
run: 86, Failures: 10, Errors: 0, Skipped: 1, Time elapsed: 0.281 sec
TEST-org.apache.tomcat.util.res.TestStringManager.APR.txt:Tests run: 5,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
TEST-org.apache.tomcat.util.res.TestStringManager.NIO2.txt:Tests run: 5,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
TEST-org.apache.tomcat.util.res.TestStringManager.NIO.txt:Tests run: 5,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec

:)

On Tue, Jun 9, 2020 at 2:54 PM Mark Thomas  wrote:

> On 09/06/2020 18:37, Raymond Auge wrote:
> > Hey All (particularly Markt whom I spoke with about this months and
> > months ago),
> >
> > Noting that bnd was already added to the build I took a crack at making
> > better use of it.
> >
> > Here are a few items and some questions in no particular order:
> >
> > - you don't use bndlib, can we remove that? bnd is fully standalone for
> > your purposes and is all you need
>
> If we don't need it then +1 to dropping it.
>
> > - bootstrap.jar in master seems to be missing the class
> > `org.apache.tomcat.util.ExceptionUtils` at least from a dependency
> > analysis point of view, should it be included in the files list?
>
> No sure. That needs some more careful thought / analysis.
>
> > - tomcat-embed-core.jar appears to be missing tribes dependency (at
> > least it refers to it but does not include it) Shouldn't it really
> > contain all of catalina (minus catalina-ant?)
>
> That is deliberate.
>
> > - files.tomcat-embed-core seems to reference an old package
> > org/apache/jk/**, can we remove that?
>
> Yes, that can be removed.
>
> > - I've split out the i18n LocalStrings_* (the locale specific ones) into
> > a separate output dir so that you wouldn't have to then filter them out,
> > it makes building their zips also cleaner, does that sound logical?
>
> I'd want to see the patch for that first.
>
> > - I moved a slew of concerns that bnd could handle out of ant and
> > directly into the bnd configurations, manifest filtering, etc., bnd has
> > filtering capability built in and knows about all ant properties so this
> > eliminates ant work, comments on that?
>
> Again, I'd want to see the patch for that.
>
> > - generated all the Name sections for spec API packages instead of
> > maintaining those by hand (now they are complete)
>
> Sounds good.
>
> > - add all the correct OSGi metadata of course to the spec jars and to
> > everyone else.
>
> Sounds good. Note the naming convention may have changed in the move
> from Java EE to Jakarta EE.
>
> > - I've added bnd's JPMS build support to all the modules, still builds
> > on Java 8, and you get JPMS module-info almost for free (very small
> > amount of configurable bits)
>
> Generally sounds good. My only concern is consistency for the spec JARs.
>
> > Could someone provide the build instruction I'd need to do the most
> > throughout test build? I see that there's a .travis script which does
> > `ant -q test 2>&1 > ant-test.log` is that really all?
>
> Yes, assuming you have properties set to point to a valid Tomcat Native
> build.
>
> > Shall I create an SVN branch to explore this? Or would a git PR be
> enough?
>
> I'd recommend tacking this one issue at a time. PRs would be fine for
> that. Some should be pretty quick.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)

Improving OSGi/bnd build and much more...

[Raymond Auge]

Hey All (particularly Markt whom I spoke with about this months and months
ago),

Noting that bnd was already added to the build I took a crack at making
better use of it.

Here are a few items and some questions in no particular order:

- you don't use bndlib, can we remove that? bnd is fully standalone for
your purposes and is all you need
- bootstrap.jar in master seems to be missing the class
`org.apache.tomcat.util.ExceptionUtils` at least from a dependency analysis
point of view, should it be included in the files list?
- tomcat-embed-core.jar appears to be missing tribes dependency (at least
it refers to it but does not include it) Shouldn't it really contain all of
catalina (minus catalina-ant?)
- files.tomcat-embed-core seems to reference an old package
org/apache/jk/**, can we remove that?
- I've split out the i18n LocalStrings_* (the locale specific ones) into a
separate output dir so that you wouldn't have to then filter them out, it
makes building their zips also cleaner, does that sound logical?
- I moved a slew of concerns that bnd could handle out of ant and directly
into the bnd configurations, manifest filtering, etc., bnd has filtering
capability built in and knows about all ant properties so this eliminates
ant work, comments on that?
- generated all the Name sections for spec API packages instead of
maintaining those by hand (now they are complete)
- add all the correct OSGi metadata of course to the spec jars and to
everyone else.
- I've added bnd's JPMS build support to all the modules, still builds on
Java 8, and you get JPMS module-info almost for free (very small amount of
configurable bits)

Could someone provide the build instruction I'd need to do the most
throughout test build? I see that there's a .travis script which does `ant
-q test 2>&1 > ant-test.log` is that really all?

Shall I create an SVN branch to explore this? Or would a git PR be enough?
-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

Re: [Bug 63555] embedded jar manifests missing automatic module names

[Raymond Auge]

On Fri, Jul 26, 2019 at 11:33 AM Mark Thomas  wrote:

> On 26/07/2019 16:27, Raymond Auge wrote:
> > .. maybe I can play with it over the next months.
>
> Thanks. Much appreciated. We'll at least need to wait for a bnd 4.3.0
> release. Although I suspect that will happen before Jakarta EE makes any
> decision regarding JPMS.
>

Certainly. The currently timeline for release is end of August.

- Ray


>
> Cheers,
>
> Mark
>
>
> >
> > - Ray
> >
> > On Fri, Jul 26, 2019 at 11:24 AM  > <mailto:bugzi...@apache.org>> wrote:
> >
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=63555
> >
> > --- Comment #3 from Raymond Augé  > <mailto:rotty3...@apache.org>> ---
> > When you get back to this let me know if I can help with bnd.
> >
> > --
> > You are receiving this mail because:
> > You are the assignee for the bug.
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
> >
> >
> > --
> > *Raymond Augé*
> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> > Senior Software Architect *Liferay, Inc.*
> > <http://www.liferay.com> (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Re: [Bug 63555] embedded jar manifests missing automatic module names

[Raymond Auge]

.. maybe I can play with it over the next months.

- Ray

On Fri, Jul 26, 2019 at 11:24 AM  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=63555
>
> --- Comment #3 from Raymond Augé  ---
> When you get back to this let me know if I can help with bnd.
>
> --
> 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
>
>

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Constants.IS_SECURITY_ENABLED

[Raymond Auge]

On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas ma...@apache.org wrote:

 On 18/08/2013 20:06, Raymond Auge wrote:
  On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas ma...@apache.org wrote:

  First of all this is a container concern, not an application
  concern. Secondly, a security manager applies JVM wide.


I agree 100%

However, in this case the JSP impl is preventing the container itself from
making any such change! The JSP impl has no business making the decision on
behalf of either the container or JVM.



 snip/

  Nowhere in any specification is this stated!

 Maybe not in language that is immediately clear but this is stated in
 the J2EE platform specification. (section EE.6.2.2)



I infer no such meaning from the EE spec. I fact the spec seems to go out
of it's way to avoid claiming what is NOT allowed and only talks about what
is minimally required by each of the stackholders.

Furthermore, why couldn't any of EE.6.2.2.3 System Administrator’s
Responsibilities be implemented as a web application designed to simplify
management of these responsibilities?

As long as the policies imposed by the administrator are respected, why
does it matter where policy management takes place?

In fact, if I'm not mistaken one significant point for the JVM's Security
API being dynamic as opposed to being completely static, is so that
management can be performed, either programmatically, or
remotely (otherwise why would these APIs even exist were that not the case).

snip/

.. none of which explains why the Jasper retains static final check of
whether security manager is enabled or not.

Sincerely,
- Ray




 Mark


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




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)

Re: Constants.IS_SECURITY_ENABLED

[Raymond Auge]

Fair enough!

Thank you


On Mon, Aug 19, 2013 at 4:49 PM, Mark Thomas ma...@apache.org wrote:

 On 19/08/2013 21:11, Raymond Auge wrote:
  On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas ma...@apache.org wrote:
 
  On 18/08/2013 20:06, Raymond Auge wrote:
  On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas ma...@apache.org wrote:
 
  First of all this is a container concern, not an application
  concern. Secondly, a security manager applies JVM wide.
 
 
  I agree 100%
 
  However, in this case the JSP impl is preventing the container itself
 from
  making any such change!

 No it isn't. Tomcat provides configuration options to start the
 container with or without a SecurityManager. Tomcat provides no options
 to configure the SecurityManager dynamically.

  The JSP impl has no business making the decision on
  behalf of either the container or JVM.

 The JSP implementation is part of the container. Design decisions made
 for one can have an impact on the other.

  snip/
 
  Nowhere in any specification is this stated!
 
  Maybe not in language that is immediately clear but this is stated in
  the J2EE platform specification. (section EE.6.2.2)
 
 
  I infer no such meaning from the EE spec.

 You miss my point. My point is that this is a container concern. The
 spec makes that clear.

  Furthermore, why couldn't any of EE.6.2.2.3 System Administrator’s
  Responsibilities be implemented as a web application designed to
 simplify
  management of these responsibilities?

 They could. Tomcat does not implement that way.

  As long as the policies imposed by the administrator are respected, why
  does it matter where policy management takes place?

 It doesn't. That is a design choice for container implementers.

  In fact, if I'm not mistaken one significant point for the JVM's Security
  API being dynamic as opposed to being completely static, is so that
  management can be performed, either programmatically, or
  remotely (otherwise why would these APIs even exist were that not the
 case).
 
  snip/
 
  .. none of which explains why the Jasper retains static final check of
  whether security manager is enabled or not.

 Because Tomcat only provides options to configure a SecurityManager on
 start-up.

 If Tomcat was going to implement dynamic configuration of the
 SecurityManager then the various IS_SECURITY_ENABLED constants would
 need to be removed.

 Mark


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




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)

Re: Constants.IS_SECURITY_ENABLED

[Raymond Auge]

I've filed a bugs:

https://java.net/jira/browse/JSP-37
https://issues.apache.org/bugzilla/show_bug.cgi?id=55446


On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge raymond.a...@liferay.comwrote:

 Hello everyone,

 My name is Raymond Auge and this is my first message to the list.
 Hopefully I follow protocol correctly. Let me know if I don't.

 

 org.apache.jasper.Constants.IS_SECURITY_ENABLED

 is a global (static final) constant. As such it is evaluated exactly once.

 Since Jasper is typically provided as part of the app server this means
 it's impossible for some later module to enable Java security dynamically.

 The Java security API is clearly dynamic. It allows for the creation of
 both security managers and policies created and registered at runtime.

 The JVM itself always performs dynamic evaluation of security (normally
 the very same null check which is stored by IS_SECURITY_ENABLED.

 Scenario demonstrating a problem:

 1) start tomcat normally (no security)
 2) assuming any normal app is initialized, a JspRuntimeContext will be
 created and at first invocation

 Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);

 is evaluated.

 3) deploy some later component (ie. a webapp) which does:

 System.setSecurityManager(new SecurityManager());

 4) from that point, all Jasper code will provide the incorrect state, app
 server wide

 I realize this is a very long standing mechanism. I'm wondering what would
 be the odds of accepting a patch which enables a dynamic check as opposed
 to global constant.

 A further change would be required to initialize security dynamically
 which I think could be done simply enough without incurring significant
 performance issue.

 BTW, this issue affects every app server which uses Jasper (including
 users of the JSR RI in the Glassfish project)

 Any thoughts?


 Sincerely,
 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com (@Liferay)




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)

Re: Constants.IS_SECURITY_ENABLED

[Raymond Auge]

On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas ma...@apache.org wrote:

 On 18/08/2013 17:34, Raymond Auge wrote:
  I've filed a bugs:
 
  https://java.net/jira/browse/JSP-37
  https://issues.apache.org/bugzilla/show_bug.cgi?id=55446

 And I have closed the Tomcat one as invalid.

  On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge raymond.a...@liferay.com
 wrote:
  Since Jasper is typically provided as part of the app server this means
  it's impossible for some later module to enable Java security
 dynamically.

 Correct. This is by design.

  The Java security API is clearly dynamic. It allows for the creation of
  both security managers and policies created and registered at runtime.
 
  The JVM itself always performs dynamic evaluation of security (normally
  the very same null check which is stored by IS_SECURITY_ENABLED.

 Irrelevant.

  Scenario demonstrating a problem:
 
  1) start tomcat normally (no security)
  2) assuming any normal app is initialized, a JspRuntimeContext will be
  created and at first invocation
 
  Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);
 
  is evaluated.
 
  3) deploy some later component (ie. a webapp) which does:
 
  System.setSecurityManager(new SecurityManager());

 Web applications have no business trying to configure a security
 manager. First of all this is a container concern, not an application
 concern. Secondly, a security manager applies JVM wide. An application
 has no way to determine how to configure a security manager to enable
 any other applications to operate correctly. This is why it is a
 container concern where the deployer can determine a) if they require a
 security manager in their environment (something else an application has
 no way of determining) and b) what an appropriate security policy is for
 their environment.



Nowhere in any specification is this stated! Why can't a web application
declare and provide a security manager?



  I realize this is a very long standing mechanism. I'm wondering what
 would
  be the odds of accepting a patch which enables a dynamic check as
 opposed
  to global constant.

 Zero. I would veto any commit that applied such a patch.

  A further change would be required to initialize security dynamically
  which I think could be done simply enough without incurring significant
  performance issue.
 
  BTW, this issue affects every app server which uses Jasper (including
  users of the JSR RI in the Glassfish project)
 
  Any thoughts?

 You haven't thought through the implications of your proposal nor the
 practicalities of how it would work. The point being that it couldn't work.

 Mark



Thanks for your support.


-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)