Re: [VOTE] Apache TomEE 8.0.8

2021-09-06 Thread Wiesner, Martin
Hi all,

+1 (non-binding)

Tested in several projects (primarily web services, JAXB, REST…),
both on Linux & Mac OS, each under AdoptOpenJDK 11 (latest).

Best
Martin
—
https://twitter.com/mawiesne

Am 06.09.2021 um 10:27 schrieb Jean-Louis Monteiro 
mailto:jlmonte...@tomitribe.com>>:

+1 (binding)
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Thu, Sep 2, 2021 at 5:31 PM Alex The Rocker  wrote:

Alright so my vote is [+1] non-binding for TomEE 8.0.8 based on my
tests (I doubt the fix for activemq exception can be in time for
8.0.8, let's keep this one for 8.0.9...)

Alex

Le jeu. 2 sept. 2021 à 17:23, Jean-Louis Monteiro
 a écrit :

The change has been introduced in Java version 16+

See https://openjdk.java.net/jeps/396
and https://bugs.openjdk.java.net/browse/JDK-8256358

JEP 396: Strongly Encapsulate JDK Internals by Default (JDK-8256299
) core-libs

Strongly encapsulate all internal elements of the JDK by default,
except
for critical internal APIs <
https://openjdk.java.net/jeps/260#Description>
such as sun.misc.Unsafe. Allow end users to choose the relaxed strong
encapsulation that has been the default since JDK 9.

With this change, the default value of the launcher option
--illegal-access
 is
now
deny rather than permit. As a consequence, existing code that uses most
internal classes, methods, or fields of the JDK will fail to run. Such
code
can be made to run on JDK 16 by specifying --illegal-access=permit.
That
option will, however, be removed in a future release.

For further details, please see JEP 396
.


You need to add --illegal-access=permit to your surefire configuration or
add it to your JVM options.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Thu, Sep 2, 2021 at 2:57 PM Alex The Rocker 
wrote:

Hello again,

Of course my vote related to TomEE 8.0.8 experiments with Java 16 is
not blocking the release since it's not a binding vote.
I continued my tests and I found no regression with TomEE+ 8.0.8 with
IBM Semeru Runtime 11.0.12 (new name for AdoptOpenJDK OpenJ9) with a
app which relies on JAX-WS / JAX-RS / JMS & Websockets.

With Java 16 runtime, I have this annoying exception in catalina.out
when I use the embedded ActiveMQ for JMS purposes:

02-Sep-2021 12:50:33.955 SEVERE [ActiveMQ Task-1]
org.apache.activemq.util.IntrospectionSupport.setProperty Could not
set property host on Socket[unconnected]
java.lang.reflect.InaccessibleObjectException: Unable to make public
void sun.security.ssl.SSLSocketImpl.setHost(java.lang.String)
accessible: module java.base does not "export
sun.security.ssl" to unnamed module @8960bcc0
at

java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
at

java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at

java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at

org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:179)
at

org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:155)
at

org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:140)
at

org.apache.activemq.transport.tcp.SslTransport.(SslTransport.java:81)
at

org.apache.activemq.transport.tcp.SslTransportFactory.createTransport(SslTransportFactory.java:122)
at

org.apache.activemq.transport.TransportFactory.doCompositeConnect(TransportFactory.java:138)
at

org.apache.activemq.transport.TransportFactory.compositeConnect(TransportFactory.java:91)
at

org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1013)
at

org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:149)
at

org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at

org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at

java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at

java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:883)

It's not blocking the JMS requests from executing.

Bbut accumulating exceptions in logs is not something we appreciate,
since we have alerters on exceptions rates in production, so I hope
that issue (which is not new with TomEE+ 8.0.8, same issue with 8.0.6)
will soon be fixed, again having in mind that Java 17 LTS availability
is getting close...

Hope it helps,
Alex

Le jeu. 2 sept. 2021 à 09:57, Thomas Andraschko
 a écrit :

+1 (non-binding)

I think we should work on java17 after that release

Alex The Rocker  schrieb am Do., 2. Sept.
2021,
09:52:

Hello,

