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: Integrating migration tool into Tomcat 10

[Mark Thomas]

On 10/02/2021 17:13, Christopher Schultz wrote:
> Mark,
> 
> On 2/9/21 16:12, Mark Thomas wrote:
>> The hard part
>> here is the identification of the webapp as a Java EE app. The only
>> reliable way to do this is class scanning and that is slow.
> 
> Why not look at the system id or namespace of WEB-INF/web.xml? Anyone
> using the legacy Java EE will be using web-app with a low version and a
> namespace like http://xmlns.jcp.org/xml/ns/javaee instead of
> https://jakarta.ee/xml/ns/jakartaee.

Because Jakarta EE compliant apps can still use Java EE schemas. Use of
an old schema is not a guarantee of which API is being used.

>> A final point, which probably should have been first, is is there a
>> demand for this feature? Early indications from the users list and $work
>> is that there is (going to be) a demand for this feature.
> 
> Being able to drop your old, crufty web application onto Tomcat 10 (or
> 11?) will be an absolutely killer feature.
> 
> How many times have we had someone email the users list asking for help
> upgrading their Tomcat from 4.1 -> 9.0 and something breaks and "the
> original developer is gone; I don't know Java; I've been told this is
> high-priority and just need it done by Friday"?

Indeed.

> A feature like this can really help those situations.
> 
> One possible response to this would be "don't abandon your software; get
> your vendor to re-package the application for you" or something similar.
> But some applications, while "old" don't necessarily require conversion
> because they work /just fine/.
> 
> If this feature existed today, I would *immediately* test my own
> application on it to see if it worked (and possibly consider a migration
> to Tomcat 10 in the near-term instead of dreading it). I currently have
> zero interest in downloading the conversion tool, building it, figuring
> out how to invoke it and then install the converted WAR file into a new
> version of Tomcat. It wouldn't surprise me if there are a LOT of people
> out there feeling the same way.

Ack. I wouldn't be surprised either.

Don't forget there will always be the Tomcat 9.x version which tracks
that latest Tomcat codebase but retains the Java EE 8 API. That provides
a support route that doesn't require conversion.

Mark

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

Re: Integrating migration tool into Tomcat 10

[Christopher Schultz]

Mark,

On 2/9/21 16:12, Mark Thomas wrote:

The hard part
here is the identification of the webapp as a Java EE app. The only
reliable way to do this is class scanning and that is slow.


Why not look at the system id or namespace of WEB-INF/web.xml? Anyone 
using the legacy Java EE will be using web-app with a low version and a 
namespace like http://xmlns.jcp.org/xml/ns/javaee instead of 
https://jakarta.ee/xml/ns/jakartaee.



A final point, which probably should have been first, is is there a
demand for this feature? Early indications from the users list and $work
is that there is (going to be) a demand for this feature.


Being able to drop your old, crufty web application onto Tomcat 10 (or 
11?) will be an absolutely killer feature.


How many times have we had someone email the users list asking for help 
upgrading their Tomcat from 4.1 -> 9.0 and something breaks and "the 
original developer is gone; I don't know Java; I've been told this is 
high-priority and just need it done by Friday"?


A feature like this can really help those situations.

One possible response to this would be "don't abandon your software; get 
your vendor to re-package the application for you" or something similar. 
But some applications, while "old" don't necessarily require conversion 
because they work /just fine/.


If this feature existed today, I would *immediately* test my own 
application on it to see if it worked (and possibly consider a migration 
to Tomcat 10 in the near-term instead of dreading it). I currently have 
zero interest in downloading the conversion tool, building it, figuring 
out how to invoke it and then install the converted WAR file into a new 
version of Tomcat. It wouldn't surprise me if there are a LOT of people 
out there feeling the same way.


-chris

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

[Bug 65135] New: mbeans-descriptors.xml missing attribute for parallelAnnotationScanning

[bugzilla]

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

Bug ID: 65135
   Summary: mbeans-descriptors.xml missing attribute for
parallelAnnotationScanning
   Product: Tomcat 9
   Version: 9.0.41
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: mich...@bigmichi1.de
  Target Milestone: -

when the "parallelAnnotationScanning" property was introduced in
StandardContext the descriptor file mbeans-descriptors.xml was also changed
see
https://github.com/apache/tomcat/commit/101476c3536ac09a105d0b603b2c51dd0f3770e9
but is missing the `is="true"` attribute. without that attribute all calls to
the JmxProxyServlet are causing an error that is written to the catalina.out


