Re: CDI support improvements

2019-06-11 Thread Romain Manni-Bucau 
Hell Rémy,

I commented inline

Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :

> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
> wrote:
>
>> My 2cts would be that we have the luck to be fully ASF here so each
>> project can likely get back its missing piece(s) and we stay overall
>> consistent instead of creating yet another fork in our beloved foundation
>> (we already have some concurrent servers or even jdbc pools which does not
>> help much user land).
>>
>> @Rémy do you track the issues you encounter somewhere?
>> For instance "CXF is not user friendly" but once you have CDI you get CXF
>> set up just adding a servlet. Here, an initializer would have been friendly
>> but then you would encounter the servlet initializer ordering issue.
>>
>
> Ok :)
>
> So:
> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really
> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
> that good).
>

Depends, if you use maven it is fine  ;).

Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
jakarta jars) you just need:

org.apache.cxf:cxf-core:3.3.2
org.apache.cxf:cxf-rt-security:3.3.2
org.apache.cxf:cxf-rt-transports-http:3.3.2
org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
org.apache.cxf:cxf-integration-cdi:3.3.2
org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
Microprofile you need it)


> - (Ok I figured it out) Looking at the integration(s), I quickly notice
> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
> cxf-rt-transports-http (did I miss any ?). They all need that I define a
> Servlet it seems (no idea why at least some of these don't do it for me).
>

There are two main concepts: the integration (cdi, spring, blueprint, )
and the transport (http, jms, ...). Http transport goes through the servlet
and the integration relies on the transport to forward the messages
(request) to the CXF server which does the link with the beans.


> - After getting somewhere and trying a mp health test with your Geronimo
> Health CDI bundle, I got:
> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
> and
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
> are equal candidates for handling the current request which can lead to
> unpredictable results
> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
> at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
> at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
> at
> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
> with modifiers "private"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
> at
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
> ... 47 more
>
> That's where I am right now. The way to use CXF with Tomcat should be more
> obvious.
>

Geronimo Health has a common and a cdi modules (cdi one being not suffixed
in terms of naming). Both are exactly the same except cdi one uses CDI
beans for the wiring and common is reusable in an OSGi container.
Common is not intended to be scanned.
I will add a scan=none in the jar since it is not done today and leads to
that issue if not excluded from the scanned jar - can be done through
openwebbeans.properties.

-> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give
another try with a snapshot


>
> OWB did not have most of these issues, the amount of libraries is
> manageable and the integration was labelled as "tomcat7". The main issue
> with OWB is that integration had issues [it needed some adjustments in
> Tomcat to avoid instance manager replacement timing issues; other more
> cosmetic problems were the use of both Catalina internal components and
>

buildbot success in on tomcat-7-trunk

2019-06-11 Thread buildbot 
The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1358

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] 503424d4a89c1fefaf3e45ffac797c1afb854dcf
Blamelist: remm 

Build succeeded!

Sincerely,
 -The Buildbot




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

[tomcat] branch 7.0.x updated: Fix typos

2019-06-11 Thread violetagg 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 2056124  Fix typos
2056124 is described below

commit 20561244ae9660113522cd410ed1aae4afb4ad5f
Author: Violeta Georgieva 
AuthorDate: Tue Jun 11 18:46:22 2019 -0400

Fix typos
---
 webapps/docs/changelog.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 13d00c9..9a12f57 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -66,7 +66,7 @@
 file. Identified by Coverity scan. (markt)
   
   
-Fix a potential concurrency issue in the StringCache identifed by
+Fix a potential concurrency issue in the StringCache identified by
 Coverity scan. (markt)
   
   
@@ -184,7 +184,7 @@
   
 Use the test command to check for terminal availability
 rather than the tty command since the tty
-based test fails on non-Eglish locales. (markt)
+based test fails on non-English locales. (markt)
   
 
   


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

[tomcat] branch 7.0.x updated: Add EL varargs improvements to changelog

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 2fe48a5  Add EL varargs improvements to changelog
2fe48a5 is described below

commit 2fe48a5d7011ef91e55eb7d42fee3d944c808d57
Author: Mark Thomas 
AuthorDate: Tue Jun 11 23:42:27 2019 +0100

Add EL varargs improvements to changelog
---
 webapps/docs/changelog.xml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d78736b..13d00c9 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -133,6 +133,9 @@
 Include file names in error messages if SMAP processor is unable to
 delete or rename a class file during SMAP generation. (markt)
   
+  
+Improvements to varargs handling in the Java UEL implementation. 
(markt)
+  
 
   
   


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

Re: [tomcat] branch 7.0.x updated: Fix exception type

2019-06-11 Thread Mark Thomas 
On 11/06/2019 23:13, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch 7.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/7.0.x by this push:
>  new 503424d  Fix exception type
> 503424d is described below
> 
> commit 503424d4a89c1fefaf3e45ffac797c1afb854dcf
> Author: remm 
> AuthorDate: Wed Jun 12 00:13:19 2019 +0200
> 
> Fix exception type

Thanks for fixing this.

Mark


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

[tomcat] branch 8.5.x updated: Fix typos

2019-06-11 Thread violetagg 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 4e33b38  Fix typos
4e33b38 is described below

commit 4e33b38a36a9a47c15e1d56a9d2d28bbd3b99d38
Author: Violeta Georgieva 
AuthorDate: Tue Jun 11 18:35:11 2019 -0400

Fix typos
---
 webapps/docs/changelog.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index dd8d395..31a2821 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -160,7 +160,7 @@
   
 Use the test command to check for terminal availability
 rather than the tty command since the tty
-based test fails on non-Eglish locales. (markt)
+based test fails on non-English locales. (markt)
   
 
   
@@ -173,7 +173,7 @@
 file. Identified by Coverity scan. (markt)
   
   
-Fix a potential concurrency issue in the StringCache identifed by
+Fix a potential concurrency issue in the StringCache identified by
 Coverity scan. (markt)
   
   


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

[tomcat] branch master updated: Fix typos

2019-06-11 Thread violetagg 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/master by this push:
 new ca524fa  Fix typos
ca524fa is described below

commit ca524faa0e44d435aff357e9632dcab88bd7dd5b
Author: Violeta Georgieva 
AuthorDate: Tue Jun 11 18:23:37 2019 -0400

Fix typos
---
 webapps/docs/changelog.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 7027b16..eecddf8 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -281,7 +281,7 @@
   
 Use the test command to check for terminal availability
 rather than the tty command since the tty
-based test fails on non-Eglish locales. (markt)
+based test fails on non-English locales. (markt)
   
 
   
@@ -299,7 +299,7 @@
 file. Identified by Coverity scan. (markt)
   
   
-Fix a potential concurrency issue in the StringCache identifed by
+Fix a potential concurrency issue in the StringCache identified by
 Coverity scan. (markt)
   
   
@@ -339,7 +339,7 @@
   
   
 63361: Add a new method
-(Registry.disableRegistry()) that can be used to disbale
+(Registry.disableRegistry()) that can be used to disable
 JMX registration of Tomcat components providing it is called before the
 first component is registered. (markt)
   


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

[tomcat] branch 7.0.x updated: Fix exception type

2019-06-11 Thread remm 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 503424d  Fix exception type
503424d is described below

commit 503424d4a89c1fefaf3e45ffac797c1afb854dcf
Author: remm 
AuthorDate: Wed Jun 12 00:13:19 2019 +0200

Fix exception type
---
 test/javax/el/TestBeanELResolver.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/javax/el/TestBeanELResolver.java 
b/test/javax/el/TestBeanELResolver.java
index 31b4c5b..825d7c3 100644
--- a/test/javax/el/TestBeanELResolver.java
+++ b/test/javax/el/TestBeanELResolver.java
@@ -266,7 +266,7 @@ public class TestBeanELResolver {
  * Tests that an exception will be thrown when the property does not have
  * setter method.
  */
-@Test(expected = PropertyNotFoundException.class)
+@Test(expected = PropertyNotWritableException.class)
 public void testSetValue07() {
 BeanELResolver resolver = new BeanELResolver();
 ELContext context = new ELContextImpl();


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

buildbot failure in on tomcat-7-trunk

2019-06-11 Thread buildbot 
The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1357

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] be23a22490f8fd7b1c677703f80cc406722689f4
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

Re: CDI support improvements

2019-06-11 Thread Rémy Maucherat 
On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
wrote:

> My 2cts would be that we have the luck to be fully ASF here so each
> project can likely get back its missing piece(s) and we stay overall
> consistent instead of creating yet another fork in our beloved foundation
> (we already have some concurrent servers or even jdbc pools which does not
> help much user land).
>
> @Rémy do you track the issues you encounter somewhere?
> For instance "CXF is not user friendly" but once you have CDI you get CXF
> set up just adding a servlet. Here, an initializer would have been friendly
> but then you would encounter the servlet initializer ordering issue.
>

Ok :)

So:
- When downloading CXF, I'm facing a myriad of JARs, and I cannot really
figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
that good).
- (Ok I figured it out) Looking at the integration(s), I quickly notice
there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
cxf-rt-transports-http (did I miss any ?). They all need that I define a
Servlet it seems (no idea why at least some of these don't do it for me).
- After getting somewhere and trying a mp health test with your Geronimo
Health CDI bundle, I got:
11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
and
org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
are equal candidates for handling the current request which can lead to
unpredictable results
11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
at
org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
at
org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
at
org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
at
org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
at
org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
at org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
...
Caused by: java.lang.IllegalAccessException: Class
org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
with modifiers "private"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
at
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
at java.lang.reflect.Method.invoke(Method.java:491)
at
org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
... 47 more

That's where I am right now. The way to use CXF with Tomcat should be more
obvious.

OWB did not have most of these issues, the amount of libraries is
manageable and the integration was labelled as "tomcat7". The main issue
with OWB is that integration had issues [it needed some adjustments in
Tomcat to avoid instance manager replacement timing issues; other more
cosmetic problems were the use of both Catalina internal components and
Servlet level components, an integration should try to choose one or the
other unless there's a showstopper which forces both], so I tried to
modernize and improve it.


>
> In other words I wonder if we can't cumulate our efforts instead of
> working isolated and moreover if we can avoid to split the code and
> deliverables more than necessary - sounds like overlapping will be very
> high without more details.
>

I understand but CXF has too many constraints like the need to support many
many different kind of deployments and uses, so I'm not really blaming
anyone here.


> Do we have a functional showcase app already? Can help building one if
> needed.
> Do you have an idea of where you want to land (in terms of config +
> deliverables)?
>

Yes, ok. So for OWB as an example, here's what I have:
- Use Tomcat 9.0.21.
- Add  to the  element in server.xml. If OWB is not
present, the missing dependency of the listener will be logged as INFO
(without causing further problems). The context listener can also be
configured in conf/context.xml and it would apply to all webapps, but I
prefer avoiding this if possible (it's more hidden).
- Add the JAR from tomcat-owb to the lib folder, then this should CDI
enable all webapps. One thing I'm not sure about yet is the separate
javax.* JARs, so let's ignore that "detail" for now ...
- The integration can also be used at the individual webapp level (as
before) using context.xml.
- It only uses Catalina components.
Doe

Re: CDI support improvements

2019-06-11 Thread David Blevins 
> On Jun 11, 2019, at 12:02 PM, Mark Thomas  wrote:
> 
> On 11/06/2019 19:37, David Blevins wrote:
>> 
>> At a high level, is there a desire to start supporting more "EE" like specs 
>> such as CDI, JAX-RS, JPA, etc?
> 
> Make it easier to integrate? Sure.
> 
> Implement additional specs? No.

That's been my understanding as well.


> On Jun 11, 2019, at 12:21 PM, Rémy Maucherat  wrote:
> 
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS) 
> is the building block of many other APIs (like the Microprofile), so there's 
> a need to be able to use it in a "clean and light [and] in Tomcat spirit" way 
> (as you said). I had a look at OWB and CXF and while the support is there, it 
> needs some work (especially for the latter) and is certainly not user 
> friendly (again, esp for the latter). Note that the work is also in Tomcat 
> itself, since I'm in a good position to make changes and improvements as 
> needed.
> 
> As for the answer, it would still be "no" at this point, since at most these 
> could be considered as a couple extra optional modules like the jdbc pool, or 
> maybe "build them yourself" poms.

If CDI integration code were to live here, I'd probably want to see us rebase 
TomEE on top of it.  That would probably mean occasional CDI-related PRs, 
documentation, dev threads, user questions, etc.  It's a bit of a can of worms 
even if it's an add-on, which is why I ask the above.

In the event people here prefer not to open that can of worms of supporting 
Tomcat+CDI integration code, it and you would be more than welcome in TomEE.  
We could have a "Tomcat+CDI" dist of TomEE that used just the new code.  As 
noted above, we'd probably rebase the other TomEE dists on that one.  It's been 
8 years and I definitely have appetite for a fresh perspective (just like you, 
speaking for myself only not all of TomEE).

I'm a fan wherever it lives.  My concern would be if it happens here and isn't 
actually welcome.  I would feel very awkward sending people over to help 
maintain it.


-David


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

[Bug 63492] close_time No recovery

2019-06-11 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63492

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas  ---
Bugzilla is not a support forum.

This is a topic for the users mailing list. It has also been discussed several
times previously. Those discussions are in the archives.

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

[tomcat] branch master updated: Fix Javadoc typo

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/master by this push:
 new bcdc744  Fix Javadoc typo
bcdc744 is described below

commit bcdc744b08e93e73ba9daea25ec1a9889a9d67e1
Author: Mark Thomas 
AuthorDate: Tue Jun 11 21:49:07 2019 +0100

Fix Javadoc typo
---
 java/javax/el/ELContext.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/javax/el/ELContext.java b/java/javax/el/ELContext.java
index f294192..46f0564 100644
--- a/java/javax/el/ELContext.java
+++ b/java/javax/el/ELContext.java
@@ -48,7 +48,7 @@ public abstract class ELContext {
 }
 
 /**
- * Mark the given property as resolved and notfy any interested listeners.
+ * Mark the given property as resolved and notify any interested listeners.
  *
  * @param base The base object on which the property was found
  * @param property The property that was resolved


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

[tomcat] branch 7.0.x updated: Align EL implementation with 8.5.x where possible. Cosmetic changes only

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new be23a22  Align EL implementation with 8.5.x where possible. Cosmetic 
changes only
be23a22 is described below

commit be23a22490f8fd7b1c677703f80cc406722689f4
Author: Mark Thomas 
AuthorDate: Tue Jun 11 21:52:16 2019 +0100

Align EL implementation with 8.5.x where possible. Cosmetic changes only

Changes include:
- re-order methods to reduce diff
- re-order catch blocks to reduce diff
- document unchecked exceptions in Javadoc rather than method signature
- Use varargs for i18n for cleaner code
- remove unnecessary (...)
- make more use of Util.handleThrowable
- whitespace changes
---
 java/javax/el/ArrayELResolver.java  |  43 +++
 java/javax/el/BeanELResolver.java   |  44 ++-
 java/javax/el/CompositeELResolver.java  | 118 -
 java/javax/el/ELContext.java|  63 +-
 java/javax/el/ELException.java  |  16 +--
 java/javax/el/ELResolver.java   |  70 +++
 java/javax/el/Expression.java   |   4 +-
 java/javax/el/ExpressionFactory.java| 160 +++-
 java/javax/el/FunctionMapper.java   |   5 -
 java/javax/el/ListELResolver.java   |  28 ++---
 java/javax/el/LocalStrings.properties   |  14 ++-
 java/javax/el/LocalStrings_es.properties|  10 +-
 java/javax/el/MapELResolver.java|  20 ++-
 java/javax/el/MethodExpression.java |   8 +-
 java/javax/el/MethodInfo.java   |  14 +--
 java/javax/el/MethodNotFoundException.java  |  25 +---
 java/javax/el/PropertyNotFoundException.java|  24 +---
 java/javax/el/PropertyNotWritableException.java |  25 +---
 java/javax/el/ResourceBundleELResolver.java |  18 +--
 java/javax/el/ValueExpression.java  |  40 +++---
 20 files changed, 303 insertions(+), 446 deletions(-)

diff --git a/java/javax/el/ArrayELResolver.java 
b/java/javax/el/ArrayELResolver.java
index 4204fe4..fa46260 100644
--- a/java/javax/el/ArrayELResolver.java
+++ b/java/javax/el/ArrayELResolver.java
@@ -34,40 +34,38 @@ public class ArrayELResolver extends ELResolver {
 }
 
 @Override
-public Object getValue(ELContext context, Object base, Object property)
-throws NullPointerException, PropertyNotFoundException, 
ELException {
+public Class getType(ELContext context, Object base, Object property) {
 if (context == null) {
 throw new NullPointerException();
 }
 
 if (base != null && base.getClass().isArray()) {
 context.setPropertyResolved(true);
-int idx = coerce(property);
-if (idx < 0 || idx >= Array.getLength(base)) {
-return null;
+try {
+int idx = coerce(property);
+checkBounds(base, idx);
+} catch (IllegalArgumentException e) {
+// ignore
 }
-return Array.get(base, idx);
+return base.getClass().getComponentType();
 }
 
 return null;
 }
 
 @Override
-public Class getType(ELContext context, Object base, Object property)
-throws NullPointerException, PropertyNotFoundException, 
ELException {
+public Object getValue(ELContext context, Object base, Object property) {
 if (context == null) {
 throw new NullPointerException();
 }
 
 if (base != null && base.getClass().isArray()) {
 context.setPropertyResolved(true);
-try {
-int idx = coerce(property);
-checkBounds(base, idx);
-} catch (IllegalArgumentException e) {
-// ignore
+int idx = coerce(property);
+if (idx < 0 || idx >= Array.getLength(base)) {
+return null;
 }
-return base.getClass().getComponentType();
+return Array.get(base, idx);
 }
 
 return null;
@@ -75,9 +73,7 @@ public class ArrayELResolver extends ELResolver {
 
 @Override
 public void setValue(ELContext context, Object base, Object property,
-Object value) throws NullPointerException,
-PropertyNotFoundException, PropertyNotWritableException,
-ELException {
+Object value) {
 if (context == null) {
 throw new NullPointerException();
 }
@@ -87,8 +83,7 @@ public class ArrayELResolver extends ELResolver {
 
 if (this.readOnly) {
 throw new PropertyNotWritableException(Util.message(context,
-"resolverNotWriteable", new Object[] { base.getClass()
-

[tomcat] branch 8.5.x updated: Fix Javadoc typo

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new bdcfd02  Fix Javadoc typo
bdcfd02 is described below

commit bdcfd025dc964eaccf274c5f9276d6a53b1ffdcb
Author: Mark Thomas 
AuthorDate: Tue Jun 11 21:49:23 2019 +0100

Fix Javadoc typo
---
 java/javax/el/ELContext.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/javax/el/ELContext.java b/java/javax/el/ELContext.java
index f294192..46f0564 100644
--- a/java/javax/el/ELContext.java
+++ b/java/javax/el/ELContext.java
@@ -48,7 +48,7 @@ public abstract class ELContext {
 }
 
 /**
- * Mark the given property as resolved and notfy any interested listeners.
+ * Mark the given property as resolved and notify any interested listeners.
  *
  * @param base The base object on which the property was found
  * @param property The property that was resolved


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

[tomcat] branch 8.5.x updated: Align EL impl with 9.0.x. i18n improvements and minor code clean-up

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 2e62f51  Align EL impl with 9.0.x. i18n improvements and minor code 
clean-up
2e62f51 is described below

commit 2e62f51ca7d511c88eacd5cccf11ea25398bf3ac
Author: Mark Thomas 
AuthorDate: Tue Jun 11 20:59:00 2019 +0100

Align EL impl with 9.0.x. i18n improvements and minor code clean-up
---
 java/javax/el/ArrayELResolver.java   |  2 +-
 java/javax/el/ExpressionFactory.java | 21 +++--
 java/javax/el/ListELResolver.java|  2 +-
 java/javax/el/LocalStrings.properties|  4 
 java/javax/el/LocalStrings_es.properties |  7 +++
 java/javax/el/StaticFieldELResolver.java | 10 +-
 6 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/java/javax/el/ArrayELResolver.java 
b/java/javax/el/ArrayELResolver.java
index 5bbb2a1..d500e85 100644
--- a/java/javax/el/ArrayELResolver.java
+++ b/java/javax/el/ArrayELResolver.java
@@ -138,7 +138,7 @@ public class ArrayELResolver extends ELResolver {
 return ((Character) property).charValue();
 }
 if (property instanceof Boolean) {
-return (((Boolean) property).booleanValue() ? 1 : 0);
+return ((Boolean) property).booleanValue() ? 1 : 0;
 }
 if (property instanceof String) {
 return Integer.parseInt((String) property);
diff --git a/java/javax/el/ExpressionFactory.java 
b/java/javax/el/ExpressionFactory.java
index 58c80b6..cc80a9e 100644
--- a/java/javax/el/ExpressionFactory.java
+++ b/java/javax/el/ExpressionFactory.java
@@ -151,9 +151,7 @@ public abstract class ExpressionFactory {
 writeLock.unlock();
 }
 } catch (ClassNotFoundException e) {
-throw new ELException(
-"Unable to find ExpressionFactory of type: " + className,
-e);
+throw new ELException(Util.message(null, 
"expressionFactory.cannotFind", className), e);
 }
 }
 
@@ -177,17 +175,13 @@ public abstract class ExpressionFactory {
 (ExpressionFactory) constructor.newInstance(properties);
 }
 
-} catch (InstantiationException | IllegalAccessException | 
IllegalArgumentException |
-NoSuchMethodException e) {
-throw new ELException(
-"Unable to create ExpressionFactory of type: " + 
clazz.getName(),
-e);
 } catch (InvocationTargetException e) {
 Throwable cause = e.getCause();
 Util.handleThrowable(cause);
-throw new ELException(
-"Unable to create ExpressionFactory of type: " + 
clazz.getName(),
-e);
+throw new ELException(Util.message(null, 
"expressionFactory.cannotCreate", clazz.getName()), e);
+} catch (InstantiationException | IllegalAccessException | 
IllegalArgumentException |
+NoSuchMethodException e) {
+throw new ELException(Util.message(null, 
"expressionFactory.cannotCreate", clazz.getName()), e);
 }
 
 return result;
@@ -400,8 +394,7 @@ public abstract class ExpressionFactory {
 // Should never happen with UTF-8
 // If it does - ignore & return null
 } catch (IOException e) {
-throw new ELException("Failed to read " + 
SERVICE_RESOURCE_NAME,
-e);
+throw new ELException(Util.message(null, 
"expressionFactory.readFailed", SERVICE_RESOURCE_NAME), e);
 } finally {
 try {
 is.close();
@@ -425,7 +418,7 @@ public abstract class ExpressionFactory {
 } catch (FileNotFoundException e) {
 // Should not happen - ignore it if it does
 } catch (IOException e) {
-throw new ELException("Failed to read " + PROPERTY_FILE, e);
+throw new ELException(Util.message(null, 
"expressionFactory.readFailed", PROPERTY_FILE), e);
 }
 }
 return null;
diff --git a/java/javax/el/ListELResolver.java 
b/java/javax/el/ListELResolver.java
index 749fdae..cd88620 100644
--- a/java/javax/el/ListELResolver.java
+++ b/java/javax/el/ListELResolver.java
@@ -144,7 +144,7 @@ public class ListELResolver extends ELResolver {
 return ((Character) property).charValue();
 }
 if (property instanceof Boolean) {
-return (((Boolean) property).booleanValue() ? 1 : 0);
+return ((Boolean) property).booleanValue() ? 1 : 0;
 }
 if (property instanceof String) {
 return Integer.parseInt((String) property);
diff --git a/java/javax/el/LocalStrings.properties 
b/java/javax/el/LocalSt

Re: CDI support improvements

2019-06-11 Thread Romain Manni-Bucau 
My 2cts would be that we have the luck to be fully ASF here so each project
can likely get back its missing piece(s) and we stay overall consistent
instead of creating yet another fork in our beloved foundation (we already
have some concurrent servers or even jdbc pools which does not help much
user land).

@Rémy do you track the issues you encounter somewhere?
For instance "CXF is not user friendly" but once you have CDI you get CXF
set up just adding a servlet. Here, an initializer would have been friendly
but then you would encounter the servlet initializer ordering issue.

In other words I wonder if we can't cumulate our efforts instead of working
isolated and moreover if we can avoid to split the code and deliverables
more than necessary - sounds like overlapping will be very high without
more details.

Do we have a functional showcase app already? Can help building one if
needed.
Do you have an idea of where you want to land (in terms of config +
deliverables)?

Answering both can be a way to move forward and see how we can converge.
To complete David's answer, I kind of see that even without integrating
some EE things in Tomcat itself, it can benefit to TomEE and enable it to
align even more on Tomcat in terms of user facing configuration for
instance.

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



Le mar. 11 juin 2019 à 21:22, Rémy Maucherat  a écrit :

> Hi David,
>
> On Tue, Jun 11, 2019 at 8:37 PM David Blevins 
> wrote:
>
>> Hi All,
>>
>> At a high level, is there a desire to start supporting more "EE" like
>> specs such as CDI, JAX-RS, JPA, etc?
>>
>> Completely understood if the answer is "depends."  I suspect it would
>> depend on if the code is clean and light in Tomcat spirit.
>>
>
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
> JAX-RS) is the building block of many other APIs (like the Microprofile),
> so there's a need to be able to use it in a "clean and light [and] in
> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
> support is there, it needs some work (especially for the latter) and is
> certainly not user friendly (again, esp for the latter). Note that the work
> is also in Tomcat itself, since I'm in a good position to make changes and
> improvements as needed.
>
> As for the answer, it would still be "no" at this point, since at most
> these could be considered as a couple extra optional modules like the jdbc
> pool, or maybe "build them yourself" poms.
>
>
>>
>> I write this not from the perspective of "let's move a bunch of TomEE
>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>> and retire equivalent TomEE code."
>>
>> That's not a specific proposal, just curious if appetite has developed in
>> recent years to entertain tip-toeing beyond the same set of specs.
>>
>
> Rémy
>
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> >
>> >
>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit
>> :
>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>> >
>> > Once done it can be hosted on both side.Owb has the advantage to be
>> know by users, tomcat to be a more natural home for an integration. At the
>> end it is mainly synchronizing both projects for a consistent communication
>> and code "move" IMHO.
>> >
>> > For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>> >
>> > Ok, I think things look reasonably good using CDI extensions (looking
>> at the Geronimo mp implementation you did) except the default CXF "servlet"
>> integration. I think right now the "servlet" integration from the
>> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
>> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
>> derives from cxf-integration-cdi).
>> >
>> > So this looks a lot closer to Meecrowave than I originally expected,
>> with a lot of "buts" though:
>> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
>> here is a "Meecrowave for Tomcat"
>> >
>> > Guess this one can converge - at least for TomEE it did and we have a
>> tons of flavors, I dont see a blocker to unify it here to.
>> >
>> > - The JAR has all of Tomcat, log4j, API JA

Re: CDI support improvements

2019-06-11 Thread Rémy Maucherat 
Hi David,

On Tue, Jun 11, 2019 at 8:37 PM David Blevins 
wrote:

> Hi All,
>
> At a high level, is there a desire to start supporting more "EE" like
> specs such as CDI, JAX-RS, JPA, etc?
>
> Completely understood if the answer is "depends."  I suspect it would
> depend on if the code is clean and light in Tomcat spirit.
>

Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS)
is the building block of many other APIs (like the Microprofile), so
there's a need to be able to use it in a "clean and light [and] in Tomcat
spirit" way (as you said). I had a look at OWB and CXF and while the
support is there, it needs some work (especially for the latter) and is
certainly not user friendly (again, esp for the latter). Note that the work
is also in Tomcat itself, since I'm in a good position to make changes and
improvements as needed.

As for the answer, it would still be "no" at this point, since at most
these could be considered as a couple extra optional modules like the jdbc
pool, or maybe "build them yourself" poms.


>
> I write this not from the perspective of "let's move a bunch of TomEE code
> into Tomcat", but more of "let's write cleaner newer code in Tomcat and
> retire equivalent TomEE code."
>
> That's not a specific proposal, just curious if appetite has developed in
> recent years to entertain tip-toeing beyond the same set of specs.
>

Rémy

>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau 
> wrote:
> >
> >
> >
> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :
> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
> >
> > Once done it can be hosted on both side.Owb has the advantage to be know
> by users, tomcat to be a more natural home for an integration. At the end
> it is mainly synchronizing both projects for a consistent communication and
> code "move" IMHO.
> >
> > For deep tomcat/cxf integration, you can use
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
> module. Technically it uses an embedded flavor but it would be easy to move
> to a standalone one through a listener based on a small refactoring in
> Meecrowave#start. The good part are the lifecycle and scanning integrations
> + the tooling to make testing and dev simple -
> http://openwebbeans.apache.org/meecrowave/.
> >
> > Ok, I think things look reasonably good using CDI extensions (looking at
> the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
> >
> > So this looks a lot closer to Meecrowave than I originally expected,
> with a lot of "buts" though:
> > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal
> here is a "Meecrowave for Tomcat"
> >
> > Guess this one can converge - at least for TomEE it did and we have a
> tons of flavors, I dont see a blocker to unify it here to.
> >
> > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here
> be based off Tomcat, the javax APIs and OWB already present in the Tomcat
> OWB implementation JAR (the classic "tomcat7" or the modernized
> "tomcat-owb")
> >
> > The jar is just one flavor of meecrowave - assuming you reference the
> fatjar, you should still be able to use it as plain unitary dependencies.
> > The missing part here is to extract from Meecrowave master class all the
> logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I
> guess and ignoring the specific launcher config?)
> >
> > - log4j would need to be removed as well
> >
> > It is already supported, in this IT we drop log4j, johnzon, cxf:
> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
> >
> > - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
> >
> > Yep, but all are also settable from a listener or a centralized file, we
> are really free here.
> >
> >
> >
> >
> > More technically: openwebbeans does not need properties files you can
> pass Properties when you create the WebBeansContext, this is what tomee
> does. Same for cxf and its bus ;).
> >
> > Ok, I'll have a look at that, it's better than properties files (but
> similar).
> >
> > Biggest short term challenge is to align scanners but it is very doable,
> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
> >
> > Ok.
> >
> > Feel free to shout if you need help or more precise pointers.
> >
> > Rémy
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: CDI support improvements

2019-06-11 Thread Mark Thomas 
On 11/06/2019 19:37, David Blevins wrote:
> Hi All,
> 
> At a high level, is there a desire to start supporting more "EE" like specs 
> such as CDI, JAX-RS, JPA, etc?
> 
> Completely understood if the answer is "depends."  I suspect it would depend 
> on if the code is clean and light in Tomcat spirit.
> 
> I write this not from the perspective of "let's move a bunch of TomEE code 
> into Tomcat", but more of "let's write cleaner newer code in Tomcat and 
> retire equivalent TomEE code."
> 
> That's not a specific proposal, just curious if appetite has developed in 
> recent years to entertain tip-toeing beyond the same set of specs.

Make it easier to integrate? Sure.

Implement additional specs? No.

Mark

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

Re: CDI support improvements

2019-06-11 Thread David Blevins 
Hi All,

At a high level, is there a desire to start supporting more "EE" like specs 
such as CDI, JAX-RS, JPA, etc?

Completely understood if the answer is "depends."  I suspect it would depend on 
if the code is clean and light in Tomcat spirit.

I write this not from the perspective of "let's move a bunch of TomEE code into 
Tomcat", but more of "let's write cleaner newer code in Tomcat and retire 
equivalent TomEE code."

That's not a specific proposal, just curious if appetite has developed in 
recent years to entertain tip-toeing beyond the same set of specs.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau  wrote:
> 
> 
> 
> Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :
> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau  
> wrote:
>  
> Once done it can be hosted on both side.Owb has the advantage to be know by 
> users, tomcat to be a more natural home for an integration. At the end it is 
> mainly synchronizing both projects for a consistent communication and code 
> "move" IMHO.
> 
> For deep tomcat/cxf integration, you can use 
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core module. 
> Technically it uses an embedded flavor but it would be easy to move to a 
> standalone one through a listener based on a small refactoring in 
> Meecrowave#start. The good part are the lifecycle and scanning integrations + 
> the tooling to make testing and dev simple - 
> http://openwebbeans.apache.org/meecrowave/.
> 
> Ok, I think things look reasonably good using CDI extensions (looking at the 
> Geronimo mp implementation you did) except the default CXF "servlet" 
> integration. I think right now the "servlet" integration from the 
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave (in 
> org.apache.meecrowave.cxf) is more likely to be the way to go (it derives 
> from cxf-integration-cdi).
> 
> So this looks a lot closer to Meecrowave than I originally expected, with a 
> lot of "buts" though:
> - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here is 
> a "Meecrowave for Tomcat"
> 
> Guess this one can converge - at least for TomEE it did and we have a tons of 
> flavors, I dont see a blocker to unify it here to.
>  
> - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be 
> based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB 
> implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
> 
> The jar is just one flavor of meecrowave - assuming you reference the fatjar, 
> you should still be able to use it as plain unitary dependencies.
> The missing part here is to extract from Meecrowave master class all the 
> logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I 
> guess and ignoring the specific launcher config?)
>  
> - log4j would need to be removed as well
> 
> It is already supported, in this IT we drop log4j, johnzon, cxf: 
> https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32
>  
> - plenty of configuration files and options in the JARs, but I guess that's 
> the way it is since all the subcomponents are so flexible
> 
> Yep, but all are also settable from a listener or a centralized file, we are 
> really free here.
>  
>  
> 
> 
> More technically: openwebbeans does not need properties files you can pass 
> Properties when you create the WebBeansContext, this is what tomee does. Same 
> for cxf and its bus ;).
> 
> Ok, I'll have a look at that, it's better than properties files (but similar).
> 
> Biggest short term challenge is to align scanners but it is very doable, long 
> term it is to drop big core jars in all 3 libs for smaller bundles ;).
> 
> Ok.
> 
> Feel free to shout if you need help or more precise pointers.
> 
> Rémy
> 


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

[tomcat] branch 7.0.x updated: Changes missed in previous commit

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 34b36ed  Changes missed in previous commit
34b36ed is described below

commit 34b36ed0912898a0879692e5d89cd1902b2e90e2
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:52:35 2019 +0100

Changes missed in previous commit
---
 java/javax/el/Util.java | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index 172c83c..cfe0c06 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -40,6 +40,7 @@ import java.util.concurrent.locks.ReentrantReadWriteLock;
 
 class Util {
 
+private static final Class[] EMPTY_CLASS_ARRAY = new Class[0];
 private static final Object[] EMPTY_OBJECT_ARRAY = new Object[0];
 
 /**
@@ -217,9 +218,6 @@ class Util {
 
 Wrapper result = findWrapper(clazz, wrappers, methodName, paramTypes, 
paramValues);
 
-if (result == null) {
-return null;
-}
 return getMethod(clazz, (Method) result.unWrap());
 }
 
@@ -233,12 +231,7 @@ class Util {
 
 Map candidates = new 
HashMap();
 
-int paramCount;
-if (paramTypes == null) {
-paramCount = 0;
-} else {
-paramCount = paramTypes.length;
-}
+int paramCount = paramTypes.length;
 
 for (Wrapper w : wrappers) {
 Class[] mParamTypes = w.getParameterTypes();
@@ -529,7 +522,7 @@ class Util {
 
 private static Class[] getTypesFromValues(Object[] values) {
 if (values == null) {
-return null;
+return EMPTY_CLASS_ARRAY;
 }
 
 Class result[] = new Class[values.length];
@@ -588,7 +581,7 @@ class Util {
 
 if (clazz == null) {
 throw new MethodNotFoundException(
-message(null, "util.method.notfound", clazz, methodName,
+message(null, "util.method.notfound", null, methodName,
 paramString(paramTypes)));
 }
 
@@ -602,9 +595,6 @@ class Util {
 
 Wrapper result = findWrapper(clazz, wrappers, methodName, paramTypes, 
paramValues);
 
-if (result == null) {
-return null;
-}
 return getConstructor(clazz, (Constructor) result.unWrap());
 }
 


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

[tomcat] 03/04: Implement equals() and hashCode() because compareTo() is implemented

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit f695782a15c1bd672a7b3d79bccca31da468fcdf
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:29:03 2019 +0100

Implement equals() and hashCode() because compareTo() is implemented
---
 java/javax/el/Util.java | 20 
 1 file changed, 20 insertions(+)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index e7e20d2..af428ab 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -802,6 +802,26 @@ class Util {
 }
 }
 }
+
+@Override
+public boolean equals(Object o)
+{
+return o == this || (null != o &&
+this.getClass().equals(o.getClass()) &&
+((MatchResult)o).getExact() == this.getExact() &&
+((MatchResult)o).getAssignable() == this.getAssignable() &&
+((MatchResult)o).getCoercible() == this.getCoercible() &&
+((MatchResult)o).isBridge() == this.isBridge());
+}
+
+@Override
+public int hashCode()
+{
+return (this.isBridge() ? 1 << 24 : 0) ^
+this.getExact() << 16 ^
+this.getAssignable() << 8 ^
+this.getCoercible();
+}
 }
 
 


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

[tomcat] 04/04: Back-port varargs handling improvements to 7.0.x

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit d208fa862d68c11b6b12e22d582367c73f7b0df8
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:49:48 2019 +0100

Back-port varargs handling improvements to 7.0.x
---
 java/javax/el/Util.java   |  59 -
 test/javax/el/TestBeanELResolver.java | 481 ++
 test/javax/el/TesterBean.java |   9 +
 3 files changed, 535 insertions(+), 14 deletions(-)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index af428ab..172c83c 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -40,6 +40,8 @@ import java.util.concurrent.locks.ReentrantReadWriteLock;
 
 class Util {
 
+private static final Object[] EMPTY_OBJECT_ARRAY = new Object[0];
+
 /**
  * Checks whether the supplied Throwable is one that needs to be
  * rethrown and swallows all others.
@@ -248,11 +250,29 @@ class Util {
 }
 
 // Check the number of parameters
-if (!(paramCount == mParamCount ||
-(w.isVarArgs() && paramCount >= mParamCount))) {
+// Multiple tests to improve readability
+if (!w.isVarArgs() && paramCount != mParamCount) {
 // Method has wrong number of parameters
 continue;
 }
+if (w.isVarArgs() && paramCount < mParamCount -1) {
+// Method has wrong number of parameters
+continue;
+}
+if (w.isVarArgs() && paramCount == mParamCount && paramValues != 
null &&
+paramValues.length > paramCount && !paramTypes[mParamCount 
-1].isArray()) {
+// Method arguments don't match
+continue;
+}
+if (w.isVarArgs() && paramCount > mParamCount && paramValues != 
null &&
+paramValues.length != paramCount) {
+// Might match a different varargs method
+continue;
+}
+if (!w.isVarArgs() && paramValues != null && paramCount != 
paramValues.length) {
+// Might match a different varargs method
+continue;
+}
 
 // Check the parameters match
 int exactMatch = 0;
@@ -261,9 +281,12 @@ class Util {
 boolean noMatch = false;
 for (int i = 0; i < mParamCount; i++) {
 // Can't be null
-if (mParamTypes[i].equals(paramTypes[i])) {
-exactMatch++;
-} else if (i == (mParamCount - 1) && w.isVarArgs()) {
+if (w.isVarArgs() && i == (mParamCount - 1)) {
+if (i == paramCount || (paramValues != null && 
paramValues.length == i)) {
+// Nothing is passed as varargs
+assignableMatch++;
+break;
+}
 Class varType = mParamTypes[i].getComponentType();
 for (int j = i; j < paramCount; j++) {
 if (isAssignableFrom(paramTypes[j], varType)) {
@@ -285,18 +308,22 @@ class Util {
 // lead to a varArgs method matching when the result
 // should be ambiguous
 }
-} else if (isAssignableFrom(paramTypes[i], mParamTypes[i])) {
-assignableMatch++;
 } else {
-if (paramValues == null) {
-noMatch = true;
-break;
+if (mParamTypes[i].equals(paramTypes[i])) {
+exactMatch++;
+} else if (paramTypes[i] != null && 
isAssignableFrom(paramTypes[i], mParamTypes[i])) {
+assignableMatch++;
 } else {
-if (isCoercibleFrom(paramValues[i], mParamTypes[i])) {
-coercibleMatch++;
-} else {
+if (paramValues == null) {
 noMatch = true;
 break;
+} else {
+if (isCoercibleFrom(paramValues[i], 
mParamTypes[i])) {
+coercibleMatch++;
+} else {
+noMatch = true;
+break;
+}
 }
 }
 }
@@ -609,7 +636,11 @@ class Util {
 Object[] parameters = null;
 if (parameterTypes.length > 0) {
 parameters = new Object[parameterTypes.length];
-int paramCount = params.length;
+int paramCount;
+if (params == null) {
+params = EMPTY_OB

[tomcat] 01/04: ws alignment with 8.5.x

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit 133437383764b429c302d5ba250c86f26d257314
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:26:26 2019 +0100

ws alignment with 8.5.x
---
 java/javax/el/Util.java | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index 5da8c67..cc5a631 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -76,8 +76,7 @@ class Util {
 }
 return template;
 } catch (MissingResourceException e) {
-return "Missing Resource: '" + name + "' for Locale "
-+ locale.getDisplayName();
+return "Missing Resource: '" + name + "' for Locale " + 
locale.getDisplayName();
 }
 }
 
@@ -214,8 +213,7 @@ class Util {
 
 List wrappers = Wrapper.wrap(methods, methodName);
 
-Wrapper result = findWrapper(
-clazz, wrappers, methodName, paramTypes, paramValues);
+Wrapper result = findWrapper(clazz, wrappers, methodName, paramTypes, 
paramValues);
 
 if (result == null) {
 return null;
@@ -575,8 +573,7 @@ class Util {
 
 List wrappers = Wrapper.wrap(constructors);
 
-Wrapper result = findWrapper(
-clazz, wrappers, methodName, paramTypes, paramValues);
+Wrapper result = findWrapper(clazz, wrappers, methodName, paramTypes, 
paramValues);
 
 if (result == null) {
 return null;


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

[tomcat] 02/04: lock() should be outside try {...}

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit 51cbfd346a98bd426307a7f0fa93c0a9371eac60
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:27:01 2019 +0100

lock() should be outside try {...}
---
 java/javax/el/Util.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index cc5a631..e7e20d2 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -120,8 +120,8 @@ class Util {
 
 if (factory == null) {
 final Lock writeLock = cacheValue.getLock().writeLock();
+writeLock.lock();
 try {
-writeLock.lock();
 factory = cacheValue.getExpressionFactory();
 if (factory == null) {
 factory = ExpressionFactory.newInstance();


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

[tomcat] branch 7.0.x updated (d6b5385 -> d208fa8)

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


from d6b5385  Better error messages for SMAP generation
 new 1334373  ws alignment with 8.5.x
 new 51cbfd3  lock() should be outside try {...}
 new f695782  Implement equals() and hashCode() because compareTo() is 
implemented
 new d208fa8  Back-port varargs handling improvements to 7.0.x

The 4 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:
 java/javax/el/Util.java   |  90 +--
 test/javax/el/TestBeanELResolver.java | 481 ++
 test/javax/el/TesterBean.java |   9 +
 3 files changed, 559 insertions(+), 21 deletions(-)


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

[tomcat] branch 8.5.x updated: Implement equals() and hashCode() because compareTo() is implemented

2019-06-11 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 0c598b1  Implement equals() and hashCode() because compareTo() is 
implemented
0c598b1 is described below

commit 0c598b1d04c147c9976e734a7d2fcaf74db48593
Author: Mark Thomas 
AuthorDate: Tue Jun 11 18:23:26 2019 +0100

Implement equals() and hashCode() because compareTo() is implemented
---
 java/javax/el/Util.java | 20 
 1 file changed, 20 insertions(+)

diff --git a/java/javax/el/Util.java b/java/javax/el/Util.java
index 1dfd0a8..0ec663c 100644
--- a/java/javax/el/Util.java
+++ b/java/javax/el/Util.java
@@ -809,6 +809,26 @@ class Util {
 }
 return cmp;
 }
+
+@Override
+public boolean equals(Object o)
+{
+return o == this || (null != o &&
+this.getClass().equals(o.getClass()) &&
+((MatchResult)o).getExact() == this.getExact() &&
+((MatchResult)o).getAssignable() == this.getAssignable() &&
+((MatchResult)o).getCoercible() == this.getCoercible() &&
+((MatchResult)o).isBridge() == this.isBridge());
+}
+
+@Override
+public int hashCode()
+{
+return (this.isBridge() ? 1 << 24 : 0) ^
+this.getExact() << 16 ^
+this.getAssignable() << 8 ^
+this.getCoercible();
+}
 }
 
 


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

[ANN] Apache Tomcat 8.5.42 available

2019-06-11 Thread Mark Thomas 
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.42.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.41 include:

- Fix various concurrency and stability issues for HTTP/2.

- Add support for same-site cookie attribute. Patch provided by John
  Kelly.

- Add an option to sort directory listings provided by the Default
  Servlet.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat 9.0.21 available

2019-06-11 Thread Mark Thomas 
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.21.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.21 is a bugfix and feature release. The notable
changes compared to 9.0.20 include:

- Fix various concurrency and stability issues for HTTP/2.

- Add support for same-site cookie attribute. Patch provided by John
  Kelly.

- Add an option to sort directory listings provided by the Default
  Servlet.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: CDI support improvements

2019-06-11 Thread Romain Manni-Bucau 
Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :

> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau 
> wrote:
>
>
>> Once done it can be hosted on both side.Owb has the advantage to be know
>> by users, tomcat to be a more natural home for an integration. At the end
>> it is mainly synchronizing both projects for a consistent communication and
>> code "move" IMHO.
>>
>> For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>>
>
> Ok, I think things look reasonably good using CDI extensions (looking at
> the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
>
> So this looks a lot closer to Meecrowave than I originally expected, with
> a lot of "buts" though:
> - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here
> is a "Meecrowave for Tomcat"
>

Guess this one can converge - at least for TomEE it did and we have a tons
of flavors, I dont see a blocker to unify it here to.


> - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be
> based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB
> implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
>

The jar is just one flavor of meecrowave - assuming you reference the
fatjar, you should still be able to use it as plain unitary dependencies.
The missing part here is to extract from Meecrowave master class all the
logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I
guess and ignoring the specific launcher config?)


> - log4j would need to be removed as well
>

It is already supported, in this IT we drop log4j, johnzon, cxf:
https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32


> - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
>

Yep, but all are also settable from a listener or a centralized file, we
are really free here.


>
>
>>
>>
 More technically: openwebbeans does not need properties files you can
 pass Properties when you create the WebBeansContext, this is what tomee
 does. Same for cxf and its bus ;).

>>>
>>> Ok, I'll have a look at that, it's better than properties files (but
>>> similar).
>>>
>>
 Biggest short term challenge is to align scanners but it is very
 doable, long term it is to drop big core jars in all 3 libs for smaller
 bundles ;).

>>>
>>> Ok.
>>>

 Feel free to shout if you need help or more precise pointers.

>>>
> Rémy
>
>

Re: CDI support improvements

2019-06-11 Thread Rémy Maucherat 
On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau 
wrote:


> Once done it can be hosted on both side.Owb has the advantage to be know
> by users, tomcat to be a more natural home for an integration. At the end
> it is mainly synchronizing both projects for a consistent communication and
> code "move" IMHO.
>
> For deep tomcat/cxf integration, you can use
> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
> module. Technically it uses an embedded flavor but it would be easy to move
> to a standalone one through a listener based on a small refactoring in
> Meecrowave#start. The good part are the lifecycle and scanning integrations
> + the tooling to make testing and dev simple -
> http://openwebbeans.apache.org/meecrowave/.
>

Ok, I think things look reasonably good using CDI extensions (looking at
the Geronimo mp implementation you did) except the default CXF "servlet"
integration. I think right now the "servlet" integration from the
cxf-rt-transports-http package is "bad" and that the one from Meecrowave
(in org.apache.meecrowave.cxf) is more likely to be the way to go (it
derives from cxf-integration-cdi).

So this looks a lot closer to Meecrowave than I originally expected, with a
lot of "buts" though:
- Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here
is a "Meecrowave for Tomcat"
- The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be
based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB
implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
- log4j would need to be removed as well
- plenty of configuration files and options in the JARs, but I guess that's
the way it is since all the subcomponents are so flexible


>
>
>>> More technically: openwebbeans does not need properties files you can
>>> pass Properties when you create the WebBeansContext, this is what tomee
>>> does. Same for cxf and its bus ;).
>>>
>>
>> Ok, I'll have a look at that, it's better than properties files (but
>> similar).
>>
>
>>> Biggest short term challenge is to align scanners but it is very doable,
>>> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
>>>
>>
>> Ok.
>>
>>>
>>> Feel free to shout if you need help or more precise pointers.
>>>
>>
Rémy