[-1] (non 

Re: [VOTE] Apache TomEE 8.0.8

2021-09-06 Thread Jean-Louis Monteiro
+1 (binding)
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Thu, Sep 2, 2021 at 5:31 PM Alex The Rocker  wrote:

> Alright so my vote is [+1] non-binding for TomEE 8.0.8 based on my
> tests (I doubt the fix for activemq exception can be in time for
> 8.0.8, let's keep this one for 8.0.9...)
>
> Alex
>
> Le jeu. 2 sept. 2021 à 17:23, Jean-Louis Monteiro
>  a écrit :
> >
> > The change has been introduced in Java version 16+
> >
> > See https://openjdk.java.net/jeps/396
> > and https://bugs.openjdk.java.net/browse/JDK-8256358
> >
> > JEP 396: Strongly Encapsulate JDK Internals by Default (JDK-8256299
> > > ) core-libs
> > >
> > > Strongly encapsulate all internal elements of the JDK by default,
> except
> > > for critical internal APIs <
> https://openjdk.java.net/jeps/260#Description>
> > > such as sun.misc.Unsafe. Allow end users to choose the relaxed strong
> > > encapsulation that has been the default since JDK 9.
> > >
> > > With this change, the default value of the launcher option
> > > --illegal-access
> > >  is
> now
> > > deny rather than permit. As a consequence, existing code that uses most
> > > internal classes, methods, or fields of the JDK will fail to run. Such
> code
> > > can be made to run on JDK 16 by specifying --illegal-access=permit.
> That
> > > option will, however, be removed in a future release.
> > >
> > > For further details, please see JEP 396
> > > .
> > >
> >
> > You need to add --illegal-access=permit to your surefire configuration or
> > add it to your JVM options.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, Sep 2, 2021 at 2:57 PM Alex The Rocker 
> wrote:
> >
> > > Hello again,
> > >
> > > Of course my vote related to TomEE 8.0.8 experiments with Java 16 is
> > > not blocking the release since it's not a binding vote.
> > > I continued my tests and I found no regression with TomEE+ 8.0.8 with
> > > IBM Semeru Runtime 11.0.12 (new name for AdoptOpenJDK OpenJ9) with a
> > > app which relies on JAX-WS / JAX-RS / JMS & Websockets.
> > >
> > > With Java 16 runtime, I have this annoying exception in catalina.out
> > > when I use the embedded ActiveMQ for JMS purposes:
> > >
> > > 02-Sep-2021 12:50:33.955 SEVERE [ActiveMQ Task-1]
> > > org.apache.activemq.util.IntrospectionSupport.setProperty Could not
> > > set property host on Socket[unconnected]
> > > java.lang.reflect.InaccessibleObjectException: Unable to make public
> > > void sun.security.ssl.SSLSocketImpl.setHost(java.lang.String)
> > > accessible: module java.base does not "export
> > >  sun.security.ssl" to unnamed module @8960bcc0
> > >  at
> > >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> > >  at
> > >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> > >  at
> > >
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> > >  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> > >  at
> > >
> org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:179)
> > >  at
> > >
> org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:155)
> > >  at
> > >
> org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:140)
> > >  at
> > >
> org.apache.activemq.transport.tcp.SslTransport.(SslTransport.java:81)
> > >  at
> > >
> org.apache.activemq.transport.tcp.SslTransportFactory.createTransport(SslTransportFactory.java:122)
> > >  at
> > >
> org.apache.activemq.transport.TransportFactory.doCompositeConnect(TransportFactory.java:138)
> > >  at
> > >
> org.apache.activemq.transport.TransportFactory.compositeConnect(TransportFactory.java:91)
> > >  at
> > >
> org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1013)
> > >  at
> > >
> org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:149)
> > >  at
> > >
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
> > >  at
> > >
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
> > >  at
> > >
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> > >  at
> > >
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> > >  at java.base/java.lang.Thread.run(Thread.java:883)
> > >
> > > It's not blocking the JMS requests from executing.
> > >
> > > Bbut accumulating exceptions in logs is not something we appreciate,
> > > since we have alerters on exceptions rates in production, so I hope
> > > that issue (which is not new with TomEE+ 8.0.8, same issue with 8.0.6)
> > > will soon be fixed, again