10-Feb-2021 17:43:56.703 SCHWERWIEGEND [http-nio-8080-exec-1]
org.apache.catalina.mbeans.MBeanDumper.dumpBeans Error getting attribute
[parallelAnnotationScanning] for object name
[Catalina:j2eeType=WebModule,name=//localhost/example,J2EEApplication=none,J2EEServer=none]
javax.management.ReflectionException: Cannot find getter method
[getParallelAnnotationScanning] on resource
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/example]]
at
org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:457)
at
org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:168)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
at
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
org.apache.catalina.mbeans.MBeanDumper.dumpBeans(MBeanDumper.java:87)
at
org.apache.catalina.manager.JMXProxyServlet.listBeans(JMXProxyServlet.java:193)
at
org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:129)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:626)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
...
Caused by: java.lang.NoSuchMethodException:
org.apache.catalina.core.StandardContext.getParallelAnnotationScanning()
at java.base/java.lang.Class.getMethod(Class.java:2201)
at
org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:450)
... 57 more

the get method is defined in StandardContext as `boolean
isParallelAnnotationScanning()` but because of the missing is=true it Is
expected to find a method `boolean getParallelAnnotationScanning()`

this bug is present in all versions since 9.0.39

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

Re: Integrating migration tool into Tomcat 10

[Mark Thomas]

On 10/02/2021 16:29, Romain Manni-Bucau wrote:
> Le mer. 10 févr. 2021 à 17:15, Emmanuel Bourg  a écrit :
> 
>> Le 2021-02-10 16:36, Rémy Maucherat a écrit :
>>
>>> After reading everything, I'd say it's worth adding a second integrated
>>> option, and think I'm now swaying towards the runtime option. The main
>>> problem would be the detection of legacy webapps. We could simply
>>> mandate
>>> using an explicit new attribute on the Context element (and done !) so
>>> nobody pays any needless costs.
>>
>> The runtime option still incurs a cost for the legacy applications
>> because the classes and the resources have to be filtered every time the
>> application is started. Ideally the application should be converted only
>> once.
>>
> 
> Tomcat has work/ folder for that purpose. The ClassFileTransformer and
> WebResourceFilter can dump the outputs in work/ and load it from there when
> needed at restart making it almost negligible.

What you are describing is a lazy init version of the convert at
deployment. The runtime solution is starting to look a lot more complex
than the deploy time solution.

The WebResourceFilter may be non-trivial to implement. Filtering of
static resources accessed directly is relatively simple to implement -
there is code doing this for a limited subset of cases already - but
handing resources in JARs, WARS and JARS nested in WARs will be more
complex.

Another thought has occurred to me after testing the migration tool with
Jira. There are a handful of ways that applications could obtain
resources that would not be caught (and could not be caught) by the
WebResourceFilter. Migration at the time of deployment avoids these issues.

While we don;t seem to have much consensus so far, one point we do seem
to have consensus on is that the user will need to do something to
identify the application as needing conversion.

Mark

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

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

[Mark Thomas]

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

Re: Integrating migration tool into Tomcat 10

[Romain Manni-Bucau]

Le mer. 10 févr. 2021 à 17:15, Emmanuel Bourg  a écrit :

> Le 2021-02-10 16:36, Rémy Maucherat a écrit :
>
> > After reading everything, I'd say it's worth adding a second integrated
> > option, and think I'm now swaying towards the runtime option. The main
> > problem would be the detection of legacy webapps. We could simply
> > mandate
> > using an explicit new attribute on the Context element (and done !) so
> > nobody pays any needless costs.
>
> The runtime option still incurs a cost for the legacy applications
> because the classes and the resources have to be filtered every time the
> application is started. Ideally the application should be converted only
> once.
>

Tomcat has work/ folder for that purpose. The ClassFileTransformer and
WebResourceFilter can dump the outputs in work/ and load it from there when
needed at restart making it almost negligible.


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

[tomcat-jakartaee-migration] branch master updated: Add a few more default excludes

[markt]

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

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


The following commit(s) were added to refs/heads/master by this push:
 new ff68194  Add a few more default excludes
ff68194 is described below

commit ff6819437050bc2e4fa9974cece1b022998e4754
Author: Mark Thomas 
AuthorDate: Wed Feb 10 16:16:33 2021 +

Add a few more default excludes
---
 src/main/java/org/apache/tomcat/jakartaee/Migration.java | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/main/java/org/apache/tomcat/jakartaee/Migration.java 
b/src/main/java/org/apache/tomcat/jakartaee/Migration.java
index e8c39b6..59d4600 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/Migration.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/Migration.java
@@ -67,6 +67,10 @@ public class Migration {
 // Bouncy Castle JCE provider
 DEFAULT_EXCLUDES.add("bcprov*.jar");
 DEFAULT_EXCLUDES.add("bcpkix*.jar");
+// Closure compiler
+DEFAULT_EXCLUDES.add("closure-compiler-*.jar");
+// Eclipse compiler for Java
+DEFAULT_EXCLUDES.add("ecj-*.jar");
 // Hystrix
 DEFAULT_EXCLUDES.add("hystrix-core-*.jar");
 DEFAULT_EXCLUDES.add("hystrix-serialization-*.jar");


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

Re: Integrating migration tool into Tomcat 10

[Emmanuel Bourg]

Le 2021-02-10 16:36, Rémy Maucherat a écrit :


After reading everything, I'd say it's worth adding a second integrated
option, and think I'm now swaying towards the runtime option. The main
problem would be the detection of legacy webapps. We could simply 
mandate

using an explicit new attribute on the Context element (and done !) so
nobody pays any needless costs.


The runtime option still incurs a cost for the legacy applications 
because the classes and the resources have to be filtered every time the 
application is started. Ideally the application should be converted only 
once.


Emmanuel Bourg

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

Re: Integrating migration tool into Tomcat 10

[Romain Manni-Bucau]

Le mer. 10 févr. 2021 à 16:37, Rémy Maucherat  a écrit :

> On Tue, Feb 9, 2021 at 10:12 PM Mark Thomas  wrote:
>
> > Hi all,
> >
> > I've been looking at the options to integrate the Java EE to Jakarta EE
> > migration functionality into Tomcat 10.
> >
> > There are essentially two ways to do this: deployment time and runtime.
> >
> > The simplest solution to implement is probably a separate webapps-legacy
> > directory (or some other name) where WARs and DIRs added to that
> > directory get converted to Jakarta EE with the new version being placed
> > in the webapps directory. There are complexities (such as handling an
> > updates of the legacy WAR) but they should be manageable.
> >
> > A more complex version of the deploy time solution has the legacy web
> > application placed in webapps, identified as a legacy webapp and then
> > replaced with the new version (several ways to do this). The hard part
> > here is the identification of the webapp as a Java EE app. The only
> > reliable way to do this is class scanning and that is slow.
> >
> > The runtime approach converts classes and static resources as they are
> > loaded. The classes are relatively easy to handle. A
> > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > The static files are more of a problem. The good news is that the
> > WebResources refactoring means static file access all goes through the
> > same code but the filtering required essentially means we'd need to load
> > static files into memory - regardless of size, convert them, and then
> > update the cache with the converted version. That is likely to have a
> > performance impact.
> >
> > Because of the performance impacts of handling static resources, the
> > runtime approach also needs a way to identify applications that need
> > conversion. I don't see a reliable, performant way to do that. Which, I
> > think, leaves us with the simple deployment time approach and something
> > (filename, special directory, something else) to mark an app as needing
> > conversion.
> >
> > A final point, which probably should have been first, is is there a
> > demand for this feature? Early indications from the users list and $work
> > is that there is (going to be) a demand for this feature.
> >
> > Thoughts?
> >
>
> Overall it seems more people would like it now, for various reasons.
> However, there's zero consensus on how since everyone came up with a
> different idea.
>
> I'd like to note the tool is the appropriate solution for most cases, so we
> cover that already. The main problem with the tool is the perceived effort
> from users.
>
> After reading everything, I'd say it's worth adding a second integrated
> option, and think I'm now swaying towards the runtime option. The main
> problem would be the detection of legacy webapps. We could simply mandate
> using an explicit new attribute on the Context element (and done !) so
> nobody pays any needless costs.
>

s/attribute/listener/ ? the context listener can install the class file
transformer + webresource filter wrapper programmatically and is a one
liner for end user. Wdyt?


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

Re: Integrating migration tool into Tomcat 10

[Rémy Maucherat]

On Tue, Feb 9, 2021 at 10:12 PM Mark Thomas  wrote:

> Hi all,
>
> I've been looking at the options to integrate the Java EE to Jakarta EE
> migration functionality into Tomcat 10.
>
> There are essentially two ways to do this: deployment time and runtime.
>
> The simplest solution to implement is probably a separate webapps-legacy
> directory (or some other name) where WARs and DIRs added to that
> directory get converted to Jakarta EE with the new version being placed
> in the webapps directory. There are complexities (such as handling an
> updates of the legacy WAR) but they should be manageable.
>
> A more complex version of the deploy time solution has the legacy web
> application placed in webapps, identified as a legacy webapp and then
> replaced with the new version (several ways to do this). The hard part
> here is the identification of the webapp as a Java EE app. The only
> reliable way to do this is class scanning and that is slow.
>
> The runtime approach converts classes and static resources as they are
> loaded. The classes are relatively easy to handle. A
> ClassFileTransformer can be added to the WebappClassLoader to do this.
> The static files are more of a problem. The good news is that the
> WebResources refactoring means static file access all goes through the
> same code but the filtering required essentially means we'd need to load
> static files into memory - regardless of size, convert them, and then
> update the cache with the converted version. That is likely to have a
> performance impact.
>
> Because of the performance impacts of handling static resources, the
> runtime approach also needs a way to identify applications that need
> conversion. I don't see a reliable, performant way to do that. Which, I
> think, leaves us with the simple deployment time approach and something
> (filename, special directory, something else) to mark an app as needing
> conversion.
>
> A final point, which probably should have been first, is is there a
> demand for this feature? Early indications from the users list and $work
> is that there is (going to be) a demand for this feature.
>
> Thoughts?
>

Overall it seems more people would like it now, for various reasons.
However, there's zero consensus on how since everyone came up with a
different idea.

I'd like to note the tool is the appropriate solution for most cases, so we
cover that already. The main problem with the tool is the perceived effort
from users.

After reading everything, I'd say it's worth adding a second integrated
option, and think I'm now swaying towards the runtime option. The main
problem would be the detection of legacy webapps. We could simply mandate
using an explicit new attribute on the Context element (and done !) so
nobody pays any needless costs.

Rémy


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

[tomcat-jakartaee-migration] 02/02: Exclude packages from migration that are part of Java SE.

[markt]

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

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

commit 5f47a4f3c731ffd9a7a28defdd16a482b651d4df
Author: Mark Thomas 
AuthorDate: Wed Feb 10 15:11:16 2021 +

Exclude packages from migration that are part of Java SE.
---
 CHANGES.md   | 1 +
 src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java | 2 +-
 src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java | 8 
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/CHANGES.md b/CHANGES.md
index 386e5b8..baeffb2 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -25,6 +25,7 @@
 - Fix [#13](https://github.com/apache/tomcat-jakartaee-migration/issues/13). 
Refactor mapping of log messages to log levels. (markt)
 - Fix [#3](https://github.com/apache/tomcat-jakartaee-migration/issues/3). Add 
support for excluding files from conversion. (markt)
 - Fix handling of classes with more than 32768 entries in the constant pool. 
(markt)
+- Exclude `javax.xml.stream` and `javax.xml.XMLConstants` from the EE profile. 
(markt)
 
 ## 0.1.0
 
diff --git a/src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java 
b/src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java
index 128c1a6..89b4a09 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java
@@ -57,7 +57,7 @@ public enum EESpecProfile {
 "|validation" +
 "|websocket" +
 "|ws[/\\.]rs" +
-"|xml[/\\.](bind|registry|rpc|soap|stream|ws|XMLConstants)))");
+"|xml[/\\.](bind|registry|rpc|soap|ws)))");
 
 private Pattern pattern;
 
diff --git a/src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java 
b/src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java
index ae21b36..351cf6c 100644
--- a/src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java
+++ b/src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java
@@ -58,9 +58,7 @@ public class EESpecProfileTest {
 assertEquals("javax.xml.rpc", profile.convert("javax.xml.rpc"));
 assertEquals("javax.xml.registry", 
profile.convert("javax.xml.registry"));
 assertEquals("javax.xml.soap", profile.convert("javax.xml.soap"));
-assertEquals("javax.xml.stream", profile.convert("javax.xml.stream"));
 assertEquals("javax.xml.ws", profile.convert("javax.xml.ws"));
-assertEquals("javax.xml.XMLConstants", 
profile.convert("javax.xml.XMLConstants"));
 
 // non EE javax packages
 assertEquals("javax.annotation.processing", 
profile.convert("javax.annotation.processing"));
@@ -69,8 +67,10 @@ public class EESpecProfileTest {
 assertEquals("javax.security.auth", 
profile.convert("javax.security.auth"));
 assertEquals("javax.swing", profile.convert("javax.swing"));
 assertEquals("javax.transaction.xa", 
profile.convert("javax.transaction.xa"));
+assertEquals("javax.xml.stream", profile.convert("javax.xml.stream"));
 assertEquals("javax.xml.namespace", 
profile.convert("javax.xml.namespace"));
 assertEquals("javax.xml.xpath.XPathConstants", 
profile.convert("javax.xml.xpath.XPathConstants"));
+assertEquals("javax.xml.XMLConstants", 
profile.convert("javax.xml.XMLConstants"));
 }
 
 @Test
@@ -106,9 +106,7 @@ public class EESpecProfileTest {
 assertEquals("jakarta.xml.registry", 
profile.convert("javax.xml.registry"));
 assertEquals("jakarta.xml.rpc", profile.convert("javax.xml.rpc"));
 assertEquals("jakarta.xml.soap", profile.convert("javax.xml.soap"));
-assertEquals("jakarta.xml.stream", 
profile.convert("javax.xml.stream"));
 assertEquals("jakarta.xml.ws", profile.convert("javax.xml.ws"));
-assertEquals("jakarta.xml.XMLConstants", 
profile.convert("javax.xml.XMLConstants"));
 
 // non EE javax packages
 assertEquals("javax.annotation.processing", 
profile.convert("javax.annotation.processing"));
@@ -117,7 +115,9 @@ public class EESpecProfileTest {
 assertEquals("javax.security.auth", 
profile.convert("javax.security.auth"));
 assertEquals("javax.swing", profile.convert("javax.swing"));
 assertEquals("javax.transaction.xa", 
profile.convert("javax.transaction.xa"));
+assertEquals("javax.xml.stream", profile.convert("javax.xml.stream"));
 assertEquals("javax.xml.namespace", 
profile.convert("javax.xml.namespace"));
 assertEquals("javax.xml.xpath.XPathConstants", 
profile.convert("javax.xml.xpath.XPathConstants"));
+assertEquals("javax.xml.XMLConstants", 
profile.convert("javax.xml.XMLConstants"));
 }
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For add

[tomcat-jakartaee-migration] 01/02: Update changelog

[markt]

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

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

commit 3490a6bb8187d28111f410f7c1e157901b680ce8
Author: Mark Thomas 
AuthorDate: Wed Feb 10 10:00:54 2021 +

Update changelog
---
 CHANGES.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGES.md b/CHANGES.md
index 4c6b15d..386e5b8 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -24,6 +24,7 @@
 - Replace `-verbose` with `-logLevel=` to provide more control over logging 
level. (markt)
 - Fix [#13](https://github.com/apache/tomcat-jakartaee-migration/issues/13). 
Refactor mapping of log messages to log levels. (markt)
 - Fix [#3](https://github.com/apache/tomcat-jakartaee-migration/issues/3). Add 
support for excluding files from conversion. (markt)
+- Fix handling of classes with more than 32768 entries in the constant pool. 
(markt)
 
 ## 0.1.0
 


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

[tomcat-jakartaee-migration] branch master updated (abde81d -> 5f47a4f)

[markt]

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

markt pushed a change to branch master
in repository 
https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git.


from abde81d  Fix bug. Constant pool size is defined as u2
 new 3490a6b  Update changelog
 new 5f47a4f  Exclude packages from migration that are part of Java SE.

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


Summary of changes:
 CHANGES.md   | 2 ++
 src/main/java/org/apache/tomcat/jakartaee/EESpecProfile.java | 2 +-
 src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java | 8 
 3 files changed, 7 insertions(+), 5 deletions(-)


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

Re: Integrating migration tool into Tomcat 10

[Martin Grigorov]

On Wed, Feb 10, 2021 at 12:24 PM Mark Thomas  wrote:

> On 10/02/2021 09:30, Martin Grigorov wrote:
>
> 
>
> > Believe me it is not that simple.
> > Spring Boot Maven/Gradle plugins produce a jar file that contains other
> jar
> > files inside. Those jar files are not compressed for optimization reasons
> > and the Jakarta EE migration tool cannot handle that because
> > java.util.jar.* APIs does not provide a way to not compress, after
> > re-writing the classes/files.
> > So, a Spring Boot application cannot be really migrated to Jakarta EE.
>
> This is no longer correct. Use of the "-zipInMemory" option will address
> this.
>

Good to know!


>
> There are other complications with Spring Boot applications (you need to
> swap out the Tomcat implementation JARs as well) but those should be
> solvable. Whether it is the migration tool's job to solve them is a
> different question.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

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

[Mark Thomas]

On 10/02/2021 09:56, ma...@apache.org 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-jakartaee-migration.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new abde81d  Fix bug. Constant pool size is defined as u2
> abde81d is described below
> 
> commit abde81dfa60b1e390c82e4b30240a59ea1b0596e
> Author: Mark Thomas 
> AuthorDate: Wed Feb 10 09:55:51 2021 +
> 
> Fix bug. Constant pool size is defined as u2
> 
> u2 is an unsigned 2-byte integer but short is a signed 2-byte integer.
> Therefore use int.

FYI, I have finally got around to testing the migration tool with
Atlassian Jira. This is what uncovered the above bug.

I am still seeing a failure when I start Jira under Tomcat 10. I'm
currently investigating the root cause.

Mark

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

Re: Integrating migration tool into Tomcat 10

[Mark Thomas]

On 10/02/2021 09:30, Martin Grigorov wrote:



> Believe me it is not that simple.
> Spring Boot Maven/Gradle plugins produce a jar file that contains other jar
> files inside. Those jar files are not compressed for optimization reasons
> and the Jakarta EE migration tool cannot handle that because
> java.util.jar.* APIs does not provide a way to not compress, after
> re-writing the classes/files.
> So, a Spring Boot application cannot be really migrated to Jakarta EE.

This is no longer correct. Use of the "-zipInMemory" option will address
this.

There are other complications with Spring Boot applications (you need to
swap out the Tomcat implementation JARs as well) but those should be
solvable. Whether it is the migration tool's job to solve them is a
different question.

Mark

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

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

[markt]

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

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


The following commit(s) were added to refs/heads/master by this push:
 new abde81d  Fix bug. Constant pool size is defined as u2
abde81d is described below

commit abde81dfa60b1e390c82e4b30240a59ea1b0596e
Author: Mark Thomas 
AuthorDate: Wed Feb 10 09:55:51 2021 +

Fix bug. Constant pool size is defined as u2

u2 is an unsigned 2-byte integer but short is a signed 2-byte integer.
Therefore use int.
---
 src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java 
b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
index 173ea8e..1b15652 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
@@ -49,7 +49,8 @@ public class ClassConverter implements Converter {
 
 // Loop through constant pool
 Constant[] constantPool = 
javaClass.getConstantPool().getConstantPool();
-for (short i = 0; i < constantPool.length; i++) {
+// Need an int as the maximum pool size is 2^16
+for (int i = 0; i < constantPool.length; i++) {
 if (constantPool[i] instanceof ConstantUtf8) {
 ConstantUtf8 c = (ConstantUtf8) constantPool[i];
 String str = c.getBytes();


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

Re: Integrating migration tool into Tomcat 10

[Martin Grigorov]

Hi Romain,

On Wed, Feb 10, 2021 at 10:39 AM Romain Manni-Bucau 
wrote:

> Le mer. 10 févr. 2021 à 09:32, Martin Grigorov  a
> écrit :
>
> > Hi,
> >
> > On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas  wrote:
> >
> > > Hi all,
> > >
> > > I've been looking at the options to integrate the Java EE to Jakarta EE
> > > migration functionality into Tomcat 10.
> > >
> > > There are essentially two ways to do this: deployment time and runtime.
> > >
> > > The simplest solution to implement is probably a separate
> webapps-legacy
> > > directory (or some other name) where WARs and DIRs added to that
> > > directory get converted to Jakarta EE with the new version being placed
> > > in the webapps directory. There are complexities (such as handling an
> > > updates of the legacy WAR) but they should be manageable.
> > >
> > > A more complex version of the deploy time solution has the legacy web
> > > application placed in webapps, identified as a legacy webapp and then
> > > replaced with the new version (several ways to do this). The hard part
> > > here is the identification of the webapp as a Java EE app. The only
> > > reliable way to do this is class scanning and that is slow.
> > >
> > > The runtime approach converts classes and static resources as they are
> > > loaded. The classes are relatively easy to handle. A
> > > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > > The static files are more of a problem. The good news is that the
> > > WebResources refactoring means static file access all goes through the
> > > same code but the filtering required essentially means we'd need to
> load
> > > static files into memory - regardless of size, convert them, and then
> > > update the cache with the converted version. That is likely to have a
> > > performance impact.
> > >
> > > Because of the performance impacts of handling static resources, the
> > > runtime approach also needs a way to identify applications that need
> > > conversion. I don't see a reliable, performant way to do that. Which, I
> > > think, leaves us with the simple deployment time approach and something
> > > (filename, special directory, something else) to mark an app as needing
> > > conversion.
> > >
> > > A final point, which probably should have been first, is is there a
> > > demand for this feature? Early indications from the users list and
> $work
> > > is that there is (going to be) a demand for this feature.
> > >
> > > Thoughts?
> > >
> >
> > We should also think about Tomcat Embedded! Many of the modern web
> > frameworks use embedded Tomcat/Jetty/Undertow.
> > I guess it should be even easier for them to set a property saying "I
> need
> > this app to be migrated" or to put it in the special folder
> > (webapps-legacy/).
> > We just need to make sure tomcat-embed is taken into account for the
> > eventual solution!
> >
>
> I'm actually not sure:
>
> 1. embed case almost never have a webapps/ folder and always uses flat
> classpath so only option is a javaagent but 2.
>

"almost never" does not mean that it is not possible to do
org.apache.catalina.startup.Tomcat#addContext("someName",
"/path/to/folder/with/static/files/which/need/to/be/migrated")
javaagent alone won't help you for any non-class files


> 2. embed case does not have this standalone status where you put an app in
> another one so if you want to change you change it in your build
>

I don't really understand you here


>
> I can see you speaking of spring-boot or so but this is all solved by maven
> shade plugin or gradle equivalent task so I wouldn't invest in a solution
> which - for this case - wouldnt be used compared to the standalone case
> which still has ops vs dev coverage and need IMHO.
>

Believe me it is not that simple.
Spring Boot Maven/Gradle plugins produce a jar file that contains other jar
files inside. Those jar files are not compressed for optimization reasons
and the Jakarta EE migration tool cannot handle that because
java.util.jar.* APIs does not provide a way to not compress, after
re-writing the classes/files.
So, a Spring Boot application cannot be really migrated to Jakarta EE.


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

Re: Integrating migration tool into Tomcat 10

[Romain Manni-Bucau]

Le mer. 10 févr. 2021 à 09:32, Martin Grigorov  a
écrit :

> Hi,
>
> On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas  wrote:
>
> > Hi all,
> >
> > I've been looking at the options to integrate the Java EE to Jakarta EE
> > migration functionality into Tomcat 10.
> >
> > There are essentially two ways to do this: deployment time and runtime.
> >
> > The simplest solution to implement is probably a separate webapps-legacy
> > directory (or some other name) where WARs and DIRs added to that
> > directory get converted to Jakarta EE with the new version being placed
> > in the webapps directory. There are complexities (such as handling an
> > updates of the legacy WAR) but they should be manageable.
> >
> > A more complex version of the deploy time solution has the legacy web
> > application placed in webapps, identified as a legacy webapp and then
> > replaced with the new version (several ways to do this). The hard part
> > here is the identification of the webapp as a Java EE app. The only
> > reliable way to do this is class scanning and that is slow.
> >
> > The runtime approach converts classes and static resources as they are
> > loaded. The classes are relatively easy to handle. A
> > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > The static files are more of a problem. The good news is that the
> > WebResources refactoring means static file access all goes through the
> > same code but the filtering required essentially means we'd need to load
> > static files into memory - regardless of size, convert them, and then
> > update the cache with the converted version. That is likely to have a
> > performance impact.
> >
> > Because of the performance impacts of handling static resources, the
> > runtime approach also needs a way to identify applications that need
> > conversion. I don't see a reliable, performant way to do that. Which, I
> > think, leaves us with the simple deployment time approach and something
> > (filename, special directory, something else) to mark an app as needing
> > conversion.
> >
> > A final point, which probably should have been first, is is there a
> > demand for this feature? Early indications from the users list and $work
> > is that there is (going to be) a demand for this feature.
> >
> > Thoughts?
> >
>
> We should also think about Tomcat Embedded! Many of the modern web
> frameworks use embedded Tomcat/Jetty/Undertow.
> I guess it should be even easier for them to set a property saying "I need
> this app to be migrated" or to put it in the special folder
> (webapps-legacy/).
> We just need to make sure tomcat-embed is taken into account for the
> eventual solution!
>

I'm actually not sure:

1. embed case almost never have a webapps/ folder and always uses flat
classpath so only option is a javaagent but 2.
2. embed case does not have this standalone status where you put an app in
another one so if you want to change you change it in your build

I can see you speaking of spring-boot or so but this is all solved by maven
shade plugin or gradle equivalent task so I wouldn't invest in a solution
which - for this case - wouldnt be used compared to the standalone case
which still has ops vs dev coverage and need IMHO.


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

Re: Integrating migration tool into Tomcat 10

[Martin Grigorov]

Hi,

On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas  wrote:

> Hi all,
>
> I've been looking at the options to integrate the Java EE to Jakarta EE
> migration functionality into Tomcat 10.
>
> There are essentially two ways to do this: deployment time and runtime.
>
> The simplest solution to implement is probably a separate webapps-legacy
> directory (or some other name) where WARs and DIRs added to that
> directory get converted to Jakarta EE with the new version being placed
> in the webapps directory. There are complexities (such as handling an
> updates of the legacy WAR) but they should be manageable.
>
> A more complex version of the deploy time solution has the legacy web
> application placed in webapps, identified as a legacy webapp and then
> replaced with the new version (several ways to do this). The hard part
> here is the identification of the webapp as a Java EE app. The only
> reliable way to do this is class scanning and that is slow.
>
> The runtime approach converts classes and static resources as they are
> loaded. The classes are relatively easy to handle. A
> ClassFileTransformer can be added to the WebappClassLoader to do this.
> The static files are more of a problem. The good news is that the
> WebResources refactoring means static file access all goes through the
> same code but the filtering required essentially means we'd need to load
> static files into memory - regardless of size, convert them, and then
> update the cache with the converted version. That is likely to have a
> performance impact.
>
> Because of the performance impacts of handling static resources, the
> runtime approach also needs a way to identify applications that need
> conversion. I don't see a reliable, performant way to do that. Which, I
> think, leaves us with the simple deployment time approach and something
> (filename, special directory, something else) to mark an app as needing
> conversion.
>
> A final point, which probably should have been first, is is there a
> demand for this feature? Early indications from the users list and $work
> is that there is (going to be) a demand for this feature.
>
> Thoughts?
>

We should also think about Tomcat Embedded! Many of the modern web
frameworks use embedded Tomcat/Jetty/Undertow.
I guess it should be even easier for them to set a property saying "I need
this app to be migrated" or to put it in the special folder
(webapps-legacy/).
We just need to make sure tomcat-embed is taken into account for the
eventual solution!

Martin


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

Re: Integrating migration tool into Tomcat 10

[Romain Manni-Bucau]

Hi,

I'd go simple:

1. Add in the tool jar a ClassFileTransformer
2. Make this transformer configurable (packages using "startsWith" which is
fast and optimizable - maybe something like
https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/openwebbeans/KnownClassesFilter.java#L218
)
3. Add a transformer webresource - like in maven shade plugin - which is
about to transform a resource from a pattern (prefix/suffix cases being
optimized in terms of matching) and replacement

With these 3 new configurable classes tomcat stays pure and fast for all
cases but enables the migration on the fly when needed.
Can even be a tomcat-jakarta-migration-helper.jar totally independent of
tomcat - while it is released on central from time to time ;).

All mecanism requiring another webapp or a reload are promises of failures
IMHO since often webapps are dropped or undesired except the app webapps in
real or dev deployments.

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



Le mer. 10 févr. 2021 à 01:46, Emmanuel Bourg  a écrit :

> Le 2021-02-09 22:12, Mark Thomas a écrit :
>
> > Thoughts?
>
> I think this feature is really desirable. For the Debian packaging this
> would mean a faster transition to Tomcat 10.
>
> There are two issues:
> 1. How to identify a legacy application?
> 2. How to convert the application once identified?
>
> For the identification, either:
> a. separate the Java EE and Jakarta EE webapps in different directories.
> It's simple but it's an additional decision point for the user and there
> will be mistakes.
> b. keep the webapps in the same directory and scan the content. This
> degrades the performances for those having switched to Jakarta EE, so
> this should be optional, and probably disabled by default.
> c. keep the webapps in the same directory, load them as usual and
> trigger the conversion mechanism only if a class loading error related
> to the javax namespace occurs.
>
> Regarding the conversion, we can:
> a. Convert at runtime with class loading tricks, which is quite elegant
> but the price is paid every time the application is started.
> b. Convert at deployment time before loading the application, this means
> more file juggling but only the first start is impacted.
>
> The convenience of the automatic migration comes obviously at a price
> but I think it's important we ensure it doesn't impact those ready to
> jump to the new Jakarta EE world. For this reason I'm leaning toward the
> solution 1c + 2b (convert on errors, and convert the webapp before
> reloading).
>
> The start sequence would look like this:
> 1. foo.war is copied to the webapps directory by the user
> 2. The foo application is loaded
> 3. A NoClassDefFoundError regarding the javax.servlet.Servlet class is
> thrown, the migration mechanism is triggered
> 4. The migration tool is executed on foo.war. The original file is
> renamed foo.war.legacy and the migrated file remains as foo.war
> 5. The application is reloaded
>
> And on subsequent starts, the migrated application is loaded directly,
> with no performance impact.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>