Re: TomEE 9.x relies on Tomcat 10.0.27 but this one is quite old ...

[Jonathan Gallimore]

I will check on the state of these CVEs with respect to the backports, and
reply on this thread.

One comment I'll make though, is that NexusIQ (I also use it) will
potentially still identify the jars as Tomcat 10.0.27, and therefore may
still identify them as vulnerable (incorrectly), despite a patch being
applied.

While I understand the frustration that may cause both yourself and your
customers, please understand that both Tomcat and TomEE are community
projects, and everyone contributing is doing so as a volunteer.

Richard has already outlined why we can't move to Tomcat 10.1.x on TomEE
9.x. TomEE 10.x is in progress. Any contributions you wanted to make would
be most welcome.

Jon

On Mon, Nov 13, 2023 at 1:29 PM COURTAULT Francois
 wrote:

> THALES GROUP LIMITED DISTRIBUTION to email recipients
>
> Hello Richard,
>
> I performed a vulnerabilities scan using NexusIQ, the result are:
> - CVE-2022-45143 (CVSS 3 scoring 7.5) on  tomcat-catalina : 10.0.27
> - CVE-2023-24998 (CVSS 3 scoring 7.5) on tomcat-coyote : 10.0.27
>
> Some of our customers won't accept that ☹
>
> BTW I also scan Tomcat 10.1.15 with the same tool and I don't have anymore
> such CVSS 3 score.
> So will you start TomEE 10.x at some point ?
>
> Best Regards.
>
> -Original Message-
> From: Richard Zowalla 
> Sent: lundi 13 novembre 2023 12:53
> To: users@tomee.apache.org
> Subject: Re: TomEE 9.x relies on Tomcat 10.0.27 but this one is quite old
> ...
>
> Hi,
>
> the TomEE 10.0.27 contained in TomEE 9.1.x is patched inside the TomEE
> build to fix the latest CVEs. We did not backport bug fixes, though.
>
> As TomEE 9 targets EE9(.1), we cannot upgrade to Tomcat 10.1.x, which is
> EE10. So from a spec perspective, there is currently no plan to migrate
> TomEE 9.x to Tomcat 10.1.x (without breaking the tck).
>
> Gruß
> Richard
>
>
> Am Montag, dem 13.11.2023 um 11:30 + schrieb COURTAULT Francois:
> > THALES GROUP LIMITED DISTRIBUTION to email recipients
> >
> > Hello everyone,
> >
> > According to this link
> > https://tomcat.apache.org/tomcat-10.0-eol.html  Tomcat 10.0.x is EOL,
> > right?
> > But TomEE 9.1.1 still rely on Tomcat 10.0.x.
> >
> > Any plan to migrate TomEE 9.x to Tomcat 10.1.x ?
> >
> > Best Regards.
> >
> >
> >
>

Re: Tomee forum users is closed?

[Jonathan Gallimore]

Hi

Its definitely not closed, and this message arrived fine - are you using a
link to Nabble from the website or similar?

Thanks

Jon

On Wed, Sep 15, 2021 at 6:11 PM Mauro Chi  wrote:

> Hi guys.
> Is from some time that the tomee forum users is not reachable.
> I ask : is closed ?
>

Re: Tomee 8.0.6 start fails

[Jonathan Gallimore]

What's the JNDI lookup you're doing here?

eu.debooy.doosutils.service.ServiceLocator.listContext(ServiceLocator.java:149)
at
eu.debooy.doosutils.service.ServiceLocator.lookup(ServiceLocator.java:184)
at
eu.debooy.doosutils.service.JNDI$JNDINaam.(JNDI.java:57) at
eu.debooy.doos.component.quartz.QuartzListener.getProperties(QuartzListener.java:108)
at
eu.debooy.doos.component.quartz.QuartzListener.contextInitialized(QuartzListener.java:80)

Is that looking up something on another server?

Its making a HTTP call, and it looks like that is potentially running into
a network / firewall issue from what I can see.

Jon



On Thu, Jul 15, 2021 at 10:01 PM Marco DE BOOIJ 
wrote:

> Hi Jon,
>
> Thanks for your help. Took some time to investigate. I did what you
> proposed and I found the application that blocks the start. If I remove
> this application (or make the expanded directory in the webapps
> directory unaccessible for Tomee) than Tomee starts without a problem.
>
> The problem is that none of my other applications will work without this
> application. It looks that Quartz is involved or is this just
> coincidence. The strange thing is that I have another Tomee instance
> with the same version and the exact same application (I copied over the
> war file to be 100% sure). Only the distribution (latest Debian) is
> different. Here I can restart Tomee without a problem. When I deploy
> this application on the empty Tomee the it runs well.
>
> *The catalina.2021-07-15.log content from start to freeze*:
>
> 15-Jul-2021 22:14:38.816 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Server version
> name:   Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Server
> built:  Dec 3 2020 11:43:00 UTC
> 15-Jul-2021 22:14:38.816 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Server version
> name:   Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Server
> built:  Dec 3 2020 11:43:00 UTC
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Server version
> number: 9.0.41.0
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke OS
> Name:   Linux
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke OS
> Version:5.4.0-77-generic
> 15-Jul-2021 22:14:38.817 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> Architecture:  amd64
> 15-Jul-2021 22:14:38.818 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Java
> Home: /usr/lib/jvm/java-11-openjdk-amd64
> 15-Jul-2021 22:14:38.818 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke JVM
> Version:   11.0.11+9-Ubuntu-0ubuntu2.20.04
> 15-Jul-2021 22:14:38.818 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke JVM
> Vendor:Ubuntu
> 15-Jul-2021 22:14:38.818 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> CATALINA_BASE: /srv/local/tomee
> 15-Jul-2021 22:14:38.818 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> CATALINA_HOME: /srv/local/opt/apache-tomee-plus-8.0.6
> 15-Jul-2021 22:14:38.837 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line
> argument: --add-opens=java.base/java.lang=ALL-UNNAMED
> 15-Jul-2021 22:14:38.837 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line
> argument: --add-opens=java.base/java.io=ALL-UNNAMED
> 15-Jul-2021 22:14:38.837 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line
> argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> 15-Jul-2021 22:14:38.837 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line
> argument:
> -Djava.util.logging.config.file=/srv/local/tomee/conf/logging.properties
> 15-Jul-2021 22:14:38.840 INFO [main]
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line
> argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> 15-Jul-2021 22:14:38.840 INFO [main]
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line
> argument: -javaagent:/srv/local/opt/tomee/lib/openejb-javaagent.jar
> 15-Jul-2021 22:14:38.840 INFO [main]
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line
> argument: -Djava.awt.headless=true
> 15-Jul-2021 22:14:38.840 INFO [main]
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line
> argument: -Djava.security.egd=file:/dev/./urandom
> 15-Jul-2021 22:14:38.840 INFO [main]
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line
> argument: -XX:+DisableExplicitGC
> 15-Jul-2021 22:14:38.841 INFO [main]
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line
> argument: 

Re: Tomee 8.0.6 start fails

[Jonathan Gallimore]

Hi Marco

I'd suggest getting a thread dump of the TomEE process that is stuck.
Assuming you're running on Linux, you can get the PID with:

ps -ef | grep Bootstrap

and then get the thread dump with:

jstack 

The thread dump will contain the classnames and methods for the call stack
for every thread in the JVM, so you may want to remove anything you deem to
be sensitive, but hopefully the thread dump itself will give you some clues
as to what is going on, or you can attach it here and we'll take a look.

Jon

On Sun, Jul 11, 2021 at 9:24 PM Marco DE BOOIJ 
wrote:

> Dears,
>
> I have a strange behaviour. When I install Tomee (8.0.6) it starts and
> restarts without a problem. When I install applications, it works. The
> applications are reachable. So far so good.
>
> When I restart Tomee deploys the applications but then it stops after
> the message "INFO [main] org.apache.openejb.client.EventLogger.log
> RemoteInitialContextCreated{providerUri=http://127.0.0.1:8080/tomee/ejb};.
>
> I know that this question does not have much detail but perhaps you can
> guide me to where I need to look to resolve this problem? I have another
> instance of Tomee (same version) that does not have this problem. It
> looks like the config files are the same.
>
> Regards,
>
> Marco
>
>

Re: IIOP tunelling over HTTP

[Jonathan Gallimore]

Hi Francois

It is tested and working on TomEE 8.0.6; I did specifically test it using
this example:
https://github.com/apache/tomee/tree/master/examples/ejb-remote-call-2
before replying. Do let us know if you run into issues and we'll be happy
to help you out.

Jon

On Tue, Mar 23, 2021 at 5:39 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> Thanks for answering :-)
> I found this link http://tomee.apache.org/latest/docs/ejbd-transport.html
> but it seems rot really recent (reference to 1.7.x).
> Is this link quite similar with your answer ?
>
> We are using currently TomEE 8.0.6. Does it fully work and fully tested on
> this release .
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mardi 23 mars 2021 17:29
> To: users@tomee.apache.org
> Subject: Re: IIOP tunelling over HTTP
>
> Hi
>
> TomEE does have the ability to do remote EJB calls over HTTP, although it
> isn't based on IIOP. This capability has actually been around in OpenEJB in
> the pre-TomEE days :-).
>
> In TomEE, you'll need to enable remote support, and configure a list of
> packages that are allowed to be serialized/deserialized.
>
> tomee.remote.support = true
> tomee.serialization.class.blacklist = *
> tomee.serialization.class.whitelist = org.mycompany.package
>
> After that, you can lookup and call remote EJBs in the usual way. The
> global JNDI names of your EJBs should be logged out at deploy time.
>
> Properties properties = new Properties();
> properties.put(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.RemoteInitialContextFactory");
> properties.put(Context.PROVIDER_URL, "
> http://localhost:8080/tomee/ejb;);
>
> Context ctx = new InitialContext(properties);
> Object ref =
>
> ctx.lookup("global/ejb-remote-call-2/Greetings!org.superbiz.remote.Greetings");
>
>
> This should also work with a reverse proxy such as HTTPD in front of TomEE.
> You may wish to turn on authentication so anonymous users can't call your
> business methods.
>
> I've always quite liked this functionality as it enables remote EJB access
> in a fairly straightforward way, without needing to open up other ports.
>
> Hope that helps.
>
> Jon
>
> On Tue, Mar 23, 2021 at 4:00 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello everyone,
> >
> > Previously we were using Welogic. In one of our use-case, we performed
> > a remote EJB (so using iiop) call to the our customer backend over the
> > internet.
> > Because of some firewall issue we might have, we use http tunneling
> > iiop to perform this call.
> >
> > Do you know if we can do the same with TomEE ?
> >
> > Best Regards.
> >
> >
> >
> >
>

Re: IIOP tunelling over HTTP

[Jonathan Gallimore]

Hi

TomEE does have the ability to do remote EJB calls over HTTP, although it
isn't based on IIOP. This capability has actually been around in OpenEJB in
the pre-TomEE days :-).

In TomEE, you'll need to enable remote support, and configure a list of
packages that are allowed to be serialized/deserialized.

tomee.remote.support = true
tomee.serialization.class.blacklist = *
tomee.serialization.class.whitelist = org.mycompany.package

After that, you can lookup and call remote EJBs in the usual way. The
global JNDI names of your EJBs should be logged out at deploy time.

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.RemoteInitialContextFactory");
properties.put(Context.PROVIDER_URL, "
http://localhost:8080/tomee/ejb;);

Context ctx = new InitialContext(properties);
Object ref =
ctx.lookup("global/ejb-remote-call-2/Greetings!org.superbiz.remote.Greetings");


This should also work with a reverse proxy such as HTTPD in front of TomEE.
You may wish to turn on authentication so anonymous users can't call your
business methods.

I've always quite liked this functionality as it enables remote EJB access
in a fairly straightforward way, without needing to open up other ports.

Hope that helps.

Jon

On Tue, Mar 23, 2021 at 4:00 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> Previously we were using Welogic. In one of our use-case, we performed a
> remote EJB (so using iiop) call to the our customer backend over the
> internet.
> Because of some firewall issue we might have, we use http tunneling iiop
> to perform this call.
>
> Do you know if we can do the same with TomEE ?
>
> Best Regards.
>
>
>
>

Re: [ANN] Apache TomEE 8.0.6

[Jonathan Gallimore]

Whoops. Hopefully fixed now. Thanks for catching that.

Jon

On Mon, Jan 25, 2021 at 9:39 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Thanks Jon.
> Good job.
>
> I realized TomEE Master is still 8.0.6-SNAPSHOT
> https://github.com/apache/tomee/blob/master/pom.xml
>
> Maybe push did not happen after release prepare/perform?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Jan 25, 2021 at 7:58 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > The Apache TomEE team is pleased to announce the availability of TomEE
> > 8.0.6.
> >
> > Apache TomEE delivers enterprise application containers and services
> based
> > on, but not limited to the Enterprise JavaBeans Specification and Java
> > Enterprise Edition Specifications.
> >
> > These releases primarily provide bug fixes and update the
> > dependencies TomEE uses.
> >
> > Notable changes include:
> >
> > TomEE 8.0.6:
> >
> >
> > [TOMEE-2894] - Translate to Portuguese: examples/rest-cdi
> > [TOMEE-2922] - Tomee Webaccess - error in file script-sample-javascript
> > with "println"
> > [TOMEE-2935] - Naming context should not enforce read only on close
> > [TOMEE-2938] - [TCK/Certification] Xalan missing for JSTL xml:transform
> > [TOMEE-2952] - Shade Taglibs, Xalan and dependencies
> > [TOMEE-2933] - Update EclipseLink to 2.7.7
> > [TOMEE-2947] - Upgrade quartz-openejb-shade in TomEE 8/9
> > [TOMEE-2951] - Upgrade to Tomcat 9.0.41
> > [TOMEE-2953] - Update to Johnzon 1.2.9
> > [TOMEE-2954] - Implement JAX-RS SSE and add example
> > [TOMEE-2955] - Update to CXF 3.3.8
> >
> > Full release notes:
> > https://issues.apache.org/jira/projects/TOMEE/versions/12349403
> >
> > Downloads are available at: http://tomee.apache.org/download-ng.html
> >
> > - The Apache TomEE team.
> >
>

[ANN] Apache TomEE 8.0.6

[Jonathan Gallimore]

The Apache TomEE team is pleased to announce the availability of TomEE
8.0.6.

Apache TomEE delivers enterprise application containers and services based
on, but not limited to the Enterprise JavaBeans Specification and Java
Enterprise Edition Specifications.

These releases primarily provide bug fixes and update the
dependencies TomEE uses.

Notable changes include:

TomEE 8.0.6:


[TOMEE-2894] - Translate to Portuguese: examples/rest-cdi
[TOMEE-2922] - Tomee Webaccess - error in file script-sample-javascript
with "println"
[TOMEE-2935] - Naming context should not enforce read only on close
[TOMEE-2938] - [TCK/Certification] Xalan missing for JSTL xml:transform
[TOMEE-2952] - Shade Taglibs, Xalan and dependencies
[TOMEE-2933] - Update EclipseLink to 2.7.7
[TOMEE-2947] - Upgrade quartz-openejb-shade in TomEE 8/9
[TOMEE-2951] - Upgrade to Tomcat 9.0.41
[TOMEE-2953] - Update to Johnzon 1.2.9
[TOMEE-2954] - Implement JAX-RS SSE and add example
[TOMEE-2955] - Update to CXF 3.3.8

Full release notes:
https://issues.apache.org/jira/projects/TOMEE/versions/12349403

Downloads are available at: http://tomee.apache.org/download-ng.html

- The Apache TomEE team.

Re: connection pool: poisoned connection not being removed from pool

[Jonathan Gallimore]

Sounds like you're using TomEE 8 and Postgres (can you specify the version
of Postgres and the JDBC driver?)

Can we get a bit more detail on the "failover" element - is this a failover
to a secondary database node? Are the database nodes you connect to
specified in the JDBC URI, or do you have a loadbalancer/proxy that is
shifting the connections across?

I'd like to reproduce and find out what's going on.

Jon

On Tue, Jan 19, 2021 at 10:05 AM Emmanuel Touzery <
emmanuel.touz...@lit-transit.com> wrote:

> Hello,
>
>  we are seeing with our TOMEE setup that a connection that was
> (potentially uncleanly) closed from the SQL server remains in the pool
> for longer periods (instead of being closed+reopened), causing long-term
> issues with the application, which we can only fix through a restart.
>
>  A scenario where we see this clearly are failovers: in that case
> the currently open connections will become invalid, which the
> application should realise quickly enough through the validation
> queries, therefore quickly cleaning up the pool (trying to establish a
> new connection would work, except in the first few hundreds of
> milliseconds of the event). But that's not what we see. We also see
> situation where something happens to the SQL server (for instance it's
> restarted), or the connection from TOMEE to the SQL server is disrupted,
> but the application never recovers until TOMEE is restarted.
>
>  Here is our resource, as defined in the tomee.xml:
>
>  
>  jdbcDriver = org.postgresql.Driver
>  jdbcUrl = jdbc:postgresql://x.x.x.x/dbname
>  userName = xx
>  password = xx
>  maxActive = 140
>  maxIdle = 20
>  validationQuery = select version();
>  testWhileIdle = true
>  testOnBorrow = true
>  testOnReturn = false
>  timeBetweenEvictionRuns = 1 millisecond
>  removeAbandonedTimeout = 4400
>  removeAbandoned = true
>  maxWaitTime = 3 millisecond
>  
>
>  We are using hibernate. This is tomee 8.0.1, hibernate 5.4.27 (we
> upgraded from 5.2.12 recently, had the issue with that version too).
>
>  Is there anything else we should do to make sure that we properly
> recover when something happens to some connections from the pool?
>
>  Thank you!
>
> Emmanuel
>
> PS: Some relevant sections of the stacktraces we're seeing for longer
> period of times after the event:
>
>  Caused by: javax.persistence.PersistenceException:
> org.hibernate.exception.JDBCConnectionException: could not prepare
> statement
>  at
> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154)
>
>
>  at
> org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1602)
>
>
>  at org.hibernate.query.Query.getResultList(Query.java:165)
>
>
>  Caused by: org.postgresql.util.PSQLException: This connection
> has been closed.
>  at
> org.postgresql.jdbc.PgConnection.checkClosed(PgConnection.java:766)
>  at
> org.postgresql.jdbc.PgConnection.prepareStatement(PgConnection.java:1582)
>  at
> org.postgresql.jdbc.PgConnection.prepareStatement(PgConnection.java:372)
>  at
> jdk.internal.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
>  at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>
>  at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>  at
> org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:126)
>
>
>  at
> org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:108)
>
>
>  at
> org.apache.tomcat.jdbc.pool.interceptor.AbstractCreateStatementInterceptor.invoke(AbstractCreateStatementInterceptor.java:75)
>
>
>  at
> org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:108)
>
>
>  at
> org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:81)
>
>
>  at com.sun.proxy.$Proxy257.prepareStatement(Unknown
> Source)
>  at
> jdk.internal.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
>  at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>
>  at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>  at
> org.apache.openejb.resource.jdbc.managed.local.ManagedConnection.invokeUnderTransaction(ManagedConnection.java:277)
>
>
>  at
> org.apache.openejb.resource.jdbc.managed.local.ManagedConnection.invoke(ManagedConnection.java:132)
>
>
>  at com.sun.proxy.$Proxy256.prepareStatement(Unknown
> Source)
>  at
> 

Re: [ANN] Welcome new Apache TomEE Committer Richard Zowalla

[Jonathan Gallimore]

Congratulations Richard, and thank you for all your contributions!

Jon

On Tue, Jan 12, 2021 at 9:34 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> The Project Management Committee (PMC) for Apache TomEE has
> invited Richard to become a committer and we are pleased to announce that
> he has accepted.
>
> Richard, a while back (yes I know) when I started contributing and I
> eventually got invited to become a committer, David sent a wonderful
> message[1] based on the well known proverb "It takes a village ... (to
> raise a child)". I can't unfortunately compete with David's phrasing and
> wonderful words, but believe me, I wish I could for you. But I'll try to
> say it with my simple but honest frenchglish words.
>
> I'm very proud to be writing this announcement on behalf of the Apache
> TomEE PMC. You have been continuously contributing to the project, with
> code, documentation, examples and most important, helping out users and
> other potential committers.
>
> You have the Apache way and I'm glad you accepted the invite.
> It's our committer responsibility to enable others to contribute and again
> I think you have been doing great.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity. Being a PMC member enables assistance with the management and
> to guide the direction of the project.
>
>
> Please join me and send him a warm welcome and thank you.
>
>
> [1]
>
> http://tomee-openejb.979440.n4.nabble.com/It-takes-a-village-Jean-Louis-td988516.html#a988522
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

[SECURITY] CVE-2020-13931 Apache TomEE - Incorrect config on JMS Resource Adapter can lead to JMX being enabled

[Jonathan Gallimore]

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache TomEE 8.0.0-M1 - 8.0.3
Apache TomEE 7.1.0 - 7.1.3
Apache TomEE 7.0.0-M1 - 7.0.8
Apache TomEE 1.0.0 - 1.7.5

Description:
If Apache TomEE is configured to use the embedded ActiveMQ broker, and the
broker config is misconfigured, a JMX port is opened on TCP port 1099,
which does not include authentication. CVE-2020-11969 previously addressed
the creation of the JMX management interface, however the incomplete fix
did not cover this edge case.

Mitigation:
- Upgrade to TomEE 7.0.9 or later
- Upgrade to TomEE 7.1.4 or later
- Upgrade to TomEE 8.0.4 or later

Ensure the correct VM broker name is used consistently across across the
resource adapter config.

Credit: Thanks to Frans Henskens for discovering and reporting this issue.

[ANN] Apache TomEE 8.0.5 & Apache TomEE 9.0.0-M3

[Jonathan Gallimore]

The Apache TomEE team is pleased to announce the availability of TomEE
8.0.5 and TomEE 9.0.0-M3.

Apache TomEE delivers enterprise application containers and services based
on, but not limited to the Enterprise JavaBeans Specification and Java
Enterprise Edition Specifications.

These releases primarily provide bug fixes and update the
dependencies TomEE uses.

Notable changes include:

TomEE 8.0.5:

[TOMEE-2874] - Translate to Portuguese: examples/webservice-handlerchain
[TOMEE-2517] - Bean Validation with MicroProfile JWT Improvement
[TOMEE-2520] - MP-JWT and BeanValidation Example
[TOMEE-2910] - update spec-apis for some fixes
[TOMEE-2902] - Upgrade to CXF 3.3.7
[TOMEE-2904] - Upgrade ActiveMQ to 5.16.0
[TOMEE-2906] - Apache BVal 2.0.5
[TOMEE-2911] - Update to Geronimo javamail to 1.6


Full release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348622

Downloads are available at: http://tomee.apache.org/download-ng.html

- The Apache TomEE team.

Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Jonathan Gallimore]

> As an alternative, I could create a SVN patch file and send it to the
Geronimo dev list?

I'd suggest creating a JIRA, and attaching the patch to that. If you can
also follow up here with the JIRA, that would be fantastic.

Thanks Richard!

Jon

On Wed, Dec 2, 2020 at 11:21 AM Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:

> Hi,
>
> as an update:
>
> I was able to locate the SVN repository [1] and did my testing with a
> related patch.
>
> @Jean-Louis: Can you point me to documentation on how to provide a PR
> for Geronimo Java Mail 1.6 ? As an alternative, I could create a SVN
> patch file and send it to the Geronimo dev list?
>
> Thanks,
> Richard
>
>
>
>
> [1] https://svn.apache.org/repos/asf/geronimo/javamail/trunk
>
> Am Mittwoch, den 02.12.2020, 10:44 + schrieb Zowalla, Richard:
> > Hi,
> >
> > thanks for the fast feedback.
> >
> > I did some debugging and found that the only allowed protocol is
> > "TLSv1" which is hardcoded in
> > MailConnection.java#getConnectedTLSSocket().
> >
> > Can you point me to the source code of the geronomo-javamail_1.6_mail
> > package in v1.0.0 ?
> >
> > I would like to test, if adding other protocols would solve the
> > issue.
> >
> > I only found [1], which is an outdated GitHub Repo. [2] does not
> > contain Geronimo Java Mail 1.6
> >
> > Best,
> > Richard
> >
> > [1]
> > https://github.com/apache/geronimo-javamail
> >
> > [2]
> > https://github.com/apache/geronimo-specs
> >
> >
> >
> >
> >
> >
> > Am Dienstag, den 01.12.2020, 12:16 +0100 schrieb Jean-Louis Monteiro:
> > > Hey Richard,
> > >
> > > Thanks for the detailed email.
> > > I have contributed recently to Geronimo Mail 1.6 but to be honest I
> > > can't
> > > answer out of my head.
> > >
> > > Cesar also worked on it, so he might be able to help.
> > > Other than that, I'm CC'ing Geronimo mailing list. Maybe Romain and
> > > others
> > > can help there.
> > >
> > > Jean-Louis
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > >
> > >
> > > http://www.tomitribe.com
> > >
> > >
> > >
> > >
> > > On Tue, Dec 1, 2020 at 10:55 AM Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de
> > >
> > > > wrote:
> > > > Hi all,
> > > >
> > > > I have updated our TomEE instances to 8.0.5 as (Geronimo) Java
> > > > Mail
> > > > 1.6
> > > > replaced the rather outdated (Geronimo) Java Mail 1.4 in this
> > > > release.
> > > >
> > > > Up to now, we were using
> > > >
> > > > 
> > > > com.sun.mail
> > > > jakarta.mail
> > > > 1.6.5
> > > > provided
> > > > 
> > > >
> > > > as our mail server is configured to only support TLS 1.2 or TLS
> > > > 1.3.
> > > > These protocols were not supported by Java Mail 1.4.
> > > >
> > > > I recently tried to migrate to the provided Geronimo Java Mail
> > > > 1.6
> > > > hoping for better protocol support, but I get
> > > > java.net.SocketException
> > > > due to a javax.net.ssl.SSLHandshakeException with "Received fatal
> > > > alert: protocol_version".
> > > >
> > > > The full stack trace and related debug output can be found here:
> > > > https://gist.github.com/rzo1/64c23a1d9be752eadf36cf3e1c719ffa
> > > >
> > > > )
> > > >
> > > > The mail session is configured as follows:
> > > >
> > > > 
> > > > 
> > > > 
> > > > mail.debug=true
> > > > mail.transport.protocol=smtp
> > > > mail.smtp.starttls.enable=true
> > > > mail.smtp.starttls.required=true
> > > > mail.smtp.ssl.enable=false
> > > > mail.smtp.host=mail.mail-server.com
> > > > mail.smtp.port=587
> > > > mail.smtp.auth=true
> > > >
> > > > mail.smtp.user=d...@mail-server.com
> > > >
> > > >
> > > > 
> > > > password=fancyPassword
> > > > 
> > > > 
> > > >
> > > > Question:
> > > >
> > > > - Does anybody have an idea how to get Geronimo Java Mail 1.6
> > > > talking
> > > > via TLS 1.2 or TLS 1.3 to our mail server?
> > > >
> > > > - Is TLS 1.2 / TLS 1.3 supported in Geronimo Java Mail 1.6?
> > > >
> > > > If this is the wrong list, please give me an advice which list
> > > > would be
> > > > a better fit.
> > > >
> > > > Thanks in advance,
> > > > Richard Z
> > > >
> > > >
> > > >
> > > >
> --
> Richard Zowalla, M.Sc.
> Research Associate, PhD Student | Medical Informatics
>
> Hochschule Heilbronn – University of Applied Sciences
> Max-Planck-Str. 39
> D-74081 Heilbronn
> phone: +49 7131 504 6791
> mail: richard.zowa...@hs-heilbronn.de
> web: https://www.mi.hs-heilbronn.de/
>

Re: TomEE7 - JNDI lookup in web application fails on TomEE 7 web profile runtime

[Jonathan Gallimore]

> java.lang.NoClassDefFoundError:
org/apache/activemq/ra/ActiveMQResourceAdapter

What flavor of TomEE are you using? If you're using webprofile, you maybe
need to switch to plus or plume (which include ActiveMQ).

Where are com..ServiceObjectFactory and
com..GenericBindingObjectFactory on your classpath? Are they in
the application itself, or in the lib directory? If its in the webapp, can
you try putting the necessary classes in a jar in the lib folder? If that
works, that may suggest there's a bug we need to look at, but it would be
useful to know.

Jon

On Wed, Oct 28, 2020 at 2:48 PM Vural, Adem  wrote:

> Hi
>
> we are trying to migrate an existing web application from following
> runtimes
>
>   *   Java EE 6 webprofile (working)
>   *   Java Web Tomcat 7 (working)
> to
>
>   *   TomEE 7 web profile (not working)
>   *   Java Web Tomcat 8 (working)
>
> While this worked out of the box for Web Tomcat 8 we are struggling to
> make it work for the TomEE 7 web profile.
> The JNDI lookup for a resource is not working with the TomEE 7 web profile.
> I am suspecting a misconfiguration on my site but I am not sure what needs
> to be corrected.
>
> Following some config files and logs.
>
> context.xml file:
>
>
> 
>
> 
>
> 
> type="javax.jms.ConnectionFactory"
>
> description="JMS Connection Factory"
>
> factory="com..GenericBindingObjectFactory"
>
> java.naming.binding="default" />
>
>
>
>
>
> 
> auth="Container"
>
> type="com..ConnectivityConfiguration"
>
> factory="com..ServiceObjectFactory" />
>
> 
>
> web.xml file:
>
>
> 
>
> http://www.w3.org/2001/XMLSchema-instance; xmlns="
> http://java.sun.com/xml/ns/javaee; xmlns:web="
> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
>
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd<
> http://java.sun.com/xml/ns/javaee%20http:/java.sun.com/xml/ns/javaee/web-app_2_5.xsd>"
> id="WebApp_ID" version="2.5">
>
> 
>
> jms/default
>
> javax.jms.ConnectionFactory
>
> 
>
>
>
> ... some servlets
>
>
>
> 
>
> connectivityConfiguration
>
> com..ConnectivityConfiguration
>
> 
>
>
>
>
>
> 
>
> The jms/default resource is found while the connectivityConfiguration is
> not.
> The difference is that jms/default type class and factory is residing in
> the project and is provided within the deployed application WAR.
> The connectivityConfiguration resource cannot be found. The class and its
> factory is provided from the runtime environment.
>
>
> LOG (when resources are defined in context.xml)
>
> 2020 10 27
> 11:12:00#+00#ERROR##anonymous#localhost-startStop-1#na##conntest7#web##na#na#na#na#Failed
> to lookup 'java:comp/env/connectivityConfiguration' from InitialContext.
> javax.naming.NamingException: Could not load resource factory class
> at
> org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:70)
> at
> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
> at
> org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
> .
> Caused by: java.lang.ClassNotFoundException:  placeholder>.ServiceObjectFactory
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1358)
> at
> org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:208)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1180)
> at
> org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:65)
> ... 48 common frames omitted
> |
>
> |
> 2020 10 27
> 11:12:00#+00#ERROR#OpenEJB.startup##anonymous#localhost-startStop-1#na##conntest7#web##na#na#na#na#Unable
> to register MBean  java.lang.NullPointerException: Delegate cannot be null
> at
> org.apache.openejb.monitoring.MBeanPojoWrapper.(MBeanPojoWrapper.java:65)
> at
> org.apache.openejb.assembler.classic.Assembler.registerAsMBean(Assembler.java:3393)
> at
> org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:3367)
> at
> org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2996)
> at
> org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
> at
> org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
> at
> 

Re: After upgrading from Tomee 7.1.3 to 8.0.3, began receiving ConcurrentAccessTimeoutException

[Jonathan Gallimore]

Can we start by looking at a thread dump (jstack) taken at the point where
you've encountered the exception?

That will hopefully show where your stateless bean instances are being
used. We may need to debug why they aren't being returned to the pool if it
looks like there is a leak (although I think that's unlikely).

Increasing the maxSize is often the first port of call, but I tend to find
it makes things crash and burn harder. We're better off finding the root
cause before increasing the parameters.

Jon

On Tue, Oct 6, 2020 at 8:25 AM Kean Erickson 
wrote:

> Hello,
>
> So I've doubled maxSize to 40 and I'm still seeing the same problem
> of timeouts encountered while waiting for an available stateless
> bean, which was never an issue until tomee 8 was introduced.
>
> Is there any known consideration with tomee 8 vs. 7 that the number of
> available instances in a stateless pool would wind up being somehow
> smaller, to the point that the pool runs out?
>
> On Sat, Oct 3, 2020 at 10:57 PM Kean Erickson 
> wrote:
>
> > I am using a BeanManager to acquire classes annotated @Stateless in
> > multiple threads. This worked fine in 7.1.3, but now in 8.0.3 I'm
> receiving
> > this error:
> >
> > javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> > Stateless Session Bean pool.  Waited 30 SECONDS
> >
> > I see a number of these exceptions until the machine roughly runs out of
> > memory and restarts (though there's never an OutOfMemoryError in logs). I
> > had encountered this error in the past and solved it completely by
> > increasing the maxSize to 20 in tomee.xml:
> >
> > 
> > maxSize = 20
> > 
> >
> > Is there any reason that I would need to boost this value in tomee 8
> > compared to tomee 7? Or any reason the memory footprint would be
> different
> > enough to cause a crash. No other differences, same configuration
> >
> > Thanks,
> > -Kean
> >
> >
>

Re: Missing xalan library in TomEE 7.0.7 and 7.0.8

[Jonathan Gallimore]

The reason for its removal is that there are some bugs with Xalan's unicode
handling, and this library hasn't seen an update for 6 years. I wasn't
aware of the regression at the time, so thank you for flagging that up.

I think my preference would be to look at how we can resolve the issue
without pulling these dependencies back in - I'll take a look at how we do
that.

Jon

On Mon, Oct 5, 2020 at 9:00 AM Lazar Kirchev 
wrote:

> Hello,
>
> About three years ago, xalan library was added to TomEE following
> https://issues.apache.org/jira/browse/TOMEE-2113
>
> Now in TomEE 7.0.7 this library was removed with
>
> https://github.com/apache/tomee/commit/8ab6bb2fb78dd8818c8b330a16687015f4719c5e
> although the apache taglibs.* 1.2.5 are still used.
>
> Now the same problem described in TOMEE-2113 appears again.
>
> Why xalan was removed in 7.0.7 and do you have plans to include it again?
>
> Regards,
> Lazar
>

Re: https://vimeo.com/7393498

[Jonathan Gallimore]

The OpenEJB Eclipse Plugin works on the latest version of Eclipse? Wow. A
few people have reached me through a few different mediums about it, and
had wondered if it was time for an update. OpenEJB 3.1.4 is super old, I'm
wondering if we can use this to deploy EARs to recent versions of TomEE
without too many changes.

Thanks for sharing your experience.

Jon

On Sun, Aug 16, 2020 at 11:27 AM Zahid Rahman  wrote:

> The demonstration  worked like a charm.
>
> Excellent accompanied talk
> i.e. debug and remote server code changes.
>
> tested on using JDK 8 on
> Eclipse IDE for Enterprise Java Developers.
> Version: 2020-03 (4.15.0
> Ubuntu 20.04 LTS
> openejb 3.1.4
>
> same version stateless bean example
> and OpenEJB eclipse plugin
>
> Regards
> Zahid
>
> https://www.backbutton.co.uk/ 
> ¯\_(ツ)_/¯
> ♡۶Java♡۶RMI ♡۶
> 
>

Re: CXF version in TomEE 7.x

[Jonathan Gallimore]

Sorry for the delayed reply.

Just a little bit of background on the TomEE branches:

Current master / TomEE 8, targets EE 8, and requires a minimum Java SE 8.
7.0.x targets EE7, and requires a minimum Java SE 7.
7.1.x also targets EE7, and is intended to be essentially the same as
7.0.x. It includes MicroProfile, which requires Java SE 8, so this version
of TomEE also requires Java SE 8.

As you point out, CXF 3.1.x is not supported by the community any more. We
can probably provide patches, and they may be merged, but they are unlikely
to cut a release for us. Moving to a more recent version, means that we
break the minimum Java SE 7 version on TomEE 7.0.x. If we just moved TomEE
7.1.x to a later version, end up with TomEE 7.0.x and 7.1.x diverging quite
a bit, which brings about the question of whether the 7.1.x branch is
worth keeping around.

TomEE 8 uses a more up to date version of CXF, so if migrating to TomEE 8
is an option for you, that's worth considering.

The CVE you specifically reference I'd need to specifically take a look at.
Its not flagging up against the version of CXF in 7.1.x for me here, so I'd
need to see where the JWK functionality was introduced. There's a couple of
other vulnerabilities in this version of CXF, such as CVE-2020-1954
and CVE-2019-12419 which shouldn't affect TomEE as those features of CXF
are not used by TomEE itself. Your application may be using them, but if it
is, its likely not portable between Java EE servers and quite tightly
coupled to CXF.

All this being said, this thread has given me an idea - I'll experiment
with it and come back with an update.

Jon





On Thu, Jul 2, 2020 at 7:58 AM Lazar Kirchev 
wrote:

> Hello,
>
> Any update on this?
>
> Thanks,
> Lazar
>
> On Fri, Jun 12, 2020 at 9:26 AM Lazar Kirchev 
> wrote:
>
> > Hello,
> >
> > Both TomEE 7.0.x and TomEE 7.1.x latest versions ship with CXF version
> > 3.1.18. However, CXF 3.1.x is not supported anymore and version 3.1.18
> > (which is the last one) is from beginning of 2019 and has security
> > vulnerabilities (e.g. https://nvd.nist.gov/vuln/detail/CVE-2019-12423
> and
> > https://nvd.nist.gov/vuln/detail/CVE-2019-17573).
> > Replacing the CXF version in TomEE 7.x with 3.2.x or 3.3.x does not work
> > because these have incompatible changes in some interfaces which TomEE
> > implements for integrating CXF.
> > Do you have any plans to adopt new versions of CXF in TomEE 7.x? If not
> > any suggestions how to work this problem around?
> >
> > Thanks,
> > Lazar
> >
>

CVE-2020-11969 Apache TomEE - useJMX attribute on ActiveMQ resource adapter URI causes authenticated JMX port to be open

[Jonathan Gallimore]

CVE-2020-11969: Apache TomEE - useJMX attribute on ActiveMQ resource
adapter URI causes authenticated JMX port to be open

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache TomEE 8.0.0-M1 - 8.0.1
Apache TomEE 7.1.0 - 7.1.2
Apache TomEE 7.0.0-M1 - 7.0.7
Apache TomEE 1.0.0 - 1.7.5

Description:
If Apache TomEE is configured to use the embedded ActiveMQ broker, and the
broker URI includes the useJMX=true parameter, a JMX port is opened on TCP
port 1099, which does not include authentication.

Mitigation:
- Upgrade to TomEE 7.0.8 or later
- Upgrade to TomEE 7.1.3 or later
- Upgrade to TomEE 8.0.2 or later

Alternatively, users may wish to remove the useJMX option from the URI (the
default is false).

- The Apache TomEE team.

[ANN] Apache TomEE 8.0.2, 7.1.3, 7.0.8

[Jonathan Gallimore]

The Apache TomEE team is pleased to announce the availability of TomEE
8.0.2. 7.1.3 and 7.0.8.

Apache TomEE delivers enterprise application containers and services based
on, but not limited to the Enterprise JavaBeans Specification and Java
Enterprise Edition Specifications.

These releases primarily provide bug fixes and update the
dependencies TomEE uses.

Notable changes include:

TomEE 8.0.2:

TOMEE-2788 - Upgrade Bouncycastle to 1.64
TOMEE-2612 - Update javaee-api to 8.0-4
TOMEE-2806 - Update WSS4J to 2.2.5
TOMEE-2811 - Update to Tomcat 9.0.35
TOMEE-2826 - Update ActiveMQ to 5.15.12
TOMEE-2808 - Update to Johnzon 1.2.5

Full release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346650

TomEE 7.1.3:

TOMEE-2788 - Upgrade Bouncycastle to 1.64
TOMEE-2806 - Update WSS4J to 2.2.5
TOMEE-2812 - Update to Tomcat 8.5.55
TOMEE-2826 - Update ActiveMQ to 5.15.12

Full release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12347033

TomEE 7.0.8

TOMEE-2788 - Upgrade Bouncycastle to 1.64
TOMEE-2806 - Update WSS4J to 2.2.5
TOMEE-2812 - Update to Tomcat 8.5.55

Full release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346649

Downloads are available at: http://tomee.apache.org/download-ng.html

- The Apache TomEE team.

Re: TomEE as JNDI server

[Jonathan Gallimore]

Sounds like an interesting use-case. ActiveMQ does have some JNDI
capabilities: https://activemq.apache.org/jndi-support.html, and the
bindings are controlled via system properties.

How are you adding your bindings in TomEE? Adding resources to tomee.xml?

Off the top of my head, it sounds ok. If you give us an idea of what your
TomEE config looks like (without anything sensitive, such as passwords),
and how you're doing the lookup from PeopleSoft (and whether its the App
server, or a rich client connecting to JNDI and ActiveMQ), we'll probably
be able to give you an idea of whether there are any issues with what
you're doing.

My own PeopleSoft knowledge is from v7.5, so quite out of date, I suspect.
I don't know the specifics of adding libraries and system properties to
Peoplesoft itself, for example, but we can probably guide you in terms of
treating it as a standalone Java application.

Jon

On Tue, May 12, 2020 at 12:15 AM Shultz, Dmitry 
wrote:

> Hi Guys,
>
> We have a need to spin up the stand alone JNDI server (in order to support
> some PeopleSoft/AMQ integration because AMQ doesn't have one).
> There are multiple TomEE's  already running In our environments (and we
> are pretty happy with it) + operations team is comfortable with  it as
> well, so the obvious choice is to spin up another TomEE just to host/serve
> JMDI context to the external client (PSFT).
>
> Is this a good/supported idea?
> If not, what are the options?
>
> Cheers,
> Dmitry
>

Re: Memory Leak with JsonbBuilder

[Jonathan Gallimore]

I think you managed to get a solution from the Johnzon team. To answer the
1.2.x question - I believe the upgrade causes regressions on the OpenAPI
MicroProfile TCK which needs further investigation.

Jon

On Wed, Apr 22, 2020 at 12:20 AM Stéphane Kay
 wrote:

> Hi,
>
> In Tomee 8.01 – 8.02 as well - we can reproduce the memory leak described
> in
>
> https://issues.apache.org/jira/browse/JOHNZON-161
>
> Problem :
>
> JsonbBuilder.create() - produces a Jsonb instance – that isn’t Garbage
> collected.
>
>
>
> I just realized that Johnzon has a 1.2.4 on Maven Central.
>
> Question – why is TomEE stuck on Johnzon 1.1.13  and why not following
> 1.2.x versions?
>
>
>
>
>
> Stephane Kay
>
> Software Architect
>
>
>
> Abraxas Cari
>
> Succursale d’Abraxas Informatique SA
>
>
>
> Avenue de la Gottaz 28A  | CH-1110 Morges
>
> direct +41 58 660 19 03  | mobile +41 76 427 02 39 | service desk +41 848
> 822 828
>
> stephane@abraxas.ch  |  www.abraxas.ch
>
>
>
> [image:
> /Users/macdev/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_27354483]
>
>
>

Re: Nabble link not working?

[Jonathan Gallimore]

Hi Ross

Thanks for reporting this - I'll reach out to Nabble and see if we can get
that resolved. It returns a 500 error for me. Nabble itself is beyond our
control, so in the meantime I'd suggest using the mailing list archive at
Apache: http://mail-archives.apache.org/mod_mbox/tomee-dev/ and
http://mail-archives.apache.org/mod_mbox/tomee-users/.

I'll get the page updated to provide those links.

Jon

On Mon, Mar 30, 2020 at 6:11 PM Cohen, Ross  wrote:

> The Forum link on the support page (
> http://tomee-openejb.979440.n4.nabble.com/)  now seems to go a blank
> page.   I can see other forums on nabble, but not the tomee list.Is
> anybody aware of this problem?
>
> Ross
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
>

Re: TomEE versions

[Jonathan Gallimore]

Thanks for your email, and apologies for the confusion - I'll try and help
:)

> - 8.0.1 ok Java EE 8 release (uncertified) but is it fully Java 11
compatible?

Correct, and yes, this is Java 11 compatible. If you find something that
isn't working on Java 11, please do report it and we'll fix it.

> - 7.1.2 why did this not supersede 7.0.x? Is it safe/recommended to go to
this version from 7.0.5 or rather stay at the 7.0.x branch?

The 7.1.x branch is intended to remain parallel to 7.0.x in terms of
features and Java EE level, but introduces MicroProfile, and has a minimum
Java SE requirement of Java 8 as opposed to 7.

> - 7.0.7 we are still running 7.0.5 everywhere, mainly because the
underlying Tomcat has not been upgraded in any of the above versions, is
that still correct? Which are the appropriate Tomcat versions per TomEE?

If you're on 7.0.5 now, upgrading to 7.0.7 will bring you up to the current
level on the 7.0.x branch (last release was about a month ago), and
shouldn't be too big a jump. That uses Tomcat 8.5.50. There's been a CVE
identified against that relating to the AJP connector, so I'd advise you to
remove the AJP connector that is present by default, unless you're
specifically using it. I'd like to push out releases for 7.0.8, 7.1.3 and
8.0.2, but there is a pending dependency that needs need to be released
first.

I hope that helps, but please do let us know if you have any further
queries!

Jon

On Thu, Mar 5, 2020 at 8:47 AM  wrote:

> Hey guys,
>
> I am a little confused about the 3 versions of TomEE which are still
> maintained (releases on Jan 20):
>
>
> - 7.1.2 why did this not supersede 7.0.x? Is it safe/recommended to go to
> this version from 7.0.5 or rather stay at the 7.0.x branch?
> - 7.0.7 we are still running 7.0.5 everywhere, mainly because the
> underlying
> Tomcat has not been upgraded in any of the above versions, is that still
> correct? Which are the appropriate Tomcat versions per TomEE?
>
> Thanks for clarifications!
>
> Best
> Fabian
>

Re: Is there a way to monitor, using JMX (jconsole), MDB pool ?

[Jonathan Gallimore]

Off the top of my head - some JCA resource adapters provide "endpoint
pooling", and so by default, TomEE lets them handle that themselves. Around
the 2017 timeframe, we found a resource adapter that didn't provide
pooling, so we added the "pool" option to the MDB container, which if set
to true, would pool in basically the same manner to the stateless pool.

With pooling handled in the resource adapter, I wouldn't expect to see
anything in JMX unless the resource adapter adds it. Try setting pool =
true on the resource adapter and check 1) that you see the information
you're after, and 2) that everything still performs and functions correctly.

Jon

On Wed, Feb 26, 2020 at 9:04 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Cesar,
>
> Definitively not under the Pool folder which is, for me, the logical
> location where to find it as Stateless Session Bean pool is there.
> The only entry I have found is under the ConnectionFactory with a MaxSize
> set to 10 but for me it's more the max connection number, right ?
>
> Best Regards.
>
> -Original Message-
> From: Cesar Hernandez [mailto:cesargu...@gmail.com]
> Sent: mardi 25 février 2020 22:25
> To: users@tomee.apache.org
> Subject: Re: Is there a way to monitor, using JMX (jconsole), MDB pool ?
>
> Hi,
> Have you checked under --> MBeans -> openejb.management in Jconsole?
>
> El mar., 18 feb. 2020 a las 7:29, COURTAULT Francois (<
> francois.courta...@thalesgroup.com>) escribió:
>
> > Hello everyone,
> >
> > Using the jconsole, I am able to monitor the SLSB pools under the Pool
> > folder.
> > But I am not able to monitor the MDB pools under the Pool folder.
> >
> > Is there any other location to look at ?
> >
> > Best Regards.
> >
> >
> >
> >
>
> --
> Atentamente:
> César Hernández.
>

Re: TomEE microprofile memory consumption

[Jonathan Gallimore]

Quick note - I'm aware of this question and I couple of others you've
asked, and I'm definitely not ignoring them. I don't know the answer off
the top of my head and will need to check code and I have a long TODO list
- I hope you understand.

If someone else can beat me to answering, that's great, thank you.

Jon

On Mon, Feb 17, 2020 at 9:30 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> Is there someone to answer to this question: " Could you confirm that if
> we haven't this entry in the system.properties or set to none then all MP
> specifications are disabled at runtime ? "
>
> Best Regards.
>
> -Original Message-
> From: COURTAULT Francois
> Sent: mercredi 12 février 2020 11:13
> To: users@tomee.apache.org
> Subject: RE: TomEE microprofile memory consumption
>
> Hello Jonathan,
>
> JIRA ticket created: TOMEE-2771
>
> If you can answer to the following question(already asked in the ticket) :
> Could you confirm that if we haven't this entry in the system.properties or
> set to none then all MP specifications are disabled et runtime ?
> It should be fine.
>
> Best Regards.
>
> -Original Message-
> From: COURTAULT Francois [mailto:francois.courta...@thalesgroup.com]
> Sent: mercredi 12 février 2020 09:51
> To: users@tomee.apache.org
> Subject: RE: TomEE microprofile memory consumption
>
> Hello Jonathan
>
> I will do so (Jira).
> BTW, is this property tomee.mp.scan documented somewhere ?
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mardi 11 février 2020 19:25
> To: users@tomee.apache.org
> Subject: Re: TomEE microprofile memory consumption
>
> Awesome, thanks for the feedback. We'd still want to fix the actual issue.
> If you get time, if you can file a JIRA, that would be great.
>
> Jon
>
> On Tue, Feb 11, 2020 at 6:01 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello Jonathan,
> >
> > We did the test (remove tomee.mp.scan = all  entry in
> > system.properties) with TomEE MP and it solves the issue we have:  a
> > lot of opentracing objects created.
> > We don't have this issue (a lot of opentracing objects created) in
> > TomEE Plus because this entry doesn't exist in system.properties !!!
> >
> > Best Regards.
> >
> > -Original Message-
> > From: COURTAULT Francois
> > Sent: mardi 11 février 2020 10:32
> > To: users@tomee.apache.org
> > Subject: RE: TomEE microprofile memory consumption
> >
> > Hello Jonathan,
> >
> > As I have mentioned, we see the issue in TomEE MP but not in TomEE Plus !
> > So I did a comparison of the 2 flavors: lib + conf
> >
> > The only difference I have seen is in the system.properties where I
> > have the line below in TomEE MP and not this one in TomEE Plus !
> > This could explain. We will try to remove this line to see if it
> > solves the memory issue we have and will let you know.
> >
> > Best Regards.
> >
> > -Original Message-
> > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> > Sent: lundi 10 février 2020 23:14
> > To: users@tomee.apache.org
> > Subject: Re: TomEE microprofile memory consumption
> >
> > Allow me start over, if I may.
> >
> > What are you seeing in your memory dumps that's a concern - a large
> > number of ScopeImpl objects? Could you provide some screenshots from
> > VisualVM for us? I'd be interested in object counts, and whether there
> > are references, and if so, what they are.
> >
> > The TaskThread comes from Tomcat. It being present doesn't sound like
> > an issue, but I appreciate you've asked because you have some concern
> > - can you provide some more context?
> >
> > > You didn't answer to this question: Is there a way to disable
> > > opentracing
> > in TomEE MP ? Is it possible ?
> >
> > Its a setting in the Geronimo OpenTracing project:
> > https://github.com/apache/geronimo-opentracing. Try setting
> > geronimo.opentracing.filter.active to false (an entry in
> > conf/system.properties should do the trick).
> >
> > Jon
> >
> > On Mon, Feb 10, 2020 at 6:46 PM COURTAULT Francois <
> > francois.courta...@thalesgroup.com> wrote:
> >
> > > Hello Jonathan,
> > >
> > > Quite complex for us what you ask for.
> > >
> > > BTW, have you any idea about this
> > > org.apache.tomcat.util.threads.TaskThread in the memory dump we have.
> > > Where could it come 

Re: Docker images for 8.0.0

[Jonathan Gallimore]

Its in progress - there's some feedback which came in last night, which I
suspect Rod will get to shortly, he's usually pretty responsive.

Jon

On Fri, Feb 14, 2020 at 3:56 PM Tobias Erdle  wrote:

> Hello again,
>
> I just wanted to ask if there are news relating this topic. I saw that
> the GitHub repo seems to have updated Dockerfiles for 8.0.1 but still no
> release to Dockerhub :( Is there any plan to release the images soon?
>
> Best regards,
>
> Tobias
>
> On 20.01.20 10:52, Jonathan Gallimore wrote:
> > 8.0.1 is being release today having just passed a vote, so I'm
> anticipating
> > Rod / Carl and other will be looking to get a Docker image for that done
> > fairly quickly. I'll take a look at the problem with the GitHub project
> you
> > mention. Thanks for pointing that out.
> >
> > Jon
> >
> > On Mon, Jan 20, 2020 at 8:53 AM Tobias Erdle 
> wrote:
> >
> >> Hi again,
> >>
> >> just wanted to ask if there are any updates on this topic, as I'm still
> >> not able to file an issue in the GitHub repo (although the README links
> >> to them, but they are disabled) and there aren't updates on Dockerhub.
> >>
> >> Would be great to get some answer ;)
> >>
> >> Thanks and best regards,
> >>
> >> Tobias Erdle
> >>
> >> --
> >> Tobias Erdle
> >>
> >> e-mail: tobi.er...@gmail.com
> >>
> >>
> --
> Tobias Erdle
>
> e-mail: tobi.er...@gmail.com
>
>

Re: TomEE 7.0.6 + Primefaces 7.0 + Omnifaces 2.7.3

[Jonathan Gallimore]

Thanks for following up with the solution!

On Thu, Feb 13, 2020 at 12:10 AM Shultz, Dmitry 
wrote:

> For anybody hitting the same issue, it was resolved by adding
> org.omnifaces to the resources/META-INF/scan.xml
>
>
>
> Cheers,
>
>
>
> *Dmitry Shultz*
>
> *Senior Software Developer*
>
>
>
> *[image: cid:image001.png@01D051C6.BA585530]*
>
>
>
> 1540 Kalamalka Lake Rd.
>
> Vernon, BC V1T 6V2
>
> t: 250.558.3200 (x 547)
>
> *KalTire.com*
>
>
>
> *From:* Shultz, Dmitry
> *Sent:* Tuesday, February 11, 2020 12:32 PM
> *To:* users@tomee.apache.org
> *Subject:* TomEE 7.0.6 + Primefaces 7.0 + Omnifaces 2.7.3
>
>
>
> Hi All,
>
>
>
> I’m running service that is using Deltaspike + Primefaces in TomEE (7.0.6)
> quite successfully, but experiencing some issue when trying to add
> Omnifaces  components to the page (full stacktrace below). Note, adding
>  Omnifaces websocket (o:socket) works pretty good, but I had to register
> the  org.omnifaces.ApplicationListener in web.xml
>
>
>
>
>
> Message:Undefined component type
> org.omnifaces.component.input.Formjavax.faces.FacesException: Undefined
> component type org.omnifaces.component.input.Form
> at
> org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1437)
> at
> org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1405)
> at
> javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123)
> at
> javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123)
> at
> javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123)
> at
> javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123)
> at
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.createComponent(ComponentTagHandlerDelegate.java:605)
> at
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:285)
> at
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:50)
> at
> org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161)
> at
> org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59)
> at
> org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:521)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:575)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:553)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
> at
> org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:228)
> at
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
> at
> org.apache.myfaces.view.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:86)
> at
> org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
> at
> org.apache.myfaces.view.facelets.impl.TemplateContextImpl$TemplateManagerImpl.apply(TemplateContextImpl.java:193)
> at
> org.apache.myfaces.view.facelets.impl.TemplateContextImpl.includeDefinition(TemplateContextImpl.java:136)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:475)
> at
> org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:94)
> at
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
> at
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:55)
> at
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:374)
> at
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:50)
> at
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
> at
> org.apache.myfaces.view.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:195)
> at
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
> at
> org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59)
> at
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
> at
> org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:521)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:575)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:553)
> at
> org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
> at
> 

Re: TomEE microprofile memory consumption

[Jonathan Gallimore]

Awesome, thanks for the feedback. We'd still want to fix the actual issue.
If you get time, if you can file a JIRA, that would be great.

Jon

On Tue, Feb 11, 2020 at 6:01 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> We did the test (remove tomee.mp.scan = all  entry in system.properties)
> with TomEE MP and it solves the issue we have:  a lot of opentracing
> objects created.
> We don't have this issue (a lot of opentracing objects created) in TomEE
> Plus because this entry doesn't exist in system.properties !!!
>
> Best Regards.
>
> -Original Message-
> From: COURTAULT Francois
> Sent: mardi 11 février 2020 10:32
> To: users@tomee.apache.org
> Subject: RE: TomEE microprofile memory consumption
>
> Hello Jonathan,
>
> As I have mentioned, we see the issue in TomEE MP but not in TomEE Plus !
> So I did a comparison of the 2 flavors: lib + conf
>
> The only difference I have seen is in the system.properties where I have
> the line below in TomEE MP and not this one in TomEE Plus !
> This could explain. We will try to remove this line to see if it solves
> the memory issue we have and will let you know.
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: lundi 10 février 2020 23:14
> To: users@tomee.apache.org
> Subject: Re: TomEE microprofile memory consumption
>
> Allow me start over, if I may.
>
> What are you seeing in your memory dumps that's a concern - a large number
> of ScopeImpl objects? Could you provide some screenshots from VisualVM for
> us? I'd be interested in object counts, and whether there are references,
> and if so, what they are.
>
> The TaskThread comes from Tomcat. It being present doesn't sound like an
> issue, but I appreciate you've asked because you have some concern - can
> you provide some more context?
>
> > You didn't answer to this question: Is there a way to disable
> > opentracing
> in TomEE MP ? Is it possible ?
>
> Its a setting in the Geronimo OpenTracing project:
> https://github.com/apache/geronimo-opentracing. Try setting
> geronimo.opentracing.filter.active to false (an entry in
> conf/system.properties should do the trick).
>
> Jon
>
> On Mon, Feb 10, 2020 at 6:46 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello Jonathan,
> >
> > Quite complex for us what you ask for.
> >
> > BTW, have you any idea about this
> > org.apache.tomcat.util.threads.TaskThread in the memory dump we have.
> > Where could it come from ?
> >
> > You didn't answer to this question: Is there a way to disable
> > opentracing in TomEE MP ? Is it possible ?
> >
> > Best Regards.
> >
> > -Original Message-
> > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> > Sent: lundi 10 février 2020 18:21
> > To: users@tomee.apache.org
> > Subject: Re: TomEE microprofile memory consumption
> >
> > > I can provide you some memory dumps if you want .
> >
> > Some details on how to reproduce with a small sample would be helpful.
> > Memory dumps tend to be quite large and contain confidential
> > information, so we prefer to not exchange those on the list.
> >
> > Jon
> >
> > On Mon, Feb 10, 2020 at 5:10 PM COURTAULT Francois <
> > francois.courta...@thalesgroup.com> wrote:
> >
> > > Hello everyone,
> > >
> > > We have 2 microservices: one using TomEE Plus and the other using
> > > TomEE
> > MP.
> > > These 2 µS don't use at all OpenTracing features: no @Trace 
> > > We have no memory issue with the µS using TomEE Plus. This is
> > > strange because TomEE Plus  somehow is a superset of TomEE MP.
> > >
> > > The issue is due to the usage of
> > > org.apache.geronimo.microprofile.opentracing.impl.ScopeImpl but we
> > > don't know what trigger that usage.
> > > We also see a lot of org.apache.tomcat.util.threads.TaskThread
> > > (don't know where it comes from) which uses the above ScopeImpl.
> > >
> > > I can provide you some memory dumps if you want .
> > >
> > > Is there a way to disable opentracing in TomEE MP ?
> > >
> > > Best Regards.
> > >
> > >
> > >
> > >
> >
>

Re: TomEE microprofile memory consumption

[Jonathan Gallimore]

Allow me start over, if I may.

What are you seeing in your memory dumps that's a concern - a large number
of ScopeImpl objects? Could you provide some screenshots from VisualVM for
us? I'd be interested in object counts, and whether there are references,
and if so, what they are.

The TaskThread comes from Tomcat. It being present doesn't sound like an
issue, but I appreciate you've asked because you have some concern - can
you provide some more context?

> You didn't answer to this question: Is there a way to disable opentracing
in TomEE MP ? Is it possible ?

Its a setting in the Geronimo OpenTracing project:
https://github.com/apache/geronimo-opentracing. Try
setting geronimo.opentracing.filter.active to false (an entry in
conf/system.properties should do the trick).

Jon

On Mon, Feb 10, 2020 at 6:46 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> Quite complex for us what you ask for.
>
> BTW, have you any idea about this
> org.apache.tomcat.util.threads.TaskThread in the memory dump we have.
> Where could it come from ?
>
> You didn't answer to this question: Is there a way to disable opentracing
> in TomEE MP ? Is it possible ?
>
> Best Regards.
>
> -----Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: lundi 10 février 2020 18:21
> To: users@tomee.apache.org
> Subject: Re: TomEE microprofile memory consumption
>
> > I can provide you some memory dumps if you want .
>
> Some details on how to reproduce with a small sample would be helpful.
> Memory dumps tend to be quite large and contain confidential information,
> so we prefer to not exchange those on the list.
>
> Jon
>
> On Mon, Feb 10, 2020 at 5:10 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello everyone,
> >
> > We have 2 microservices: one using TomEE Plus and the other using TomEE
> MP.
> > These 2 µS don't use at all OpenTracing features: no @Trace 
> > We have no memory issue with the µS using TomEE Plus. This is strange
> > because TomEE Plus  somehow is a superset of TomEE MP.
> >
> > The issue is due to the usage of
> > org.apache.geronimo.microprofile.opentracing.impl.ScopeImpl but we
> > don't know what trigger that usage.
> > We also see a lot of org.apache.tomcat.util.threads.TaskThread (don't
> > know where it comes from) which uses the above ScopeImpl.
> >
> > I can provide you some memory dumps if you want .
> >
> > Is there a way to disable opentracing in TomEE MP ?
> >
> > Best Regards.
> >
> >
> >
> >
>

Re: TomEE microprofile memory consumption

[Jonathan Gallimore]

> I can provide you some memory dumps if you want .

Some details on how to reproduce with a small sample would be helpful.
Memory dumps tend to be quite large and contain confidential information,
so we prefer to not exchange those on the list.

Jon

On Mon, Feb 10, 2020 at 5:10 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> We have 2 microservices: one using TomEE Plus and the other using TomEE MP.
> These 2 µS don't use at all OpenTracing features: no @Trace 
> We have no memory issue with the µS using TomEE Plus. This is strange
> because TomEE Plus  somehow is a superset of TomEE MP.
>
> The issue is due to the usage of
> org.apache.geronimo.microprofile.opentracing.impl.ScopeImpl but we don't
> know what trigger that usage.
> We also see a lot of org.apache.tomcat.util.threads.TaskThread (don't know
> where it comes from) which uses the above ScopeImpl.
>
> I can provide you some memory dumps if you want .
>
> Is there a way to disable opentracing in TomEE MP ?
>
> Best Regards.
>
>
>
>

Re: TOMEE-2770

[Jonathan Gallimore]

There was some work done in this area between TomEE 8.0.0 and 8.0.1, so if
you haven't yet tried 8.0.1, please do. In terms of what you're seeing, am
I correct in thinking that if you invoke a business method on an EJB with
this code may times:

*jmsContext*.createProducer().send(*messageQueue*, *jmsContext*
.createTextMessage(*"Test"*));

in a heap dump you see a number of producers that aren't being cleared up?

Jon

On Mon, Feb 10, 2020 at 8:20 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> Could you look at https://issues.apache.org/jira/browse/TOMEE-2770 please
> ?
> This is blocking for us :(
>
> Best Regards.
>
>
>
>

Re: ActiveMQ latest release in TomEE

[Jonathan Gallimore]

Yes. I think we had some crossover with the vote period for 8.0.1 and the
release of ActiveMQ 5.15.11.

Jon

On Thu, Feb 6, 2020 at 8:24 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> In TomEE 8.0.1 Plus, ActiveMQ 5.15.10 is included. Do you plan to
> integrate ActiveMQ 5.15.11 at least (5.16.0 currently in dev) in the next
> TomEE release ?
>
> Best Regards.
>
>
>
>
>

Re: Docker images for 8.0.0

[Jonathan Gallimore]

On Mon, Jan 20, 2020 at 11:54 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> If I have well understood: TomEE 9 will manage the latest MP (eg 3.2 or
> superior), right ? When the master branch will become the 9 version ?
>

I don't know the timings on that yet.


> Regarding TomEE 8, will you provide us a MP 2.2 (latest 2.x MP version)
> version ?
>

I have a fairly long to-do list, but if I can work on it, I will. I don't
know how trivial it will be. This is a good contribution point for anyone
wanting to join in.

Jon

Re: Docker images for 8.0.0

[Jonathan Gallimore]

On Mon, Jan 20, 2020 at 11:07 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> As MP is quite important for us, what is the MP compliancy new version ?
> 2.2 ? 3.x?
>

Its 2.1. This is mostly bugfixes from TomEE 8.0.0.


> I  guess it should be 2.2. The 3.x compliancy should be targeted in TomEE
> 8.1.x branch, right ?
> Has this branch ever started ?
>

There's no 8.1.x branch at present. We're more likely to see master get
branched to create an 8.0 release branch, and master become TomEE 9, and
I'd expect that to target Jakarta EE 9 and the latest MicroProfile version.

Having just gone through the pain of doing 3 simultaneous releases for 3
different branches, I would not be in favour of maintaining more branches,
but that's just my personal view. If there's desire for more branches, that
can be discussed - it should probably have its own thread rather than
picking up on this one (regarding Docker images).

Jon

Re: Docker images for 8.0.0

[Jonathan Gallimore]

8.0.1 is being release today having just passed a vote, so I'm anticipating
Rod / Carl and other will be looking to get a Docker image for that done
fairly quickly. I'll take a look at the problem with the GitHub project you
mention. Thanks for pointing that out.

Jon

On Mon, Jan 20, 2020 at 8:53 AM Tobias Erdle  wrote:

> Hi again,
>
> just wanted to ask if there are any updates on this topic, as I'm still
> not able to file an issue in the GitHub repo (although the README links
> to them, but they are disabled) and there aren't updates on Dockerhub.
>
> Would be great to get some answer ;)
>
> Thanks and best regards,
>
> Tobias Erdle
>
> --
> Tobias Erdle
>
> e-mail: tobi.er...@gmail.com
>
>

Re: Cannot connect MDB to IBM MQ queue via destinationLookup

[Jonathan Gallimore]

I'll dig out the app I had working with Websphere MQ and get back to you
later today. Apologies for missing the previous message.

Jon

On Fri, Jan 17, 2020 at 4:00 PM ptie  wrote:

> Anybody?
>
> Thanks!
> Peter
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: CXF CVE-2019-17573 and CVE-2019-12423

[Jonathan Gallimore]

I've applied the change to the master branch. Hopefully the CI won't flag
up any issues. I will double check, but I don't think we expose a /services
page, or a JWK keys service, so unless you're specifically doing something
with CXF in TomEE to use these features, they shouldn't present an issue
out of the box. If someone knows different, please let us know.

If the current votes pass, we'll release as is, and kick off another
release to pick up the update. If they fail, we'll re-roll, and this will
be included. Does that sound reasonable?

Jon

On Thu, Jan 16, 2020 at 2:36 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> It is too late, as the current VOTEs were posted before this was
> announced, and I've been trying to get this release out for over a month.
>
> That being said, I would be prepared to roll a subsequent release in
> fairly short order afterwards in order to pick this up. Ideally I'd like to
> try and release more frequently (like monthly), but if the process takes
> multiple weeks, that's unlikely to happen.
>
> We still need 1 more binding +1 on the existing votes, so I'd encourage
> PMC members to cast a vote.
>
> Jon
>
> On Thu, Jan 16, 2020 at 2:18 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
>> Hello TomEE guys,
>>
>> If it's not too late before releasing next TomEE version, could you take
>> into account the CXF team advice to migrate from 3.3.x to 3.3.5 ?
>> Current TomEE 8.0.0 release uses CXF 3.3.2.
>>
>> Best Regards.
>>
>

Re: CXF CVE-2019-17573 and CVE-2019-12423

[Jonathan Gallimore]

It is too late, as the current VOTEs were posted before this was announced,
and I've been trying to get this release out for over a month.

That being said, I would be prepared to roll a subsequent release in fairly
short order afterwards in order to pick this up. Ideally I'd like to try
and release more frequently (like monthly), but if the process takes
multiple weeks, that's unlikely to happen.

We still need 1 more binding +1 on the existing votes, so I'd encourage PMC
members to cast a vote.

Jon

On Thu, Jan 16, 2020 at 2:18 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello TomEE guys,
>
> If it's not too late before releasing next TomEE version, could you take
> into account the CXF team advice to migrate from 3.3.x to 3.3.5 ?
> Current TomEE 8.0.0 release uses CXF 3.3.2.
>
> Best Regards.
>

Re: Trouble loading custom resource within WAR embedded within EAR

[Jonathan Gallimore]

How are you using that resource - are you using @Resource or a JNDI lookup
or similar?

Thanks

Jon

On Mon, Jan 6, 2020 at 2:32 PM ptie  wrote:

> Anybody?
>
> Regards,
> Peter
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

Hi Paul

Thanks for your feedback, that's great news. FYI, TomEE 8.0.1 is up for
vote (feel free to vote on it!), and this change is included.

Cheers

Jon

On Fri, Dec 20, 2019 at 7:10 AM Paul Carter-Brown
 wrote:

> Hi Jon
>
> Latest snapshot worked a charm. Old gen went from 500MB to 110MB after
> deploy completed. Thanks so much
>
> On Tue, 17 Dec 2019, 11:33 Paul Carter-Brown, 
> wrote:
>
>> Thanks Jon.
>>
>> I'm away at the moment but will give it a spin in the next few days and
>> let you know. Thanks again
>>
>> On Mon, 16 Dec 2019, 22:53 Jonathan Gallimore, <
>> jonathan.gallim...@gmail.com> wrote:
>>
>>> Hi Paul
>>>
>>> I've pushed a new snapshot which (hopefully) should address this. The CI
>>> build is running on it now. Would you mind giving it a try? If it looks
>>> good, I'll finish rolling the release. Fingers crossed it looks ok for you.
>>>
>>> Jon
>>>
>>> On Mon, Dec 16, 2019 at 2:48 PM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>>
>>>> Further update - I think my changes work with respect to this issue,
>>>> but I do have a bunch of unit test failures which I need to look into. For
>>>> info, here's the diff:
>>>>
>>>> diff --git
>>>> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
>>>> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
>>>> index a6e2bdc4f5..c0d1a8c98f 100644
>>>> ---
>>>> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
>>>> +++
>>>> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
>>>> @@ -69,10 +69,7 @@ import org.apache.openejb.cdi.ThreadSingletonService;
>>>>  import org.apache.openejb.classloader.ClassLoaderConfigurer;
>>>>  import org.apache.openejb.classloader.CompositeClassLoaderConfigurer;
>>>>  import org.apache.openejb.component.ClassLoaderEnricher;
>>>> -import org.apache.openejb.config.ConfigurationFactory;
>>>> -import org.apache.openejb.config.NewLoaderLogic;
>>>> -import org.apache.openejb.config.QuickJarsTxtParser;
>>>> -import org.apache.openejb.config.TldScanner;
>>>> +import org.apache.openejb.config.*;
>>>>  import org.apache.openejb.core.ConnectorReference;
>>>>  import org.apache.openejb.core.CoreContainerSystem;
>>>>  import org.apache.openejb.core.CoreUserTransaction;
>>>> @@ -829,6 +826,14 @@ public class Assembler extends AssemblerTool
>>>> implements org.apache.openejb.spi.A
>>>>
>>>>  final AppContext appContext = new
>>>> AppContext(appInfo.appId, SystemInstance.get(), classLoader,
>>>> globalJndiContext, appJndiContext, appInfo.standaloneModule);
>>>>  appContext.getProperties().putAll(appInfo.properties);
>>>> +
>>>> +final Set keys =
>>>> appContext.getProperties().keySet();
>>>> +for (final Object key : keys) {
>>>> +if (! Module.class.isInstance(key)) {
>>>> +appContext.getProperties().remove(key);
>>>> +}
>>>> +}
>>>> +
>>>>  appContext.getInjections().addAll(injections);
>>>>  appContext.getBindings().putAll(globalBindings);
>>>>  appContext.getBindings().putAll(appBindings);
>>>> diff --git
>>>> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
>>>> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
>>>> index feff954d40..aed0fda941 100644
>>>> ---
>>>> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
>>>> +++
>>>> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
>>>> @@ -384,12 +384,7 @@ public class JndiEncBuilder {
>>>>  reference = new LinkRef(jndiName);
>>>>
>>>>  } else if (BeanManager.class.equals(type)) {
>>>> -reference = new LazyObjectReference(new
>>>> Callable() {
>>>> -@Override
>>>&g

Re: Configuring Quartz under TomEE

[Jonathan Gallimore]

TomEE uses Quartz internally to schedule EJB timers etc - the reason for
shading it is to avoid it conflicting with Quartz packaged in your
application. So theoretically, you should be able to package Quartz in your
application, and use it per its own documentation. If you have a code
sample with your issue that you can provide us with, we'd be happy to take
a look.

Cheers

Jon

On Fri, Dec 20, 2019 at 4:13 AM Ihsan Ecemis  wrote:

>
> Hello Everyone,
>
> We would like to store Quartz scheduling information within a relational
> database. We tried different configuration options to use our own
> properties file instead of TomEE's default, but could not get it to work.
>
> Here are the things we tried:
>
> (1) We defined the system property 'org.quartz.properties', e.g. did
> "-Dorg.quartz.properties=/tmp/quartz.properties".
> (2) Since TomEE shades org.quartz, we also tried
> "-Dorg.apache.openejb.quartz.properties=/tmp/quartz.properties".
> (3) We also tried configuring this via web.xml file by adding:
>
>   
> quartz:config-file
> /tmp/quartz.properties
>   
>
>
> In all these cases, even though we set org.quartz.jobStore.class =
> org.quartz.impl.jdbcjobstore.JobStoreTX (or
> org.apache.openejb.quartz.jobStore.class =
> org.apache.openejb.quartz.impl.jdbcjobstore.JobStoreTX) and adjust all
> parameters as documented at Quartz User Guide,  TomEE is initializing
> RAMJobStore instead of JobStoreTX.  Also, there is no indication in the
> logs that Quartz is opening our properties file.
>
> How can we configure Quartz under TomEE?
>
> Any help would be greatly appreaciated.
>
> Thanks,
>
> Ihsan.

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

Hi Paul

I've pushed a new snapshot which (hopefully) should address this. The CI
build is running on it now. Would you mind giving it a try? If it looks
good, I'll finish rolling the release. Fingers crossed it looks ok for you.

Jon

On Mon, Dec 16, 2019 at 2:48 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Further update - I think my changes work with respect to this issue, but I
> do have a bunch of unit test failures which I need to look into. For info,
> here's the diff:
>
> diff --git
> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
> index a6e2bdc4f5..c0d1a8c98f 100644
> ---
> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
> +++
> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/Assembler.java
> @@ -69,10 +69,7 @@ import org.apache.openejb.cdi.ThreadSingletonService;
>  import org.apache.openejb.classloader.ClassLoaderConfigurer;
>  import org.apache.openejb.classloader.CompositeClassLoaderConfigurer;
>  import org.apache.openejb.component.ClassLoaderEnricher;
> -import org.apache.openejb.config.ConfigurationFactory;
> -import org.apache.openejb.config.NewLoaderLogic;
> -import org.apache.openejb.config.QuickJarsTxtParser;
> -import org.apache.openejb.config.TldScanner;
> +import org.apache.openejb.config.*;
>  import org.apache.openejb.core.ConnectorReference;
>  import org.apache.openejb.core.CoreContainerSystem;
>  import org.apache.openejb.core.CoreUserTransaction;
> @@ -829,6 +826,14 @@ public class Assembler extends AssemblerTool
> implements org.apache.openejb.spi.A
>
>  final AppContext appContext = new
> AppContext(appInfo.appId, SystemInstance.get(), classLoader,
> globalJndiContext, appJndiContext, appInfo.standaloneModule);
>  appContext.getProperties().putAll(appInfo.properties);
> +
> +final Set keys =
> appContext.getProperties().keySet();
> +for (final Object key : keys) {
> +if (! Module.class.isInstance(key)) {
> +appContext.getProperties().remove(key);
> +}
> +}
> +
>  appContext.getInjections().addAll(injections);
>  appContext.getBindings().putAll(globalBindings);
>  appContext.getBindings().putAll(appBindings);
> diff --git
> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
> index feff954d40..aed0fda941 100644
> ---
> a/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
> +++
> b/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JndiEncBuilder.java
> @@ -384,12 +384,7 @@ public class JndiEncBuilder {
>  reference = new LinkRef(jndiName);
>
>  } else if (BeanManager.class.equals(type)) {
> -reference = new LazyObjectReference(new
> Callable() {
> -@Override
> -public BeanManager call() throws Exception {
> -return new
> InjectableBeanManager(WebBeansContext.currentInstance().getBeanManagerImpl());
> -}
> -});
> +reference = new LazyObjectReference<>(new
> BeanManagerLazyReference());
>
>  } else if (UserTransaction.class.equals(type)) {
>  reference = new
> IntraVmJndiReference("comp/UserTransaction");
> @@ -684,4 +679,11 @@ public class JndiEncBuilder {
>  }
>  }
>  }
> +
> +public static class BeanManagerLazyReference implements
> Callable {
> +@Override
> +public BeanManager call() throws Exception {
> +return new
> InjectableBeanManager(WebBeansContext.currentInstance().getBeanManagerImpl());
> +}
> +}
>  }
> diff --git
> a/container/openejb-core/src/main/java/org/apache/openejb/core/TempClassLoader.java
> b/container/openejb-core/src/main/java/org/apache/openejb/core/TempClassLoader.java
> index 2cf387e112..285007925f 100644
> ---
> a/container/openejb-core/src/main/java/org/apache/openejb/core/TempClassLoader.java
> +++
> b/container/openejb-core/src/main/java/org/apache/openejb/core/TempClassLoader.java
> @@ -59,6 +59,7 @@ public class TempClassLoader extends URLClassLoader {
>  private final ClassLoader system;
>  private final boolean embedded;
>  private final boolean p

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

/ WebModule from the SuperProperties on
AppContext. This is set when deploying through the apps folder and lives
forever. It has the TempClassLoader attached, and therefore all the
AnnotationFinder stuff.

I suspect (2) is too aggressive and is causing the test failures, but will
confirm.

Jon

On Mon, Dec 16, 2019 at 11:27 AM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Thanks for sending those over. I'm digging through this - I *think* I have
> pinned down a specific reference that stops that classloader from being
> released. The behaviour for a war/ear deployed in apps/ seems different to
> deploying in webapps/ - I'm assuming that's what you're doing. If you can
> confirm, that would help. I'll test out a patch with some bigger .ear files
> today.
>
> Thanks
>
> Jon
>
> On Thu, Dec 12, 2019 at 9:08 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> The mailing list seems to be stripping off your images - can you resend
>> and include my email address as well? I'd be keen to dig into this a little
>> more.
>>
>> Thanks
>>
>> Jon
>>
>> On Thu, Dec 12, 2019 at 9:00 PM Paul Carter-Brown
>>  wrote:
>>
>>> Hi,
>>>
>>> The code does seem to use org.apache.openejb.core.TempClassLoader. I can
>>> see one instance in the heap for every war in my ear. + 1.
>>>
>>> The TempClassLoader however still has 100's of strong references to it.
>>> E.g:
>>>
>>> [image: image.png]
>>>
>>> [image: image.png]
>>>
>>>
>>> Paul Carter-Brown
>>> Director
>>> Jini Guru
>>> m: +27 (0) 83 442 7179 <+27834427179>
>>> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>>>   Johannesburg, South Africa
>>> w: jini.guru  e: p...@jini.guru
>>>
>>> Disclaimer: This message and/or attachment(s) may contain
>>> privileged, confidential and/or personal information. If you are not the
>>> intended recipient you may not disclose or distribute any of
>>> the information contained within this message. In such case you must
>>> destroy this message and inform the sender of the error. Jini Guru may not
>>> accept liability for any errors, omissions, information and viruses
>>> contained in the transmission of this message. Any opinions, conclusions
>>> and other information contained within this message not related to Jini
>>> Guru official business is deemed to be that of the individual only and is
>>> not endorsed by Jini Guru.
>>>
>>>
>>>
>>> On Thu, Dec 12, 2019 at 9:29 AM Mark Struberg 
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> All this is just a workaround imo.
>>>>
>>>> Afair we (Romain) introduced a temporary throw-away ClassLoader for
>>>> scanning. That means after doing all the class scans we only keep the
>>>> extracted information but do not keep the Classes in memory. Doesn't this
>>>> work anymore?
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> > Am 12.12.2019 um 00:45 schrieb Paul Carter-Brown
>>>> :
>>>> >
>>>> > FYI. Graph of the change in heap size on a prod instance after this
>>>> change:
>>>> >
>>>> >
>>>> > Paul Carter-Brown
>>>> > Director
>>>> > Jini Guru
>>>> > m:+27 (0) 83 442 7179
>>>> > a:1st Floor, Golf House, Design Quarter, Cnr. William Nicol and
>>>> Leslie
>>>> >   Johannesburg, South Africa
>>>> > w:jini.guru  e: p...@jini.guru
>>>> >
>>>> > Disclaimer: This message and/or attachment(s) may contain privileged,
>>>> confidential and/or personal information. If you are not the intended
>>>> recipient you may not disclose or distribute any of the information
>>>> contained within this message. In such case you must destroy this message
>>>> and inform the sender of the error. Jini Guru may not accept liability for
>>>> any errors, omissions, information and viruses contained in the
>>>> transmission of this message. Any opinions, conclusions and other
>>>> information contained within this message not related to Jini Guru official
>>>> business is deemed to be that of the individual only and is not endorsed by
>>>> Jini Guru.
>>>> >
>>>> >
>>>> >

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

Thanks for sending those over. I'm digging through this - I *think* I have
pinned down a specific reference that stops that classloader from being
released. The behaviour for a war/ear deployed in apps/ seems different to
deploying in webapps/ - I'm assuming that's what you're doing. If you can
confirm, that would help. I'll test out a patch with some bigger .ear files
today.

Thanks

Jon

On Thu, Dec 12, 2019 at 9:08 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> The mailing list seems to be stripping off your images - can you resend
> and include my email address as well? I'd be keen to dig into this a little
> more.
>
> Thanks
>
> Jon
>
> On Thu, Dec 12, 2019 at 9:00 PM Paul Carter-Brown
>  wrote:
>
>> Hi,
>>
>> The code does seem to use org.apache.openejb.core.TempClassLoader. I can
>> see one instance in the heap for every war in my ear. + 1.
>>
>> The TempClassLoader however still has 100's of strong references to it.
>> E.g:
>>
>> [image: image.png]
>>
>> [image: image.png]
>>
>>
>> Paul Carter-Brown
>> Director
>> Jini Guru
>> m: +27 (0) 83 442 7179 <+27834427179>
>> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>>   Johannesburg, South Africa
>> w: jini.guru  e: p...@jini.guru
>>
>> Disclaimer: This message and/or attachment(s) may contain
>> privileged, confidential and/or personal information. If you are not the
>> intended recipient you may not disclose or distribute any of
>> the information contained within this message. In such case you must
>> destroy this message and inform the sender of the error. Jini Guru may not
>> accept liability for any errors, omissions, information and viruses
>> contained in the transmission of this message. Any opinions, conclusions
>> and other information contained within this message not related to Jini
>> Guru official business is deemed to be that of the individual only and is
>> not endorsed by Jini Guru.
>>
>>
>>
>> On Thu, Dec 12, 2019 at 9:29 AM Mark Struberg 
>> wrote:
>>
>>> Hi!
>>>
>>> All this is just a workaround imo.
>>>
>>> Afair we (Romain) introduced a temporary throw-away ClassLoader for
>>> scanning. That means after doing all the class scans we only keep the
>>> extracted information but do not keep the Classes in memory. Doesn't this
>>> work anymore?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> > Am 12.12.2019 um 00:45 schrieb Paul Carter-Brown
>>> :
>>> >
>>> > FYI. Graph of the change in heap size on a prod instance after this
>>> change:
>>> >
>>> >
>>> > Paul Carter-Brown
>>> > Director
>>> > Jini Guru
>>> > m:+27 (0) 83 442 7179
>>> > a:1st Floor, Golf House, Design Quarter, Cnr. William Nicol and
>>> Leslie
>>> >   Johannesburg, South Africa
>>> > w:jini.guru  e: p...@jini.guru
>>> >
>>> > Disclaimer: This message and/or attachment(s) may contain privileged,
>>> confidential and/or personal information. If you are not the intended
>>> recipient you may not disclose or distribute any of the information
>>> contained within this message. In such case you must destroy this message
>>> and inform the sender of the error. Jini Guru may not accept liability for
>>> any errors, omissions, information and viruses contained in the
>>> transmission of this message. Any opinions, conclusions and other
>>> information contained within this message not related to Jini Guru official
>>> business is deemed to be that of the individual only and is not endorsed by
>>> Jini Guru.
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Dec 12, 2019 at 1:17 AM Paul Carter-Brown
>>>  wrote:
>>> > Hi Jon,
>>> >
>>> > I took a look at the source and worked out that I could add my own
>>> filters using openejb.additional.exclude.
>>> >
>>> > I set it to openejb.additional.exclude=com,net,io,org and the JVM heap
>>> now sits at around 150MB whereas it would never go below 450MB previously!!!
>>> >
>>> > Our EJB's and code is all in jars prefixed with guru.jini and hence
>>> they are not filtered out and the system works 100%.
>>> >
>>> > My sense is that there should be an easier way to specify what jars
>>> and/or packages to process for annotations. I have come a

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

sdb
>> > org.asynchttpclient
>> > org.apache
>> > org.aspectj
>> >
>> > But then maybe some are too broad and I don't really understand what
>> the annotation index/cache is really needed for at runtime? Can it not be
>> lazy loaded or discarded if unused? Just thinking out loud here :-( Seems
>> like the cache uses a significant amount of heap when considering the drive
>> towards tiny micro services.
>> >
>> > Paul Carter-Brown
>> > Director
>> > Jini Guru
>> > m:+27 (0) 83 442 7179
>> > a:1st Floor, Golf House, Design Quarter, Cnr. William Nicol and
>> Leslie
>> >   Johannesburg, South Africa
>> > w:jini.guru  e: p...@jini.guru
>> >
>> > Disclaimer: This message and/or attachment(s) may contain privileged,
>> confidential and/or personal information. If you are not the intended
>> recipient you may not disclose or distribute any of the information
>> contained within this message. In such case you must destroy this message
>> and inform the sender of the error. Jini Guru may not accept liability for
>> any errors, omissions, information and viruses contained in the
>> transmission of this message. Any opinions, conclusions and other
>> information contained within this message not related to Jini Guru official
>> business is deemed to be that of the individual only and is not endorsed by
>> Jini Guru.
>> >
>> >
>> >
>> >
>> > On Wed, Dec 11, 2019 at 7:18 PM Paul Carter-Brown
>>  wrote:
>> > Hi Jon,
>> >
>> > Unfortunately the snapshot behaves exactly the same way
>> >
>> > Paul Carter-Brown
>> > Director
>> > Jini Guru
>> > m:+27 (0) 83 442 7179
>> > a:1st Floor, Golf House, Design Quarter, Cnr. William Nicol and
>> Leslie
>> >   Johannesburg, South Africa
>> > w:jini.guru  e: p...@jini.guru
>> >
>> > Disclaimer: This message and/or attachment(s) may contain privileged,
>> confidential and/or personal information. If you are not the intended
>> recipient you may not disclose or distribute any of the information
>> contained within this message. In such case you must destroy this message
>> and inform the sender of the error. Jini Guru may not accept liability for
>> any errors, omissions, information and viruses contained in the
>> transmission of this message. Any opinions, conclusions and other
>> information contained within this message not related to Jini Guru official
>> business is deemed to be that of the individual only and is not endorsed by
>> Jini Guru.
>> >
>> >
>> >
>> >
>> > On Wed, Dec 11, 2019 at 3:39 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>> > Hi Paul
>> >
>> > Would you mind trying your application with a recent snapshot?
>> >
>> https://repository.apache.org/content/repositories/snapshots/org/apache/tomee/apache-tomee/8.0.1-SNAPSHOT/
>> .
>> > I recently updated the exclude list.
>> >
>> > Many thanks
>> >
>> > Jon
>> >
>> > On Wed, Dec 11, 2019 at 12:31 PM Paul Carter-Brown
>> >  wrote:
>> >
>> > > Hi,
>> > >
>> > > I've been trying to lower the memory footprint of an EAR deployed to
>> TomEE
>> > > 8.0.0.
>> > >
>> > > Here is a screenshot of the heap histogram. The total Old Gen is about
>> > > 450MB (after forcing multiple GC's). If I boot TomEE without my EAR
>> then
>> > > the old gen is about 6MB.
>> > >
>> > > [image: Screenshot from 2019-12-11 12-53-12.png]
>> > >
>> > > The entire ear is 140MB zip, most of which is in the ears /lib
>> directory
>> > > which contains libs such as Kafka, hazelcast, apache POI, Google cloud
>> > > APIs, AWS client APIs etc etc. In total our code has about 100 actual
>> > > EJB's. If i remove files from the lib folder in the ear then I can
>> see that
>> > > the memory used by the annotation finder is lowered.
>> > >
>> > > Is there any way I can tell TomEE that it need not bother scanning
>> > > everything in the /lib folder of my EAR for annotations and fulling
>> up the
>> > > heap. I already
>> > > set openejb.deployments.classpath.include=.*jg-arch-core-impl.* to
>> scan
>> > > only the one jar in /lib which does have EJB's in it and it seems to
>> obey
>> > > this property but it doesn't seem to mean that annotation processing
>> is
>> > > skipped for all these other jars in /lib
>> > >
>> > > Thanks!
>> > >
>> > > Paul Carter-Brown
>> > > Director
>> > > Jini Guru
>> > > m: +27 (0) 83 442 7179 <+27834427179>
>> > > a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and
>> Leslie
>> > >   Johannesburg, South Africa
>> > > w: jini.guru  e: p...@jini.guru
>> > >
>> > > Disclaimer: This message and/or attachment(s) may contain
>> > > privileged, confidential and/or personal information. If you are not
>> the
>> > > intended recipient you may not disclose or distribute any of
>> > > the information contained within this message. In such case you must
>> > > destroy this message and inform the sender of the error. Jini Guru
>> may not
>> > > accept liability for any errors, omissions, information and viruses
>> > > contained in the transmission of this message. Any opinions,
>> conclusions
>> > > and other information contained within this message not related to
>> Jini
>> > > Guru official business is deemed to be that of the individual only
>> and is
>> > > not endorsed by Jini Guru.
>> > >
>> > >
>>
>>

Re: Old Gen Full of Annotation Finder Index

[Jonathan Gallimore]

Hi Paul

Would you mind trying your application with a recent snapshot?
https://repository.apache.org/content/repositories/snapshots/org/apache/tomee/apache-tomee/8.0.1-SNAPSHOT/.
I recently updated the exclude list.

Many thanks

Jon

On Wed, Dec 11, 2019 at 12:31 PM Paul Carter-Brown
 wrote:

> Hi,
>
> I've been trying to lower the memory footprint of an EAR deployed to TomEE
> 8.0.0.
>
> Here is a screenshot of the heap histogram. The total Old Gen is about
> 450MB (after forcing multiple GC's). If I boot TomEE without my EAR then
> the old gen is about 6MB.
>
> [image: Screenshot from 2019-12-11 12-53-12.png]
>
> The entire ear is 140MB zip, most of which is in the ears /lib directory
> which contains libs such as Kafka, hazelcast, apache POI, Google cloud
> APIs, AWS client APIs etc etc. In total our code has about 100 actual
> EJB's. If i remove files from the lib folder in the ear then I can see that
> the memory used by the annotation finder is lowered.
>
> Is there any way I can tell TomEE that it need not bother scanning
> everything in the /lib folder of my EAR for annotations and fulling up the
> heap. I already
> set openejb.deployments.classpath.include=.*jg-arch-core-impl.* to scan
> only the one jar in /lib which does have EJB's in it and it seems to obey
> this property but it doesn't seem to mean that annotation processing is
> skipped for all these other jars in /lib
>
> Thanks!
>
> Paul Carter-Brown
> Director
> Jini Guru
> m: +27 (0) 83 442 7179 <+27834427179>
> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>   Johannesburg, South Africa
> w: jini.guru  e: p...@jini.guru
>
> Disclaimer: This message and/or attachment(s) may contain
> privileged, confidential and/or personal information. If you are not the
> intended recipient you may not disclose or distribute any of
> the information contained within this message. In such case you must
> destroy this message and inform the sender of the error. Jini Guru may not
> accept liability for any errors, omissions, information and viruses
> contained in the transmission of this message. Any opinions, conclusions
> and other information contained within this message not related to Jini
> Guru official business is deemed to be that of the individual only and is
> not endorsed by Jini Guru.
>
>

Re: Issue with TomEE 8 on Open JDK 11

[Jonathan Gallimore]

Woohoo!

Thanks for the follow up. I'll post about kicking off some releases as soon
as I can.

Jon

On Wed, Dec 4, 2019 at 4:25 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> Tried with the TomEE microprofile 8.0.1 December, the 3rd snapshot and it
> works 
> Good job :-)
>
> Best Regards.
>
> -----Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mercredi 4 décembre 2019 16:31
> To: users@tomee.apache.org
> Cc: d...@tomee.apache.org
> Subject: Re: Issue with TomEE 8 on Open JDK 11
>
> This was the fix:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomee%2Fpull%2F610data=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7Cb26d4f16b48849400b2f08d778cf0759%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C637110702882103846sdata=iRnRAOElU0tnDgvifPy7t8xjjebcyG6uXZvr2uTfU7A%3Dreserved=0
>
> I published snapshots here:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Fgroups%2Fsnapshots%2Forg%2Fapache%2Ftomee%2Fapache-tomee%2F8.0.1-SNAPSHOT%2Fdata=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7Cb26d4f16b48849400b2f08d778cf0759%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C637110702882113841sdata=9l6y%2BWj6b56nvH02ZpzZJX2JGpD2q6bFUKFP3TjMe%2Bk%3Dreserved=0
> yesterday
> (check the file dates for 3rd December 2019). If you could pick one of
> those up and verify, that would be amazing.
>
> Release-wise - I think we're overdue. I'll try and carve out some time to
> get those up for a vote.
>
> Jon
>
> On Wed, Dec 4, 2019 at 3:24 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello Jonathan,
> >
> > No. I didn't try with a recent snapshot. Could you provide me some
> > details about how do you have fixed that, please ?
> > TomEE 8.0.1, close to be released  ?
> >
> > Best Regards.
> >
> > -Original Message-
> > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> > Sent: mercredi 4 décembre 2019 16:17
> > To: users@tomee.apache.org
> > Cc: d...@tomee.apache.org
> > Subject: Re: Issue with TomEE 8 on Open JDK 11
> >
> > I believe its already been fixed. Could you try a recent snapshot?
> >
> > Thanks
> >
> > Jon
> >
> > On Wed, Dec 4, 2019 at 3:14 PM COURTAULT Francois <
> > francois.courta...@thalesgroup.com> wrote:
> >
> > > Hello everyone,
> > >
> > >
> > >
> > > We deployed an application which uses JAXB on TomEE Plus 8.0.0 using
> > > openjdk 11 and have no issue.
> > >
> > >
> > >
> > > Then I deployed the same application on TomEE Microprofile 8.0.0
> > > using openjdk 11. In this case, the TomEE start failed.
> > >
> > > I got:
> > >
> > > java.lang.IllegalStateException: Error starting child … Caused by:
> > > org.apache.catalina.LifecycleException: Failed to start component
> > > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
> > > …
> > > Caused by: *java.lang.NoClassDefFoundError*: Could not initialize
> > > class
> > > *com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl*
> > >
> > >
> > >
> > > I think I have identified the issue: using TomEE Plus, I have in the
> > > lib
> > > folder: jakarta.activation-1.2.1.jar and jaxb-runtime-2.3.2.jar  so
> > > probably loaded by the same class loader and had no issue.
> > >
> > > When I deployed the same application in TomEE mircroprofile, I have
> > > only in the lib folder:  jaxb-runtime-2.3.2.jar, the
> > > jakarta.activation-1.2.1.jar is missing.
> > >
> > > The workaround I have found is to include in the WEB-INF/lib folder
> > > of my
> > > application:  jaxb-impl-2.3.2.jar (roughly same content  than
> > > jaxb-runtime-2.3.2.jar), activation-1.1.1.jar (same class loader ?)
> > >
> > >
> > >
> > > Do you think that in the TomEE microprofile flavor,
> > > jakarta.activation-1.2.1.jar should be added in lib folder ?
> > >
> > > Is it a bug ? if yes, do I have to submit a ticket for that ?
> > >
> > >
> > >
> > > Best Regards.
> > >
> > >
> > >
> > >
> > >
> > > [image: Thales]
> > >
> > > *François Courtault*
> > > *SOFTWARE ARCHITECT*
> > > Tel.: +33 4 42 36 66 06
> > >
> > > Gemalto is now part of the Thales Group.
&

Re: Issue with TomEE 8 on Open JDK 11

[Jonathan Gallimore]

This was the fix: https://github.com/apache/tomee/pull/610

I published snapshots here:
https://repository.apache.org/content/groups/snapshots/org/apache/tomee/apache-tomee/8.0.1-SNAPSHOT/
yesterday
(check the file dates for 3rd December 2019). If you could pick one of
those up and verify, that would be amazing.

Release-wise - I think we're overdue. I'll try and carve out some time to
get those up for a vote.

Jon

On Wed, Dec 4, 2019 at 3:24 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> No. I didn't try with a recent snapshot. Could you provide me some details
> about how do you have fixed that, please ?
> TomEE 8.0.1, close to be released  ?
>
> Best Regards.
>
> -----Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mercredi 4 décembre 2019 16:17
> To: users@tomee.apache.org
> Cc: d...@tomee.apache.org
> Subject: Re: Issue with TomEE 8 on Open JDK 11
>
> I believe its already been fixed. Could you try a recent snapshot?
>
> Thanks
>
> Jon
>
> On Wed, Dec 4, 2019 at 3:14 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello everyone,
> >
> >
> >
> > We deployed an application which uses JAXB on TomEE Plus 8.0.0 using
> > openjdk 11 and have no issue.
> >
> >
> >
> > Then I deployed the same application on TomEE Microprofile 8.0.0 using
> > openjdk 11. In this case, the TomEE start failed.
> >
> > I got:
> >
> > java.lang.IllegalStateException: Error starting child … Caused by:
> > org.apache.catalina.LifecycleException: Failed to start component
> > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
> > …
> > Caused by: *java.lang.NoClassDefFoundError*: Could not initialize
> > class
> > *com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl*
> >
> >
> >
> > I think I have identified the issue: using TomEE Plus, I have in the
> > lib
> > folder: jakarta.activation-1.2.1.jar and jaxb-runtime-2.3.2.jar  so
> > probably loaded by the same class loader and had no issue.
> >
> > When I deployed the same application in TomEE mircroprofile, I have
> > only in the lib folder:  jaxb-runtime-2.3.2.jar, the
> > jakarta.activation-1.2.1.jar is missing.
> >
> > The workaround I have found is to include in the WEB-INF/lib folder of
> > my
> > application:  jaxb-impl-2.3.2.jar (roughly same content  than
> > jaxb-runtime-2.3.2.jar), activation-1.1.1.jar (same class loader ?)
> >
> >
> >
> > Do you think that in the TomEE microprofile flavor,
> > jakarta.activation-1.2.1.jar should be added in lib folder ?
> >
> > Is it a bug ? if yes, do I have to submit a ticket for that ?
> >
> >
> >
> > Best Regards.
> >
> >
> >
> >
> >
> > [image: Thales]
> >
> > *François Courtault*
> > *SOFTWARE ARCHITECT*
> > Tel.: +33 4 42 36 66 06
> >
> > Gemalto is now part of the Thales Group.
> > Please note that my new email address is
> > francois.courta...@thalesgroup.com
> >
> >
> >
> > *THALES*
> >
> > Avenue du Jujubier La Vigie
> >
> > Z.I. Athélia IV
> >
> > 13705 La Ciotat
> >
> > https://eur01.safelinks.protection.outlook.com/?url=www.thalesgroup.co
> > mdata=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7C1af618068fda4f
> > 15e3f908d778cd18dd%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C637110
> > 694591649694sdata=cspsK3CGE6uqnULPToNhzPYteuFJ3KOTJX%2B8WofbCxQ%3
> > Dreserved=0
> >
> > [image:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintra
> > net.peopleonline.corp.thales%2Fportal%2Foutlook%2Fsignature%2Fico_link
> > edin.pngdata=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7C1af6180
> > 68fda4f15e3f908d778cd18dd%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7
> > C637110694591649694sdata=9ErmyVmF4xDackm8CKi5M4TpLTTV6KQym3mJc8x2
> > cUI%3Dreserved=0]
> > <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> > linkedin.com%2Fcompany%2Fthalesdata=02%7C01%7CFrancois.COURTAULT%
> > 40gemalto.com%7C1af618068fda4f15e3f908d778cd18dd%7C37d0a9db7c464096bfe
> > 31add5b495d6d%7C0%7C0%7C637110694591659692sdata=KG4gw4PW6FeJhOqXi
> > jQyM7IfS%2F2wHp79Jj%2Fk8UX6sXo%3Dreserved=0>
> >
> > [image:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintra
> > net.peopleonline.corp.thales%2Fportal%2Foutlook%2Fsignature%2Fico_twit
> > ter.pngdata=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7C1af61806
>

Re: Issue with TomEE 8 on Open JDK 11

[Jonathan Gallimore]

I believe its already been fixed. Could you try a recent snapshot?

Thanks

Jon

On Wed, Dec 4, 2019 at 3:14 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
>
>
> We deployed an application which uses JAXB on TomEE Plus 8.0.0 using
> openjdk 11 and have no issue.
>
>
>
> Then I deployed the same application on TomEE Microprofile 8.0.0 using
> openjdk 11. In this case, the TomEE start failed.
>
> I got:
>
> java.lang.IllegalStateException: Error starting child
> …
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
> …
> Caused by: *java.lang.NoClassDefFoundError*: Could not initialize class
> *com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl*
>
>
>
> I think I have identified the issue: using TomEE Plus, I have in the lib
> folder: jakarta.activation-1.2.1.jar and jaxb-runtime-2.3.2.jar  so
> probably loaded by the same class loader and had no issue.
>
> When I deployed the same application in TomEE mircroprofile, I have only
> in the lib folder:  jaxb-runtime-2.3.2.jar, the
> jakarta.activation-1.2.1.jar is missing.
>
> The workaround I have found is to include in the WEB-INF/lib folder of my
> application:  jaxb-impl-2.3.2.jar (roughly same content  than
> jaxb-runtime-2.3.2.jar), activation-1.1.1.jar (same class loader ?)
>
>
>
> Do you think that in the TomEE microprofile flavor,
> jakarta.activation-1.2.1.jar should be added in lib folder ?
>
> Is it a bug ? if yes, do I have to submit a ticket for that ?
>
>
>
> Best Regards.
>
>
>
>
>
> [image: Thales]
>
> *François Courtault*
> *SOFTWARE ARCHITECT*
> Tel.: +33 4 42 36 66 06
>
> Gemalto is now part of the Thales Group.
> Please note that my new email address is
> francois.courta...@thalesgroup.com
>
>
>
> *THALES*
>
> Avenue du Jujubier La Vigie
>
> Z.I. Athélia IV
>
> 13705 La Ciotat
>
> www.thalesgroup.com
>
> [image:
> http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_linkedin.png]
> 
>
> [image:
> http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_twitter.png]
> 
>
> [image:
> http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_fb.png]
> 
>
> [image:
> http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_youtube.png]
> 
>
>
>
>
>
>
>
>
> --
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: Supplying a JDBC password at run-time.

[Jonathan Gallimore]

Glad you have it working. The other approach you could take is to implement
a custom password cipher:
https://tomee.apache.org/latest/examples/datasource-ciphered-password.html or
a properties provider:
https://tomee.apache.org/latest/docs/admin/configuration/resources.html which
you might be able to hook up to your password store. Here's a sample
properties provider in a unit test, if that helps.
https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/PropertiesProviderTest.java#L90-L103

The DataSourceFactory is a little complex, but in general the properties
part of the system is quite flexible. The defaults for different resources
come from service-jar.xml in openejb-core, and are overridden by tomee.xml
or WEB-INF/resources.xml, and in turn, overridden by system properties.
Then you have ciphering, properties providers and class factories in the
mix as well, so there's a bunch of of different ways you can do it.

Couple of points to be wary of - specifying JVM args would potentially mean
the password is exposed on the command line, and visible to someone doing a
`ps`. Your System.err.println() may write the plain text password to a log,
depending on where stderr is routed to. Also, no matter how you get the
password to TomEE, if the server is compromised and an attacker is able to
get a heap dump, they'll be able to get your database password, so nothing
is perfect.

Anyway, glad you got something working, and thanks for following up. If you
have any questions around config, please let us know.

Jon

On Tue, Dec 3, 2019 at 8:06 PM randygalbraith 
wrote:

> Hi Dmitry & Richard,
>
> Thank you for all your help! Here is my anonymized source for what worked
> :-)
>
> DataSourceFactory.java:
>
> package path1.path2;
>
> import java.io.IOException;
> import path3.path4.FooStore;
>
>
> public class DataSourceFactory {
>
> public Object create() {
>
> String password = null;
>
> try {
> password = FooStore.getPassword("user", "db");
> } catch (Exception e) {
> System.err.println(e.toString());
> return null;
>
> }
> String definition = "JdbcDriver=oracle.jdbc.OracleDriver\n" +
> "JdbcUrl=jdbc:oracle:thin:@host:port:db\n" +
> "JtaManaged=true\n" +
> "UserName=user\n" +
> "Password=" + password + "\n";
> System.err.println("definition=["+definition+"]");
> try {
> return org.apache.openejb.resource.jdbc.DataSourceFactory.
> create("someDS", true, oracle.jdbc.OracleDriver.class,
>definition, null, null, null, false);
> } catch (IllegalAccessException iae) {
> System.err.println(iae.toString());
> return null;
> } catch (InstantiationException ie) {
> System.err.println(ie.toString());
> return null;
> } catch (IOException ioe) {
> System.err.println(ioe.toString());
> return null;
> }
>}
> }
>
> resources.xml:
>
> 
> 
>type="javax.sql.DataSource"
>   class-name="path1.path2.DataSourceFactory"
>   factory-name="create">
>   JdbcDriver = oracle.jdbc.OracleDriver
> 
> 
>
> build.xml updates:
> +
> +
>
> Cheers, -Randy
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: tomee and jdk14

[Jonathan Gallimore]

That's awesome, thank you!

On Fri, Nov 22, 2019 at 2:51 PM cocorossello  wrote:

> Hi,
>
> I have created the JIRA ticket, I will do the patch this weekend.
>
> https://issues.apache.org/jira/browse/TOMEE-2744
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: tomee and jdk14

[Jonathan Gallimore]

> Is it ok? Care for a PR with this patch?

A big yes please! Thank you for catching this!

Jon

On Thu, Nov 21, 2019 at 11:10 AM cocorossello 
wrote:

> Hi,
>
> Just for curiosity, I tried tomee with jdk14 (upgrading xbean). I found
> that
> the java.security.acl package is removed from jdk14
> (https://bugs.openjdk.java.net/browse/JDK-8191138  ) and
> java.security.acl.Group is referenced in AbstractSecurityService (I don't
> know if it is used somewhere else).
>
> I've tried to patch it making AbstractSecurityService implement Principal
> instead of java.security.acl.Group and everything works, at least in my
> environment, but I don't know about other setups.
>
> Is it ok? Care for a PR with this patch?
>
> Best regards,
> Vicente.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: TomEE GraalVM native image

[Jonathan Gallimore]

If we're to roll an 8.0.1 any day now, its unlikely it'll have a
MicroProfile update, as there's a number of dependencies that get pulled in
for that functionality. We can release as often as we want/can, and there's
definitely changes since 8.0.0 that we need to get released, so I wouldn't
hold up 8.0.1 for MicroProfile updates, when we can release an 8.0.2 as
soon as those changes are in.

For clarification, I don't set the roadmap for the community. For me,
Jakarta EE 8 compliance is the priority. If others wish to work on GraalVM
or other functionality in parallel, that is cool with me. An unfortunate
reality, however, is that if everything has the same priority, effectively
you have no priorities. The danger is you'll wait longer for any of it to
show up. If GraalVM native images is your priority, I would strongly
encourage you to contribute to that work.

Jon

On Thu, Nov 14, 2019 at 8:25 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> I would also consider, as the same priority level than Jakarta EE 8
> compliancy, Micro Profile compliancy.
> I hope that TomEE 8.0.1 will be MP 2.2... and TomEE 8.1.x MP 3.x (3.2
> specification has just been released - 3 days ago)
>
> Is it also the roadmap you or the community have in mind ?
>
> Best Regards.
>
> -----Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mercredi 13 novembre 2019 15:25
> To: users@tomee.apache.org
> Cc: d...@tomee.apache.org
> Subject: Re: TomEE GraalVM native image
>
> > I think it should be a quite important topic to consider in the
> > roadmap,
> right ?
>
> I agree its cool. What's the community take on the priority? Personally,
> I'd consider getting Jakarta EE 8 done the highest priority, behind bugs
> and security updates. I'm currently trying to finish one bug, and review 2
> PRs before getting a release out, and then I'll hopefully be back to
> Jakarta EE 8.
>
> If others want to work on GraalVM native images for TomEE, that's great
> and contributions are welcome. I'll keep plugging away at Jakarta EE 8.
>
> Jon
>
> On Wed, Nov 13, 2019 at 11:35 AM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello everyone,
> >
> > I am able to see some initiatives around GraalVM native-image like
> > Quarkus, Helidon,...
> > I have also seen that Tomcat 9.0.26 could be built as a native image:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomca
> > t.apache.org%2Ftomcat-9.0-doc%2Fgraal.htmldata=02%7C01%7CFrancois
> > .COURTAULT%40gemalto.com%7Cc1b6794714b74a427c3008d76846c01a%7C37d0a9db
> > 7c464096bfe31add5b495d6d%7C0%7C0%7C637092525391905126sdata=RFGUmu
> > KXLWAczYRvF24TmQkiIA%2BOWh%2F86K9tCTdRXjo%3Dreserved=0
> >
> > Digging on the web, I discover some work on TomEE side as well:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftomitribe%2Fgraalvm-microprofiledata=02%7C01%7CFrancois.
> > COURTAULT%40gemalto.com%7Cc1b6794714b74a427c3008d76846c01a%7C37d0a9db7
> > c464096bfe31add5b495d6d%7C0%7C0%7C637092525391905126sdata=2uu3%2F
> > I5b0uyFefJ3iwUN2oPs4eT%2FV0APZwb52MEoGk0%3Dreserved=0
> >
> > Are you working on a TomEE version which can be built as a GraalVM
> > native image ?
> > I think it should be a quite important topic to consider in the
> > roadmap, right ?
> >
> > Best Regards.
> >
> >
> >
> > 
> > This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: TomEE GraalVM native image

[Jonathan Gallimore]

> I think it should be a quite important topic to consider in the roadmap,
right ?

I agree its cool. What's the community take on the priority? Personally,
I'd consider getting Jakarta EE 8 done the highest priority, behind bugs
and security updates. I'm currently trying to finish one bug, and review 2
PRs before getting a release out, and then I'll hopefully be back to
Jakarta EE 8.

If others want to work on GraalVM native images for TomEE, that's great and
contributions are welcome. I'll keep plugging away at Jakarta EE 8.

Jon

On Wed, Nov 13, 2019 at 11:35 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> I am able to see some initiatives around GraalVM native-image like
> Quarkus, Helidon,...
> I have also seen that Tomcat 9.0.26 could be built as a native image:
> http://tomcat.apache.org/tomcat-9.0-doc/graal.html
>
> Digging on the web, I discover some work on TomEE side as well:
> https://github.com/tomitribe/graalvm-microprofile
>
> Are you working on a TomEE version which can be built as a GraalVM native
> image ?
> I think it should be a quite important topic to consider in the roadmap,
> right ?
>
> Best Regards.
>
>
>
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: TomEE and Arquillian

[Jonathan Gallimore]

You should be able to specify it using the "classifier" property in
arquillian.xml:

http://www.w3.org/2001/XMLSchema-instance;>
  

  plus
  -1
  -1
  
  ${tomee.version}
  target/apache-tomee-remote
  target/arquillian-test-working-dir

  


Let us know how you get on!

Jon

On Tue, Nov 12, 2019 at 11:30 AM Makarov Alexey  wrote:

> Hello!
> I use "TomEE 8 plus", and I want to write integration tests.
> I wrote small test and set some config in pom.xml. When I start tests and
> look at console I see:
> "INFO: Downloading org.apache.tomee:apache-tomee:8.0.0:zip:webprofile
> please wait...",- my maven download webprofile, I use ActiveMQ and as far
> as I understand, I need plus or plume profile. How I can do this?
>
> My pom.xml:
>
> 
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> ru.ritos
> ritos-backend
> 1.0-SNAPSHOT
> war
>
> ritos-backend
>
> 
> ${project.build.directory}/endorsed
> UTF-8
> 1.9.1
> 8.0.0
> plus
> 
>
> 
> 
> 
> org.apache.deltaspike.distribution
> distributions-bom
> ${deltaspike.version}
> pom
> import
> 
> 
> org.jboss.arquillian
> arquillian-bom
> 1.5.0.Final
> import
> pom
> 
> 
> 
>
> 
> 
> redis.clients
> jedis
> 3.1.0
> 
> 
> commons-codec
> commons-codec
> 1.13
> 
> 
> org.apache.commons
> commons-lang3
> 3.9
> 
> 
> org.apache.httpcomponents
> httpclient
> 4.5.10
> 
> 
> org.postgresql
> postgresql
> 42.2.8
> 
> 
> javax
> javaee-api
> 8.0
> provided
> 
> 
> org.apache.deltaspike.core
> deltaspike-core-api
> compile
> 
> 
> org.apache.deltaspike.core
> deltaspike-core-impl
> runtime
> 
> 
> org.apache.deltaspike.modules
> deltaspike-security-module-api
> compile
> 
> 
> org.apache.deltaspike.modules
> deltaspike-security-module-impl
> runtime
> 
> 
> 
> org.hibernate
> hibernate-entitymanager
> 5.3.13.Final
> 
>
> 
> com.vladmihalcea
> hibernate-types-52
> 2.7.1
> 
> 
> 
> org.junit.jupiter
> junit-jupiter-engine
> 5.5.2
> test
> 
> 
> org.jboss.weld
> weld-junit5
> 2.0.1.Final
> test
> 
> 
> org.mockito
> mockito-core
> 3.1.0
> test
> 
> 
>
> 
>
> 
> junit
> junit
> 4.12
> test
> 
>
> 
> org.jboss.arquillian.junit
> arquillian-junit-container
> 1.5.0.Final
> test
> 
>
> 
> org.apache.tomee
> arquillian-tomee-remote
> ${tomee.version}
> test
> 
>
> 
> org.apache.tomee
> apache-tomee
> ${tomee.version}
> plus
> zip
> test
> 
>
> 
> org.jboss.shrinkwrap.resolver
> shrinkwrap-resolver-depchain
> 3.1.3
> test
> pom
> 
>
> 
>
> 
> 
> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
> 
> 1.8
> 1.8
> 
> ${endorsed.dir}
> 
> true
> 
> 
> 
> org.apache.maven.plugins
> maven-war-plugin
> 2.3
> 
> false
> 
> 
> 
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.6
> 
> 
> validate
> 
> copy
> 
> 
>
> 

Re: Tomcat with drop-in tomee.war is missing from 8.0 release

[Jonathan Gallimore]

What version of Tomcat do you have? I'm working through a couple of issues
with a view to starting a release shortly.

Jon

On Mon, Nov 11, 2019 at 4:44 PM African Wild Dog 
wrote:

> Em seg., 11 de nov. de 2019 às 11:29, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> escreveu:
>
> > Hi Richard
> >
> > African Wild Dog is looking for the drop-in war.
>
>
> That's it. I am evaluating Tomee for a new Project. I thought the "drop-in
> war installation" was a good idea since the my Tomcat installation is
> automatically updated by debian.
>

Re: Tomcat with drop-in tomee.war is missing from 8.0 release

[Jonathan Gallimore]

Hi Richard

African Wild Dog is looking for the drop-in war. If you're not familiar
with this, in the very early days of TomEE, we used to ship a .war file
which you could deploy to a vanilla Tomcat to create TomEE. We didn't ship
it for 8.0.0 as it appeared to have some issues.

If people are willing to test it, and -perhaps more importantly-, vote on
it at release time, I see no reason why we can't bring it back. The
artifacts are still created in the build if anyone wants to give it a try.

Jon

On Sun, Nov 10, 2019 at 3:42 PM Richard Monson-Haefel <
monsonhae...@gmail.com> wrote:

> Hi African Wild Dog,
>
> I think we are miscommunicating. Can you re-phrase your original request?
>
> Thank you!
>
> Richard
>
> On Sat, Nov 9, 2019 at 10:45 AM African Wild Dog 
> wrote:
>
> > Hi Richard,
> >
> > Thanks for the reply.
> >
> > There is no download option for "drop-in war installation" for the
> 8.0.0.0
> > version: https://tomee.apache.org/download-ng.html
> >
> >
> > Em seg., 4 de nov. de 2019 às 14:42, Richard Monson-Haefel <
> > monsonhae...@gmail.com> escreveu:
> >
> > > I'm pretty sure that if you simply drop the WAR in it will be unpacked
> > and
> > > loaded.
> > >
> > > Check out the section titled "Deploy a WAR in TomEE" in this article
> > > https://www.tomitribe.com/blog/getting-started-with-tomee/
> > >
> > > On Wed, Oct 30, 2019 at 12:22 PM African Wild Dog <
> > paintedlyc...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello firends.
> > > >
> > > > Is there any plans to add "drop-in war installation" for TomEE 8.0?
> > > >
> > > > The doc page  Installing TomEE using the drop-in .war approach
> > > > <
> http://tomee.apache.org/tomee-8.0/docs/installation-drop-in-war.html>
> > > >  is
> > > > outdated.
> > > >
> > > > Regards
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from:
> > > > http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
> > > >
> > >
> > >
> > > --
> > > Richard Monson-Haefel
> > > https://twitter.com/rmonson
> > > https://www.linkedin.com/in/monsonhaefel/
> > >
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: TomEE - 8.0.0 - Release notes?

[Jonathan Gallimore]

Correct. We're missing some of the lesser used, older full profile specs.
We're not intending to certify the full profile, although the plus and
plume distributions do ship with things like connectors and JMS which work
well.

Jon

On Sun, Nov 10, 2019 at 3:41 PM Richard Monson-Haefel <
monsonhae...@gmail.com> wrote:

> The Web Profile, I believe.
>
> On Sat, Nov 9, 2019 at 10:54 AM African Wild Dog 
> wrote:
>
> > Thanks Richard.
> >
> > Is the full compliance aimed for the web profile or full profile?
> >
> > Em seg., 4 de nov. de 2019 às 14:38, Richard Monson-Haefel <
> > monsonhae...@gmail.com> escreveu:
> >
> > > Hi African Wild Dog (love that handle!):
> > >
> > > The release notes can be found here:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12344635
> > >
> > > We are working steadily on TomEE's conformance to Jakarta EE 8. TomEE
> > > passes more than 94% of the compliance tests and we hope to have full
> > > compliance soon.  We are working on getting TCK results to the
> community
> > so
> > > that people know exactly which tests are failing and can help fix them.
> > >
> > > I hope that helps!
> > >
> > > Richard
> > >
> > >
> > > On Wed, Oct 30, 2019 at 12:07 PM African Wild Dog <
> > paintedlyc...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Is there any release notes of the version 8.0.0?
> > > >
> > > > I would like to know what are the compliance with Java EE 8.
> > > >
> > > > Regards
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from:
> > > > http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
> > > >
> > >
> > >
> > > --
> > > Richard Monson-Haefel
> > > https://twitter.com/rmonson
> > > https://www.linkedin.com/in/monsonhaefel/
> > >
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Fatal error at TomEE(apache-tomee-plume-8.0.0-M3)

[Jonathan Gallimore]

Did you have any luck with this one? I'm still happy to take a look if
you're still having trouble.

Thanks

Jon

On Thu, Oct 24, 2019 at 2:31 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Can you let us know your WebsphereMQ version and your tomee.xml (with
> sensitive information like passwords removed)?
>
> I've had success with Websphere MQ in the past with TomEE, so I'm sure we
> can get you going.
>
> Jon
>
> On Thu, 24 Oct 2019, 14:09 Puttonen Sami (EXT), <
> ext-sami.putto...@traficom.fi> wrote:
>
>> Hi everyone,
>>
>> have anyone get this kind of error when trying to create resources to IBM
>> MQ and where is that class? I have try load those all needed jars from IBM,
>> but.
>>
>> 24-Oct-2019 09:45:52.180 SEVERE [main]
>> org.apache.openejb.util.OpenEJBErrorHandler.handleUnknownError FATAL ERROR:
>> Unknown error in Assembler.  Please send the following stack trace and this
>> message to users@tomee.apache.org :
>> org.apache.xbean.recipe.ConstructionException: Type class could not be
>> found: com.ibm.mq.connector.ResourceAdapterImpl
>> at
>> org.apache.xbean.recipe.ObjectRecipe.getType(ObjectRecipe.java:358)
>> at
>> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:269)
>> at
>> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
>> at
>> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
>> at
>> org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:3158)
>> at
>> org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2993)
>> at
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:592)
>> at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:493)
>> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:150)
>> at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
>> at
>> org.apache.tomee.catalina.TomcatLoader.initialize(TomcatLoader.java:245)
>> at
>> org.apache.tomee.catalina.ServerListener.lifecycleEvent(ServerListener.java:169)
>> at
>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
>> at
>> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:137)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:584)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:304)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>>
>> Cheers, Sami
>>
>

Re: Is there a way to control the max number of requests in the queue ?

[Jonathan Gallimore]

> So, in a scenario where the number of concurrent requests exceeds this
value, the requests are queued, right ?

I don't know if that's correct. I'd have to dig into the Tomcat code and
check (I'd probably want to test it as well).

> new request is rejected with a 503 status code

The server would have to accept (process) the request in order to return a
response code.

What I've normally seen is people put a load balancer or proxy in front of
Tomcat / TomEE. If that proxy isn't able to get a connection accepted, it
would try another node (if there is one), or the proxy itself would return
a 503.

I'll try and find some time to double-check for you, but the use-case
sounds unusual to me - accepting requests and putting them in a queue in a
busy/overloaded system doesn't sound like a good way to get the best
throughput.

If you have a sample config and test case, that would help.

Jon

On Thu, Oct 24, 2019 at 8:21 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> Any suggestion/answer regarding the questions I asked ?
>
> Best Regards.
>
> From: COURTAULT Francois
> Sent: jeudi 17 octobre 2019 15:44
> To: users@tomee.apache.org
> Subject: Is there a way to control the max number of requests in the queue
> ?
>
> Hello everyone,
>
> In TomEE/Tomcat, there is a way to control the max number of parallel
> requests by setting maxThreads attribute value in Executor.
>
> So, in a scenario where the number of concurrent requests exceeds this
> value, the requests are queued, right ?
> Is there a way to control the size of this queue so that if the number of
> requests (the ones in // plus we reach the max size of this queue),  any
> new request is rejected with a 503 status code ?
>
> Best Regards.
>
>
>
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: Activating CDI creates classloader leak in tomee/tomcat

[Jonathan Gallimore]

Hi

Just to confirm, I can reproduce your issue. Digging into it some more in
VisualVM.

Jon

On Sun, Oct 20, 2019 at 12:17 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Sorry, I had a couple of critical issues at work this week. This is next
> on my list to look at.
>
> Jon
>
> On Sun, 20 Oct 2019, 11:00 makkus,  wrote:
>
>> No news on this?
>> It looks to be a some problem in openebj? Is nobody else experiencing
>> class
>> leaks with TomEE 8? If I investigate the orphaned  if find this:
>> <
>> http://tomee-openejb.979440.n4.nabble.com/file/t376354/webappLoader_cgRoot.png>
>>
>> Any ideas what is happening here?
>>
>>
>>
>> --
>> Sent from:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>>
>

Re: Re: CDI Principal injection: object is not an instance of declaring class

[Jonathan Gallimore]

I responded to your other email - I'll take a look at the classes leaking
on reload later today. Thank you for reporting it, I'll let you know what
I find.

Jon

On Tue, Oct 15, 2019 at 1:38 PM makkus  wrote:

> Hi Richard,
>
> basically I might give it a try at some point, but currently I am a little
> bit under pressure and still heavily figthing the the classloader leaks
> TomEE produces
> (
> http://tomee-openejb.979440.n4.nabble.com/Activating-CDI-creates-classloader-leak-in-tomee-tomcat-tp4690835.html)
>
> - it seems impossible (even with a minimalistic app) to not leak classes on
> reload, so I start considering wether I need to move to some other
> container.
>
> Marcus
>
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Activating CDI creates classloader leak in tomee/tomcat

[Jonathan Gallimore]

Thanks for reporting this, along with the sample, the very clear steps for
reproducing the issue, and the analysis. I'll take a look at this later
today - hopefully we can track this down and fix it without too much
trouble.

Jon

On Mon, Oct 14, 2019 at 9:00 AM makkus  wrote:

> Hi folks,
>
> by tracing down a classloader leak in my webapp I realized, that leaks are
> actually created by activating CDI via adding the "beans.xml" into WEB-INF
> (TomEE plume 8.0.0-M2 and TomEE plume 8.0.0).
> To reproduce, I have created a minimalistic jsf enabled webapp consiting of
> onyl a simple ServletContextListener (called leaktest.AppContextListener).
> Feel free to download the test war archive here:
> https://1drv.ms/u/s!AlHB9FAlFWW_iLJjPO5NAk77apcO4g?e=gjFDoY
>
> When reloading the application inside tomcat multiple times and stopping
> it,
> for each load one leaktest.AppContextListener class reference can be found
> in the heapdump classes
> 
>
> When renaming "beans.xml" into something invalid like "_beans.xml" the
> classloader leak disappears, only a single leaktest.AppContextListener
> class
> can be found in the heapdump after the app is stopped. Tomcats leak
> detection button confirms this observation. Without CDI enabled (i.e.
> invalid "_beans.xml") the leak message inside the manager app lists only a
> single line (even with repreated reloads). With CDI enabled (valid
> beans.xml) for each reload an new line is added in the leak message window
> of the tomcat web application manager.
>
> Can anybody confirm this? Or has anyone successfully deployed a
> non-classloader-leaking CDI enabled webapp to TomEE?
>
> Regards,
> Marcus
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

The follow up is appreciated - we hadn't touched upon any of the
asynchronous parts of Kalyan's questions, so any pointers you're able to
give are appreciated. The hanging threads appear to be fixed in 8.0.0.

Jon

On Mon, Oct 14, 2019 at 10:46 AM Richard Monson-Haefel <
monsonhae...@gmail.com> wrote:

> Please ignore my previous email. I didn't see that Jon had already helped
> with this. Good luck!
>
> On Mon, Oct 14, 2019 at 4:45 AM Richard Monson-Haefel <
> monsonhae...@gmail.com> wrote:
>
> > Hi Kalyan,
> >
> > Are you using the @Asnycrhous annotation?  If so, that's probably why you
> > are seeing messages for the AsynchronousPool.  I found this article which
> > helps explain asynchronous EJBs
> >
> > https://www.tomitribe.com/blog/asynchronous-ejbs-on-tomee/
> >
> > It mentions the max pool size is set, as a default of 5.  As does this
> > article:
> >
> >
> https://tomee.apache.org/latest/docs/admin/configuration/application.html
> >
> > Have you tried to set that max pool size property to a higher number?  If
> > you can determine from logs the average number of invocations per second
> at
> > peak periods you could use that as a guide for setting the async pool
> > size.  If that's not possible try a couple different max pool sizes (e.g.
> > 20, 50, 100) and see if that helps. I don't think - although I'm not sure
> > about this - that setting the max pool size higher is going to effect
> > performance much but I'm not sure about that.
> >
> > Richard
> >
> > On Thu, Oct 3, 2019 at 3:16 PM Kalyan  wrote:
> >
> >> Hello,
> >> I am getting following error in my application.
> >>
> >> avax.ejb.ConcurrentAccessTimeoutException: No instances available in
> >> Stateless Session Bean pool.  Waited 30 SECONDS
> >> at
> >>
> >>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:226)
> >> at
> >>
> >>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
> >> at
> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> >> at
> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> >> at
> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> >> at
> >>
> >>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349)
> >>
> >>
> >>
> >> My application is heavily used. Looks like not enough instances of
> beans.
> >>
> >> I saw this post to increase the pool size
> >>
> >> https://tomee.apache.org/admin/configuration/containers.html
> >>
> >>
> >> and changed my configuration as
> >>
> >>
> java.naming.factory.initial=org.apache.openejb.core.LocalInitialContextFactory
> >> openejb.deployments.classpath.ear=false
> >>
> >> myApp = new://Container?type=STATELESS
> >> myApp.AccessTimeout = 30 seconds
> >> *myApp.MaxSize = 40*
> >> myApp.MinSize = 0
> >> myApp.StrictPooling = true
> >> myApp.MaxAge = 0 hours
> >> myApp.ReplaceAged = true
> >> myApp.ReplaceFlushed = false
> >> myApp.MaxAgeOffset = -1
> >> myApp.IdleTimeout = 0 minutes
> >> myApp.GarbageCollection = false
> >> myApp.SweepInterval = 5 minutes
> >> myApp.CallbackThreads = 5
> >> myApp.CloseTimeout = 5 minutes
> >> myApp.UseOneSchedulerThreadByBean = false
> >> myApp.EvictionThreads = 1
> >>
> >>
> >> On the server start up I see
> >>
> >> INFO - Configuring Service(id=myApp, type=Container, provider-id=Default
> >> Stateless Container)
> >>
> >> DEBUG - Containers: 1
> >> DEBUG - TypeContainer ID
> >> DEBUG -STATELESS   myApp
> >> DEBUG - Deployments   : 5
> >> DEBUG - TypeDeployment ID
> >>
> >> /Question i have is /
> >> How would i know if the bean size is increased ?  I don't see any log
> >> message for it.
> >>
> >> /Secondly I also see /
> >>
> >> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
> values
> >> are: none, annotations, enums, all or NONE or ALL
> >> DEBUG - Using default 'AsynchronousPool.Size=5'
> >> DEBUG - Using default 'AsynchronousPool.CorePoolSize=5'
> >> DEBUG - Using default 'AsynchronousPool.MaximumPoolSize=5'
> >> DEBUG - Using default 'AsynchronousPool.QueueSize=5'
> >> DEBUG - Using default 'AsynchronousPool.KeepAliveTime=60 SECONDS'
> >> DEBUG - Using default 'AsynchronousPool.AllowCoreThreadTimeOut=true'
> >> DEBUG - Using default 'AsynchronousPool.QueueType=linked'.  Possible
> >> values
> >> are: array, linked, priority, synchronous
> >> DEBUG - Using default 'AsynchronousPool.OfferTimeout=30 SECONDS'
> >> DEBUG - Using default 'AsynchronousPool.ShutdownWaitDuration=1 MINUTES'
> >>
> >>
> >> What's the AsynchronousPool ???
> >>
> >>
> >> Please help me to sort this issue?
> >> I'm running into this issues in production.
> >>
> >>
> >>
> >> thanks
> >> Kalyan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Sent from:
> >> 

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

Setting MaxTotal, InitialSize, MinIdle, and MaxIdle enable you to control
whether and when the pool will grow or shrink -
http://commons.apache.org/proper/commons-dbcp/configuration.html.

I'd avoid the urge to change more parameters if you can as it adds more
variables. It looks like a code change between 8.0.0-M3 and 8.0.0 makes the
difference. I'd be interested to know what change impacts it. If you had
time to do a git bisect, that would be useful to close the loop.

Jon



On Wed, Oct 9, 2019 at 11:56 PM Kalyan  wrote:

> Hi Jon,
>
> With 8.0.0 version. I don't see any ConcurrentAccessTimeoutException
> happening.
> I ran tests for few mins and works fine.
>
> One more question
>
> I was just going through
>  http://commons.apache.org/proper/commons-dbcp/configuration.html
>
> Do you think its require to set MaxIdle for the database connections ?
> does it have to be same as MaxTotal ?
>
> Please advice.
>
> Thanks a lot for the help.
>
> Regards
> Kalyan
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Problem with MessageConsumers under TomEE 8.0.0

[Jonathan Gallimore]

That's interesting. We'll see if we can create some test cases for these
different scenarios.

Jon

On Thu, Oct 10, 2019 at 4:55 PM Ihsan Ecemis  wrote:

>
> Sorry I just had time to make these experiments.
>
> Having the following (setting transacted = false) did not fix the problem
> if we do not use try-with-resources:
>
> final Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
>
>
> On the other hand, when we added transactionSupport=none to resources.xml,
> we could dequeue only 1 message, which is weird  (at each server restart,
> we dequeue 1 message even though there are more message in the queue.
> Reverting the code back to try-with-resources  makes the server dequeue all
> the messages)
>
>
> Hope that would help you guys find out where the problem is.
>
>
>
> > On Oct 1, 2019, at 16:42, Jonathan S. Fisher  wrote:
> >
> > Just curious, try this:
> >
> > final Session session = connection.createSession(false,
> > Session.AUTO_ACKNOWLEDGE);
> >
> > and/or try this:
> >
> > 
> >ResourceAdapter  = MyJmsResourceAdapter
> > transactionSupport=none
> >
> >
> >
> >
> >
> > On Mon, Sep 30, 2019 at 8:53 PM Ihsan Ecemis  wrote:
> >
> >>
> >> Thanks for digging into this Jon  (and pointing my attention toward that
> >> other paragraph in the Javadoc)
> >>
> >> And I highly appreciated the try-with-resources workaround.
> >>
> >>
> >>> On Sep 30, 2019, at 17:11, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>>
> >>>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
> >>> states the following:  There is no need to close the sessions,
> producers,
> >>> and consumers of a closed connection.
> >>>
> >>>> Here is the link:
> >>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close--
> <
> >>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close--
> >
> >>>
> >>> Good question. The changes in this area between 8.0.0-M3 and 8.0.0,
> are,
> >>> you'll be unsurprised to find out, around transaction handling. We need
> >> to
> >>> dig in a bit further.
> >>>
> >>> The Javadoc also states this: "Closing a connection causes any of its
> >>> sessions' transactions in progress to be rolled back. In the case
> where a
> >>> session's work is coordinated by an external transaction manager, a
> >>> session's commit and rollback methods are not used and the result of a
> >>> closed session's work is determined later by the transaction manager.
> >>> Closing a connection does NOT force an acknowledgment of
> >>> client-acknowledged sessions."
> >>>
> >>> A lot of this describes standalone usage, as opposed to usage in an
> >>> application server. The Connection object should actually be a proxy,
> and
> >>> calling close() shouldn't actually do anything. The sendMessage()
> method
> >> on
> >>> the CustomJmsService bean is transactional, and the connection should
> be
> >>> returned back to the pool once the method completes and the transaction
> >> is
> >>> committed.
> >>>
> >>> Thank you for the sample code, we should be able to debug through and
> see
> >>> what's going on. I should be able to do this over the next day - I'll
> >> post
> >>> my steps here in case you want to dig in and have a go yourself.
> >>>
> >>> Jon
> >>>
> >>> On Mon, Sep 30, 2019 at 6:32 PM Ihsan Ecemis 
> wrote:
> >>>
> >>>>
> >>>> Thank you very much for your suggestion Jon,  adding
> >>>> connection.createSession(), session.createProducer(), and
> >>>> session.createConsumer() in the try-with-resources block  make things
> >> work
> >>>> again!
> >>>>
> >>>>
> >>>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
> >>>> states the following:  There is no need to close the sessions,
> >> producers,
> >>>> and consumers of a closed connection.
> >>>>
> >>>> Here is the link:
> >>>>
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close--
> >> <
> >>>>
> https://docs.oracle.com/java

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

Can you give it a shot with the 8.0.0 (final) version?
https://repo1.maven.org/maven2/org/apache/tomee/openejb-core/8.0.0/openejb-core-8.0.0.jar
.

Also, try the patch, but with the debug logging for OpenEJB.resource.jdbc
off.

My change should only be introducing logging, so maybe there is something
else in the mix. It's good news that you can reproduce with a load test.

Thanks

Jon

On Wed, Oct 9, 2019 at 8:11 PM Kalyan  wrote:

> Hello Jon,
> I just put your code BasicManagedDataSource and tested with some load
> test.
> I don't see any ConcurrentAccessTimeoutException.
>
>
> Below is log
>
> 2019-10-09 18:56:40,815 DEBUG (JungoThreadPool-1-198-T642) close() -
> active:
> 5. Called from java.lang.Throwable
>
>
> But if i put back the old openejb-core-8.0.0-M3.jar. After few runs i see
> ConcurrentAccessTimeoutException.
>
>
> Please let me know your inputs.
>
> thanks
> Kalyan
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

The test failures look unrelated, I get the same with master.

To test it out, I'd suggest building OpenEJB with that patch, and trying it
on your own development machine with a database connection pool size of
one. If your connection isn't returned the pool, you'll know about it
quickly :)

Jon

On Wed, 9 Oct 2019, 16:16 Kalyan,  wrote:

> oh okay.
> thanks for the update
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Accessing Injected @RequestScoped objects from different threads

[Jonathan Gallimore]

This makes sense, you're keeping the state that the async part needs. I was
going to suggest something similar. I'll check this against the specs and
make sure we don't have a bug here.

Jon

On Wed, Oct 9, 2019 at 12:00 AM Paul Carter-Brown
 wrote:

> Hi Jon,
>
> I've attached a new version with an implementation that works along with
> the one that fails.
>
> I got it to work by getting the injected class to implement a method as
> follows:
>
> public SomeContext getForAsync() {
> return this;
> }
>
> That in combination with eagerly loading the required data from context
> injected variables at @PostConstruct means that so long as the instance
> obtained from getForAsync() is used, then when subsequent threads invoke
> the object, there is no proxy in the way and no need to access other
> injected classes that would complain about the different thread being used.
>
> Works for my use case.
>
> Paul Carter-Brown
> Director
> Jini Guru
> m: +27 (0) 83 442 7179 <+27834427179>
> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>   Johannesburg, South Africa
> w: jini.guru  e: p...@jini.guru
>
> Disclaimer: This message and/or attachment(s) may contain
> privileged, confidential and/or personal information. If you are not the
> intended recipient you may not disclose or distribute any of
> the information contained within this message. In such case you must
> destroy this message and inform the sender of the error. Jini Guru may not
> accept liability for any errors, omissions, information and viruses
> contained in the transmission of this message. Any opinions, conclusions
> and other information contained within this message not related to Jini
> Guru official business is deemed to be that of the individual only and is
> not endorsed by Jini Guru.
>
>
>
> On Tue, Oct 8, 2019 at 12:42 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> Awesome, thanks for this. Haven't had a chance to look at this yet, but
>> I'll have a go with it tomorrow.
>>
>> Jon
>>
>> On Mon, Oct 7, 2019 at 9:07 PM Paul Carter-Brown
>>  wrote:
>>
>> > Hi Jon,
>> >
>> > I've created a basic example of the issue as attached.
>> >
>> > mvn install -Prun
>> >
>> > then:
>> >
>> > curl "http://localhost:8000/basic-service/basic/async?echo=111;
>> >
>> > Paul Carter-Brown
>> > Director
>> > Jini Guru
>> > m: +27 (0) 83 442 7179 <+27834427179>
>> > a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>> >   Johannesburg, South Africa
>> > w: jini.guru  e: p...@jini.guru
>> >
>> > Disclaimer: This message and/or attachment(s) may contain
>> > privileged, confidential and/or personal information. If you are not the
>> > intended recipient you may not disclose or distribute any of
>> > the information contained within this message. In such case you must
>> > destroy this message and inform the sender of the error. Jini Guru may
>> not
>> > accept liability for any errors, omissions, information and viruses
>> > contained in the transmission of this message. Any opinions, conclusions
>> > and other information contained within this message not related to Jini
>> > Guru official business is deemed to be that of the individual only and
>> is
>> > not endorsed by Jini Guru.
>> >
>> >
>> >
>> > On Mon, Oct 7, 2019 at 3:02 PM Paul Carter-Brown
>> >  wrote:
>> >
>> >> Hi Jon,
>> >>
>> >> Not easy to create a working example but hopefully this will help
>> explain:
>> >>
>> >> @Stateless
>> >> public class myEJb() {
>> >> @Inject
>> >> private UserContext userContext;
>> >>
>> >> // Gets called from a JAX-RS context
>> >> public void go(AsyncResponse asyncResponse) {
>> >> CompletionStage cs1 = userContext.doSomething();
>> >> cs1.thenAccept((Foo foo) -> {
>> >> ... this is now on a different thread to the previous
>> threads
>> >>
>> >> CompletionStage cs2 = userContext.doSomethingElse(foo)
>> >> ... this gets IllegalStateException
>> >> cs2.thenAccept((Bar bar) -> {
>> >> asyncResponse.resume(bar);
>> >> });
>> >> });
>> >> }
>> >> }
>> >>
>> &g

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

FYI There's a handful of test failures on my full build here. Not sure if
they are related to my change or not yet.

Jon

On Tue, Oct 8, 2019 at 10:28 PM Kalyan  wrote:

> Thanks Jon!
> I will try this.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

Played around with this a little and opened this PR:
https://github.com/apache/tomee/pull/583. Take a look and see what you
think. I still need to do a full build and make sure I haven't
broken anything here. The theory is that is you turn the logging
on OpenEJB.resource.jdbc up to FINEST, you'll get a bunch of debug output
showing where connections are obtained from the datasource, and where they
are returned with connection.close(). If a transaction completes and the
connection has not been closed, it'll log that out, along with where the
connection was borrowed.

I wouldn't put this in production as it needs review and merging etc, as
well as being very verbose, but if you have a local copy of your
application that you can test with, it might be worth stepping through and
using it to ensure your connections are getting "closed", and returned to
the pool. From what you've indicated so far, it looks like you're leaking
connections (i.e., not calling close() on them).

Jon

On Tue, Oct 8, 2019 at 8:58 PM Kalyan  wrote:

> yes that's correct
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

I can reproduce your stack trace by deliberately not calling
connection.close().

"main" #1 prio=5 os_prio=31 cpu=1929.67ms elapsed=28.55s
tid=0x7f8d1c800800 nid=0x1703 waiting on condition  [0x70dd1000]
   java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.1/Native Method)
- parking to wait for  <0x00070ea81590> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(java.base@11.0.1
/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.1
/AbstractQueuedSynchronizer.java:2081)
at
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
at
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
at
org.apache.commons.dbcp2.managed.ManagedConnection.(ManagedConnection.java:60)
at
org.apache.openejb.resource.jdbc.dbcp.BasicManagedDataSource$1$1.(BasicManagedDataSource.java:90)
at
org.apache.openejb.resource.jdbc.dbcp.BasicManagedDataSource$1.getConnection(BasicManagedDataSource.java:90)
at
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533)
at
org.apache.openejb.resource.jdbc.ManagedDataSourceExhaustionTest$DBWorker.check(ManagedDataSourceExhaustionTest.java:74)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
at
org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191)
at
org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
at
org.apache.openejb.core.singleton.SingletonContainer._invoke(SingletonContainer.java:272)
at
org.apache.openejb.core.singleton.SingletonContainer.invoke(SingletonContainer.java:221)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349)
at
org.apache.openejb.resource.jdbc.ManagedDataSourceExhaustionTest$DBWorker$$LocalBeanProxy.check(org/apache/openejb/resource/jdbc/ManagedDataSourceExhaustionTest$DBWorker.java)
at
org.apache.openejb.resource.jdbc.ManagedDataSourceExhaustionTest.test(ManagedDataSourceExhaustionTest.java:84)

Is the EJB making the call out to the database running in a transaction?

Jon

On Tue, Oct 8, 2019 at 7:36 PM Kalyan  wrote:

> Yes i am able to reproduce this issue.
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

We're probably going to make some small changes quite rapidly to 1) see if
we can reproduce your issue and 2) extract some more information in logs.
If you're willing and able to pick up some snapshots, or patch your
8.0.0-M3 with some PRs and report back, that helps.

Jon

On Tue, Oct 8, 2019 at 6:49 PM Kalyan  wrote:

> Thanks Jon for looking into it.
> What do you suggest me to do ?
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

At first glance, I'd say it looks like your database connection pool is
exhausted but there's nothing using the database, so either we have a bug
or connections are leaking. Next step will probably be some logging around
that.

Jon

On Tue, 8 Oct 2019, 17:10 Jonathan Gallimore, 
wrote:

> Got it. Going to be away from my computer for a couple of hours, but I'll
> take a look later today.
>
> Jon
>
> On Tue, Oct 8, 2019 at 4:50 PM Kalyan  wrote:
>
>> Hi Jon,
>> I sent you whole jstack to your email. Please take a look and let me know
>> if
>> anything can be done.
>>
>> thanks
>> Kalyan
>>
>>
>>
>> --
>> Sent from:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>>
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

The problem with getting single threads here and there is its difficult to
pin down the root cause. With the whole jstack file I can probably give you
some pointers pretty quickly (or I'll just say if not). A very long time
back (in the 1.7.3 era) there was an issue where you can lock a database
pool, but that was actually reproducible under small load with small pools.
Most of these types of issues (that I see, at least), particularly when you
see it in production but not other environments, are bottlenecks
communicating to the database or another external system. One thing to
remember is that your stateless pool will have a max of 40 instances *per
EJB* (not in total). If your database pool is also 40, you'll potentially
see issues there.

The first thread you sent is seeing contention issues trying to get a
database connection (the pool is exhausted, either leaking connections, or
the connections are in use in other threads). The more recent one is
showing contention on the stateless EJB pool (it just hasn't timedout
waiting yet). We can't learn to much from these, other than the fact that
they are waiting. What the other threads are doing will be of interest. I
need the full picture otherwise I'm guessing, which won't really help
either of us.

Jon

On Mon, Oct 7, 2019 at 11:39 PM Kalyan  wrote:

> Rest of the thread is pretty much as below
>
> "JungoThreadPool-1-110" #220 prio=5 os_prio=0 tid=0x7fa5fc119000
> nid=0x31ff waiting on condition [0x7fa56dd75000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x00068339f010> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
>
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
> at
>
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> at
> java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
> at
>
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>
>Locked ownable synchronizers:
> - None
>
> "JungoThreadPool-1-109-T888" #219 prio=5 os_prio=0 tid=0x7fa5fc117000
> nid=0x31fe waiting on condition [0x7fa56de74000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x00068022de00> (a
> java.util.concurrent.Semaphore$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:409)
> at org.apache.openejb.util.Pool.pop(Pool.java:247)
> at org.apache.openejb.util.Pool.pop(Pool.java:228)
> at
>
> org.apache.openejb.core.stateless.StatelessInstanceManager$Data.poolPop(StatelessInstanceManager.java:512)
> at
>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:217)
> at
>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349)
> at com.sun.proxy.$Proxy74.forwardToServiceBean(Unknown Source)
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Accessing Injected @RequestScoped objects from different threads

[Jonathan Gallimore]

Awesome, thanks for this. Haven't had a chance to look at this yet, but
I'll have a go with it tomorrow.

Jon

On Mon, Oct 7, 2019 at 9:07 PM Paul Carter-Brown
 wrote:

> Hi Jon,
>
> I've created a basic example of the issue as attached.
>
> mvn install -Prun
>
> then:
>
> curl "http://localhost:8000/basic-service/basic/async?echo=111;
>
> Paul Carter-Brown
> Director
> Jini Guru
> m: +27 (0) 83 442 7179 <+27834427179>
> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>   Johannesburg, South Africa
> w: jini.guru  e: p...@jini.guru
>
> Disclaimer: This message and/or attachment(s) may contain
> privileged, confidential and/or personal information. If you are not the
> intended recipient you may not disclose or distribute any of
> the information contained within this message. In such case you must
> destroy this message and inform the sender of the error. Jini Guru may not
> accept liability for any errors, omissions, information and viruses
> contained in the transmission of this message. Any opinions, conclusions
> and other information contained within this message not related to Jini
> Guru official business is deemed to be that of the individual only and is
> not endorsed by Jini Guru.
>
>
>
> On Mon, Oct 7, 2019 at 3:02 PM Paul Carter-Brown
>  wrote:
>
>> Hi Jon,
>>
>> Not easy to create a working example but hopefully this will help explain:
>>
>> @Stateless
>> public class myEJb() {
>> @Inject
>> private UserContext userContext;
>>
>> // Gets called from a JAX-RS context
>> public void go(AsyncResponse asyncResponse) {
>> CompletionStage cs1 = userContext.doSomething();
>> cs1.thenAccept((Foo foo) -> {
>> ... this is now on a different thread to the previous threads
>>
>> CompletionStage cs2 = userContext.doSomethingElse(foo)
>> ... this gets IllegalStateException
>> cs2.thenAccept((Bar bar) -> {
>> asyncResponse.resume(bar);
>> });
>> });
>> }
>> }
>>
>> @RequestScoped
>> public class UserContext {
>>
>> @Context
>> private HttpServletRequest httpRequest;
>>
>> private Object someVal;
>>
>> public CompletionStage doSomething() {
>> ...
>> ...
>> Use httpRequest ... all OK
>> someVal = httpRequest.getAttribute("someVal");
>> ...
>> }
>>
>> public CompletionStage doSomethingElse(Foo foo) {
>> ...
>> ...
>> if (someVal == null) {
>> // will go in here as someVal is null
>> someVal = httpRequest.getAttribute("someVal"); ...
>> java.lang.IllegalStateException: No CXF message usable for JAX-RS @Context
>> injections in that thread so can't use interface
>> javax.servlet.http.HttpServletRequest
>> }
>> ...
>> }
>> }
>>
>> Paul Carter-Brown
>> Director
>> Jini Guru
>> m: +27 (0) 83 442 7179 <+27834427179>
>> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>>   Johannesburg, South Africa
>> w: jini.guru  e: p...@jini.guru
>>
>> Disclaimer: This message and/or attachment(s) may contain
>> privileged, confidential and/or personal information. If you are not the
>> intended recipient you may not disclose or distribute any of
>> the information contained within this message. In such case you must
>> destroy this message and inform the sender of the error. Jini Guru may not
>> accept liability for any errors, omissions, information and viruses
>> contained in the transmission of this message. Any opinions, conclusions
>> and other information contained within this message not related to Jini
>> Guru official business is deemed to be that of the individual only and is
>> not endorsed by Jini Guru.
>>
>>
>>
>> On Mon, Oct 7, 2019 at 2:29 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>>> Hi Paul
>>>
>>> You able to create an as small as possible sample, maybe based on
>>> https://github.com/apache/tomee/tree/master/examples/async-servlet? I'm
>>> struggling a little to picture the code in my head. It sounds likely
>>> related to the two different threads. I'm sure we can at least help
>>> figure
>>> out a workaround.
>>>
>>> Jon
>>>
>>> On Mon, Oct 7, 2019 at 1:01 PM Paul Carter-Brown
>>&g

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

Are you able to share the whole thing? That's just one thread. If you have
a whole bunch of threads all hitting the database, that sounds like a
potential issue at the database end. If there are no other threads
accessing the database, then its possible there is a leak somewhere.

Jon

On Mon, Oct 7, 2019 at 11:23 PM Kalyan  wrote:

> Hello Jon,
> Even after increasing the bean pool size. I am getting the exception.
>
> Below is the jstack.
> But I have enough connection configured on the database as well.
>
> Could you please see what's going with this.
>
>
> "JungoThreadPool-1-115-T348" #225 prio=5 os_prio=0 tid=0x7fa5fc123000
> nid=0x3204 waiting on condition [0x7fa56d86d000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0006819f6760> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
>
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
> at
>
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
> at
>
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> at
>
> org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
> at
>
> org.apache.commons.dbcp2.managed.ManagedConnection.(ManagedConnection.java:60)
> at
>
> org.apache.openejb.resource.jdbc.dbcp.BasicManagedDataSource$1$1.(BasicManagedDataSource.java:89)
> at
>
> org.apache.openejb.resource.jdbc.dbcp.BasicManagedDataSource$1.getConnection(BasicManagedDataSource.java:89)
> at
>
> org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533)
> at JDBCQueryElement.getConnection(DLJDBCQueryElement.java:3173)
>
> thanks
> Kalyan
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Accessing Injected @RequestScoped objects from different threads

[Jonathan Gallimore]

Hi Paul

You able to create an as small as possible sample, maybe based on
https://github.com/apache/tomee/tree/master/examples/async-servlet? I'm
struggling a little to picture the code in my head. It sounds likely
related to the two different threads. I'm sure we can at least help figure
out a workaround.

Jon

On Mon, Oct 7, 2019 at 1:01 PM Paul Carter-Brown
 wrote:

> Hi,
>
> I have a scenario as follows:
>
> 1) JAX-RS request comes into TomEE 8.0.0 and hits a stateless EJB of mine
> 2) The EJB has an object called UserContext injected which is
> @RequestScoped
> 3) userContext in turn injects HttpServletRequest with @Context
> 4) I use userContext fine. All is good and it can access the
> HttpServletRequest
> 5) My EJB does a rest call to another system. This rest call uses asynhttp
> with reactive programming and returns a CompletionStage.
> 6) my EJB code does a .thenAccept on the completionstage and in this code
> we try and use the injected UserContext. Here we get an error when
> UserCOntext tries to use HttpServletRequest.
>
> java.lang.IllegalStateException: No CXF message usable for JAX-RS
> @Context injections in that thread so can't use interface
> javax.servlet.http.HttpServletRequest
>
>
> I believe this is due to the completionstage being executed on a different
> thread. E.g.. steps 1-5 use TomEE-Exec-1 while step 6 uses async-http-3-3.
>
> To resolve this I got UserContext to eagerly load the data it needs
> from HttpServletRequest
> in step 3 so that at step 6 no calls to HttpServletRequest are needed. It
> seems though that the userContext is proxied by webbeans and I get a
> different instance on the different thread and this new instance has none
> of my eagerly loaded data in it.
>
> Does anyone know how to resolve this issue. Basically I want to somehow get
> step 6 to use the exact instance of UserContext as step 2 even though they
> are on different threads.
>
> Paul Carter-Brown
> Director
> Jini Guru
> m: +27 (0) 83 442 7179 <+27834427179>
> a: 1st Floor, Golf House, Design Quarter, Cnr. William Nicol and Leslie
>   Johannesburg, South Africa
> w: jini.guru  e: p...@jini.guru
>
> Disclaimer: This message and/or attachment(s) may contain
> privileged, confidential and/or personal information. If you are not the
> intended recipient you may not disclose or distribute any of
> the information contained within this message. In such case you must
> destroy this message and inform the sender of the error. Jini Guru may not
> accept liability for any errors, omissions, information and viruses
> contained in the transmission of this message. Any opinions, conclusions
> and other information contained within this message not related to Jini
> Guru official business is deemed to be that of the individual only and is
> not endorsed by Jini Guru.
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

I've had a quick run through of the code and I can't see a log statement
for that value. We can certainly add it to master, but that might not help
you on 8.0.0-M3. If you're feeling handy with a debugger, put a breakpoint
here:
https://github.com/apache/tomee/blob/tomee-8.0.0-M3/container/openejb-core/src/main/java/org/apache/openejb/core/stateless/StatelessContainerFactory.java#L138
and
inspect the pool field.

Do try and get a jstack. It should just be a matter of running jstack
. If you're not familiar with the output, you basically get a stack
trace for every thread in the JVM. Check how many threads are trying to
execute your EJB.

When you run into this issue, its always very tempting to just bump up the
pool size. I get asked this question a lot. My personal advice is that
increasing the pool size should be the absolute last thing you do. If you
have 10 threads all executing a business method on your EJB, and they are
all taking longer than 30 seconds, you have an issue and you need to find
the root cause, understand it, and fix it. Bumping it up to 40 will
probably just lead to 40 threads stuck executing your EJB business method
and getting stuck - the problem just ends up getting worse. If you know the
performance measurements, have everything tuned, and need more throughput,
that's the point to look at the pool size.

Also, take a look at the Singleton bean type as opposed to stateless. As
long as you really do not have state in your bean, a singleton
with @Lock(LockType.READ) should work well, and isn't pooled so there's no
limit on the number of threads that can call business methods all at once.
https://github.com/apache/tomee/tree/master/examples/simple-singleton

> our servers are basically using netty. OpenEjb is embedded in it.

This sounds like a very cool setup. If you wanted to contribute that to
community, I'd encourage you to do so. I would certainly be interested in
seeing it, and I'm sure others would be too.

Jon

On Thu, Oct 3, 2019 at 11:21 PM Kalyan  wrote:

> our servers are basically using netty. OpenEjb is embedded in it. I can try
> to get jstack and look into it.
> Is there anything which is logged while server start up to see how much is
> the max size? I don't have JMX
>
> thanks
> Kalyan
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

I dropped your settings into TomEE 8 here, and checked the pool for my EJB
via JMX (openejb.management -> Pool -> openejb ->  -> (file path) ->
(bean) -> Attributes. It showed with a max size of 40. 1 instance pooled,
but I'd expect that to grow to the max size.

I'd suggest getting a jstack and looking for threads
with 
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
in the trace, and see if you have something locked or running slowly. I'll
happily look at a jstack if you wish, but it may have some information you
don't want to post publicly (check the content of the jstack before
posting).

Jon

On Thu, Oct 3, 2019 at 9:50 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Hi
>
> What version of TomEE are you using?
>
> Jon
>
> On Thu, Oct 3, 2019 at 9:16 PM Kalyan  wrote:
>
>> Hello,
>> I am getting following error in my application.
>>
>> avax.ejb.ConcurrentAccessTimeoutException: No instances available in
>> Stateless Session Bean pool.  Waited 30 SECONDS
>> at
>>
>> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:226)
>> at
>>
>> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
>> at
>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
>> at
>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
>> at
>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
>> at
>>
>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349)
>>
>>
>>
>> My application is heavily used. Looks like not enough instances of beans.
>>
>> I saw this post to increase the pool size
>>
>> https://tomee.apache.org/admin/configuration/containers.html
>>
>>
>> and changed my configuration as
>>
>> java.naming.factory.initial=org.apache.openejb.core.LocalInitialContextFactory
>> openejb.deployments.classpath.ear=false
>>
>> myApp = new://Container?type=STATELESS
>> myApp.AccessTimeout = 30 seconds
>> *myApp.MaxSize = 40*
>> myApp.MinSize = 0
>> myApp.StrictPooling = true
>> myApp.MaxAge = 0 hours
>> myApp.ReplaceAged = true
>> myApp.ReplaceFlushed = false
>> myApp.MaxAgeOffset = -1
>> myApp.IdleTimeout = 0 minutes
>> myApp.GarbageCollection = false
>> myApp.SweepInterval = 5 minutes
>> myApp.CallbackThreads = 5
>> myApp.CloseTimeout = 5 minutes
>> myApp.UseOneSchedulerThreadByBean = false
>> myApp.EvictionThreads = 1
>>
>>
>> On the server start up I see
>>
>> INFO - Configuring Service(id=myApp, type=Container, provider-id=Default
>> Stateless Container)
>>
>> DEBUG - Containers: 1
>> DEBUG - TypeContainer ID
>> DEBUG -STATELESS   myApp
>> DEBUG - Deployments   : 5
>> DEBUG - TypeDeployment ID
>>
>> /Question i have is /
>> How would i know if the bean size is increased ?  I don't see any log
>> message for it.
>>
>> /Secondly I also see /
>>
>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible values
>> are: none, annotations, enums, all or NONE or ALL
>> DEBUG - Using default 'AsynchronousPool.Size=5'
>> DEBUG - Using default 'AsynchronousPool.CorePoolSize=5'
>> DEBUG - Using default 'AsynchronousPool.MaximumPoolSize=5'
>> DEBUG - Using default 'AsynchronousPool.QueueSize=5'
>> DEBUG - Using default 'AsynchronousPool.KeepAliveTime=60 SECONDS'
>> DEBUG - Using default 'AsynchronousPool.AllowCoreThreadTimeOut=true'
>> DEBUG - Using default 'AsynchronousPool.QueueType=linked'.  Possible
>> values
>> are: array, linked, priority, synchronous
>> DEBUG - Using default 'AsynchronousPool.OfferTimeout=30 SECONDS'
>> DEBUG - Using default 'AsynchronousPool.ShutdownWaitDuration=1 MINUTES'
>>
>>
>> What's the AsynchronousPool ???
>>
>>
>> Please help me to sort this issue?
>> I'm running into this issues in production.
>>
>>
>>
>> thanks
>> Kalyan
>>
>>
>>
>>
>>
>>
>>
>> --
>> Sent from:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>>
>

Re: javax.ejb.ConcurrentAccessTimeoutException: No instances available in Stateless Session Bean pool. Waited 30 SECONDS

[Jonathan Gallimore]

Hi

What version of TomEE are you using?

Jon

On Thu, Oct 3, 2019 at 9:16 PM Kalyan  wrote:

> Hello,
> I am getting following error in my application.
>
> avax.ejb.ConcurrentAccessTimeoutException: No instances available in
> Stateless Session Bean pool.  Waited 30 SECONDS
> at
>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:226)
> at
>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349)
>
>
>
> My application is heavily used. Looks like not enough instances of beans.
>
> I saw this post to increase the pool size
>
> https://tomee.apache.org/admin/configuration/containers.html
>
>
> and changed my configuration as
>
> java.naming.factory.initial=org.apache.openejb.core.LocalInitialContextFactory
> openejb.deployments.classpath.ear=false
>
> myApp = new://Container?type=STATELESS
> myApp.AccessTimeout = 30 seconds
> *myApp.MaxSize = 40*
> myApp.MinSize = 0
> myApp.StrictPooling = true
> myApp.MaxAge = 0 hours
> myApp.ReplaceAged = true
> myApp.ReplaceFlushed = false
> myApp.MaxAgeOffset = -1
> myApp.IdleTimeout = 0 minutes
> myApp.GarbageCollection = false
> myApp.SweepInterval = 5 minutes
> myApp.CallbackThreads = 5
> myApp.CloseTimeout = 5 minutes
> myApp.UseOneSchedulerThreadByBean = false
> myApp.EvictionThreads = 1
>
>
> On the server start up I see
>
> INFO - Configuring Service(id=myApp, type=Container, provider-id=Default
> Stateless Container)
>
> DEBUG - Containers: 1
> DEBUG - TypeContainer ID
> DEBUG -STATELESS   myApp
> DEBUG - Deployments   : 5
> DEBUG - TypeDeployment ID
>
> /Question i have is /
> How would i know if the bean size is increased ?  I don't see any log
> message for it.
>
> /Secondly I also see /
>
> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible values
> are: none, annotations, enums, all or NONE or ALL
> DEBUG - Using default 'AsynchronousPool.Size=5'
> DEBUG - Using default 'AsynchronousPool.CorePoolSize=5'
> DEBUG - Using default 'AsynchronousPool.MaximumPoolSize=5'
> DEBUG - Using default 'AsynchronousPool.QueueSize=5'
> DEBUG - Using default 'AsynchronousPool.KeepAliveTime=60 SECONDS'
> DEBUG - Using default 'AsynchronousPool.AllowCoreThreadTimeOut=true'
> DEBUG - Using default 'AsynchronousPool.QueueType=linked'.  Possible values
> are: array, linked, priority, synchronous
> DEBUG - Using default 'AsynchronousPool.OfferTimeout=30 SECONDS'
> DEBUG - Using default 'AsynchronousPool.ShutdownWaitDuration=1 MINUTES'
>
>
> What's the AsynchronousPool ???
>
>
> Please help me to sort this issue?
> I'm running into this issues in production.
>
>
>
> thanks
> Kalyan
>
>
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: Problem with MessageConsumers under TomEE 8.0.0

[Jonathan Gallimore]

> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
states the following:  There is no need to close the sessions, producers,
and consumers of a closed connection.

> Here is the link:
https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- <
https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->

Good question. The changes in this area between 8.0.0-M3 and 8.0.0, are,
you'll be unsurprised to find out, around transaction handling. We need to
dig in a bit further.

The Javadoc also states this: "Closing a connection causes any of its
sessions' transactions in progress to be rolled back. In the case where a
session's work is coordinated by an external transaction manager, a
session's commit and rollback methods are not used and the result of a
closed session's work is determined later by the transaction manager.
Closing a connection does NOT force an acknowledgment of
client-acknowledged sessions."

A lot of this describes standalone usage, as opposed to usage in an
application server. The Connection object should actually be a proxy, and
calling close() shouldn't actually do anything. The sendMessage() method on
the CustomJmsService bean is transactional, and the connection should be
returned back to the pool once the method completes and the transaction is
committed.

Thank you for the sample code, we should be able to debug through and see
what's going on. I should be able to do this over the next day - I'll post
my steps here in case you want to dig in and have a go yourself.

Jon

On Mon, Sep 30, 2019 at 6:32 PM Ihsan Ecemis  wrote:

>
> Thank you very much for your suggestion Jon,  adding
> connection.createSession(), session.createProducer(), and
> session.createConsumer() in the try-with-resources block  make things work
> again!
>
>
> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
> states the following:  There is no need to close the sessions, producers,
> and consumers of a closed connection.
>
> Here is the link:
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- <
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->
>
>
> And our original code, that did not close/auto-close Session,
> MessageProducer, and MessageConsumer objects worked fine since at least
> TomEE 7.0.2  (our git history shows that we had such a piece of code
> implemented in March 2017)
>
>
>
> > On Sep 30, 2019, at 09:14, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm wondering if this is because your send method isn't closing the
> > producer and the session? I did try your code and I saw the issue. I
> turned
> > it into an example, and added an Arquillian test:
> > https://github.com/apache/tomee/pull/578
> >
> > Note that I added the session, producer and consumer into the
> > try-with-resources block so they are auto-closed at the end of the
> method.
> >
> > Can you take a look and let me know what you think?
> >
> > Jon
> >
> > On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis  wrote:
> >
> >>
> >> Hello Everyone,
> >>
> >> We recently upgraded our staging environment from TomEE 8.0.0-M3 to
> 8.0.0
> >> and things started to break.
> >>
> >> After some troubleshooting, we realized that we cannot dequeue JMS
> >> messages from our ActiveMQ server using MessageConsumers.
> >>
> >>
> >> We dequeue messages in 2 different ways:  We use MessageDriven beans for
> >> most of our queues.  But with some others, we periodically poll by
> creating
> >> a MessageConsumer (please see the code below for that second case)
> >>
> >> MessageDriven beans work without any problems but we cannot receive any
> >> messages via MessageConsumers.  That same backend code is working fine
> with
> >> 8.0.0-M3.
> >>
> >>
> >> We tested this with different versions of ActiveMQ server (5.15.6,
> 5.15.9,
> >> 5.15.10) but TomEE  8.0.0 did not work with any of them.
> >>
> >>
> >> Below is redacted code snippets showing where we have the problem.
> >>
> >> Any help will be greatly appreciated.   Please let me know if you have
> any
> >> questions about our setup.
> >>
> >> Thanks,
> >>
> >> Ihsan.
> >>
> >>
> >>
> >> @Stateless
> >> public class LogService {
> >>
> >>@EJB
> >>private CustomJmsService customJmsService;
> >>
> >>@javax.ejb.Schedule(second = "*/30", minute = "*&quo

Re: Problem with MessageConsumers under TomEE 8.0.0

[Jonathan Gallimore]

Here you go:
https://github.com/apache/tomee/pull/578/files#diff-842e4b4a572903cdcd1260b172034a7dR59

Jon

On Mon, Sep 30, 2019 at 9:14 PM Jonathan S. Fisher 
wrote:

> Interesting, can you paste the new code that is working (the one with the
> explicit try/close)
>
> On Mon, Sep 30, 2019 at 12:40 PM Ihsan Ecemis  wrote:
>
> >
> > Hi Jonathan,
> >
> > We do not have a tomee.xml file, we use resources.xml file instead.  I
> > pasted its contents below.
> >
> > BTW, my previous redacted code snippet omitted the following 2 lines from
> > the CustomJmsService class:
> >
> > @Resource(name = "MyJmsConnectionFactory")
> > private ConnectionFactory connectionFactory;
> >
> > (in case you wonder where connectionFactory is coming from)
> >
> > Let me know if you see any problems with our resource configuration.
> >
> > Thank you,
> >
> > Ihsan.
> >
> >
> > 
> > 
> > 
> > 
> > jdbcDriver   = org.postgresql.Driver
> > jdbcUrl  =
> >
> jdbc:postgresql://${database_hostname}:${database_port}/${database_name}${jdbc_ssl_flag}
> > userName = ${database_username}
> > password = ${database_password}
> > 
> >
> > 
> > # Connect to the external ActiveMQ broker running on
> > localhost:61616
> > BrokerXmlConfig  =
> > ServerUrl=  nio://localhost:61616
> > 
> >
> >  > type="javax.jms.ConnectionFactory">
> > ResourceAdapter  = MyJmsResourceAdapter
> > 
> >
> > 
> > ResourceAdapter  = MyJmsResourceAdapter
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> > > On Sep 30, 2019, at 13:08, Jonathan S. Fisher 
> > wrote:
> > >
> > > Also, can you post your tomee.xml?
> > >
> > > On Mon, Sep 30, 2019 at 8:14 AM Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm wondering if this is because your send method isn't closing the
> > >> producer and the session? I did try your code and I saw the issue. I
> > turned
> > >> it into an example, and added an Arquillian test:
> > >> https://github.com/apache/tomee/pull/578
> > >>
> > >> Note that I added the session, producer and consumer into the
> > >> try-with-resources block so they are auto-closed at the end of the
> > method.
> > >>
> > >> Can you take a look and let me know what you think?
> > >>
> > >> Jon
> > >>
> > >> On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis 
> > wrote:
> > >>
> > >>>
> > >>> Hello Everyone,
> > >>>
> > >>> We recently upgraded our staging environment from TomEE 8.0.0-M3 to
> > 8.0.0
> > >>> and things started to break.
> > >>>
> > >>> After some troubleshooting, we realized that we cannot dequeue JMS
> > >>> messages from our ActiveMQ server using MessageConsumers.
> > >>>
> > >>>
> > >>> We dequeue messages in 2 different ways:  We use MessageDriven beans
> > for
> > >>> most of our queues.  But with some others, we periodically poll by
> > >> creating
> > >>> a MessageConsumer (please see the code below for that second case)
> > >>>
> > >>> MessageDriven beans work without any problems but we cannot receive
> any
> > >>> messages via MessageConsumers.  That same backend code is working
> fine
> > >> with
> > >>> 8.0.0-M3.
> > >>>
> > >>>
> > >>> We tested this with different versions of ActiveMQ server (5.15.6,
> > >> 5.15.9,
> > >>> 5.15.10) but TomEE  8.0.0 did not work with any of them.
> > >>>
> > >>>
> > >>> Below is redacted code snippets showing where we have the problem.
> > >>>
> > >>> Any help will be greatly appreciated.   Please let me know if you
> have
> > >> any
> > >>> questions about our setup.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Ihsan.
> > >>>
> > >>>
> > >>>
> > >>> @Stateless
> > >&

Re: Problem with MessageConsumers under TomEE 8.0.0

[Jonathan Gallimore]

Hi,

I'm wondering if this is because your send method isn't closing the
producer and the session? I did try your code and I saw the issue. I turned
it into an example, and added an Arquillian test:
https://github.com/apache/tomee/pull/578

Note that I added the session, producer and consumer into the
try-with-resources block so they are auto-closed at the end of the method.

Can you take a look and let me know what you think?

Jon

On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis  wrote:

>
> Hello Everyone,
>
> We recently upgraded our staging environment from TomEE 8.0.0-M3 to 8.0.0
> and things started to break.
>
> After some troubleshooting, we realized that we cannot dequeue JMS
> messages from our ActiveMQ server using MessageConsumers.
>
>
> We dequeue messages in 2 different ways:  We use MessageDriven beans for
> most of our queues.  But with some others, we periodically poll by creating
> a MessageConsumer (please see the code below for that second case)
>
> MessageDriven beans work without any problems but we cannot receive any
> messages via MessageConsumers.  That same backend code is working fine with
> 8.0.0-M3.
>
>
> We tested this with different versions of ActiveMQ server (5.15.6, 5.15.9,
> 5.15.10) but TomEE  8.0.0 did not work with any of them.
>
>
> Below is redacted code snippets showing where we have the problem.
>
> Any help will be greatly appreciated.   Please let me know if you have any
> questions about our setup.
>
> Thanks,
>
> Ihsan.
>
>
>
> @Stateless
> public class LogService {
>
> @EJB
> private CustomJmsService customJmsService;
>
> @javax.ejb.Schedule(second = "*/30", minute = "*", hour = "*")
> public void pollLogQueue() throws Exception {
> final TextMessage logMessage =
> customJmsService.receiveLogMessage(1000);
> if (logMessage != null) {
> persistLogMessages(logMessages);
> }
> }
> }
>
> @Stateless
> public class CustomJmsService {
>
> @Resource(name = "logQueue")
> private Queue logQueue;
>
> public void sendLogMessage(final LogMessage message) {
> sendMessage(logQueue, message);
> }
>
> private void sendMessage(final Queue queue, final CustomJmsMessage
> message) {
> try (final Connection connection =
> connectionFactory.createConnection()) {
> connection.start();
>
> final Session session = connection.createSession(true,
> Session.AUTO_ACKNOWLEDGE);
> final MessageProducer producer = session.createProducer(queue);
> final String serializedMessage =
> CustomJsonProvider.toJson(message);
> final Message jmsMessage =
> session.createTextMessage(serializedMessage);
>
> // This enqueues messages successfully with both 8.0.0-M3 and
> 8.0.0
> producer.send(jmsMessage);
> } catch (final Exception e) {
> throw new RuntimeException("Caught exception from JMS when
> sending a message", e);
> }
> }
>
> public TextMessage receiveLogMessage(final long receiveTimeoutMillis) {
> return receiveMessage(logQueue, receiveTimeoutMillis);
> }
>
> private TextMessage receiveMessage(final Queue queue, final long
> receiveTimeoutMillis) {
> try (final Connection connection =
> connectionFactory.createConnection()) {
> connection.start();
>
> final Session session = connection.createSession(true,
> Session.AUTO_ACKNOWLEDGE);
> final MessageConsumer messageConsumer =
> session.createConsumer(queue);
> final Message jmsMessage =
> messageConsumer.receive(receiveTimeoutMillis);
>
> // PROBLEM: jmsMessage is always null with 8.0.0. This was
> working with 8.0.0-M3
> if (jmsMessage == null) {
> return null;
> }
>
> return (TextMessage) jmsMessage;
> } catch (final Exception e) {
> throw new RuntimeException("Caught exception from JMS when
> receiving a message", e);
> }
> }
> }
>
>
>

Re: Does TomEE 8.0.0 run on Java 11?

[Jonathan Gallimore]

Thanks for the feedback - I'll take a look at that and get back to you.

Jon

On Fri, Sep 27, 2019 at 5:23 PM Paul Carter-Brown
 wrote:

> Hi Jon,
>
> I've tried with 8.0.1-SNAPSHOT and get an error:
>
> INFO: Configuring enterprise application:
>
> /home/paul/Source/jg-services/template-service/service/target/apache-tomee/webapps/jg-services-servicename-service
> Sep 27, 2019 3:58:30 PM org.apache.openejb.config.ReadDescriptors deploy
> SEVERE: Unable to load Persistence Unit from EAR:
>
> /home/paul/Source/jg-services/template-service/service/target/apache-tomee/webapps/jg-services-servicename-service,
> module:
>
> file:/home/paul/Source/jg-services/template-service/service/target/apache-tomee/webapps/jg-services-servicename-service/.
> Exception: class "javax.persistence.package-info"'s signer information does
> not match signer information of other classes in the same package
> java.lang.SecurityException: class "javax.persistence.package-info"'s
> signer information does not match signer information of other classes in
> the same package
> at java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1150)
> at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:905)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014)
> at
>
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:550)
> ...
>
> I've checked and think the conflict could be due
> to jakarta.persistence-2.2.2.jar and eclipselink-2.7.4.jar both having the
> javax.persistence and jakarta.persistence-2.2.2.jar is signed
>
> Paul
>
>
> On Fri, Sep 27, 2019 at 11:26 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Hi Paul
> >
> > Using 8.0.1-SNAPSHOT should work already - let me know if it doesn't.
> There
> > another pending fix for the standalone server - I was planning to
> propose a
> > release once that's in.
> >
> > Jon
> >
> > On Fri, Sep 27, 2019 at 10:19 AM Paul Carter-Brown
> >  wrote:
> >
> > > Hi Jon,
> > >
> > > Any chance 2.7.4 can be pushed into an official TomEE build so that we
> > can
> > > use the tomee maven plugin and get this fix. Right now we can manually
> > > upgrade for a normal deployment but our integration tests that use the
> > > tomee maven plugin use 2.7.3.
> > >
> > > Paul
> > >
> > >
> > > On Wed, Sep 25, 2019 at 10:31 PM Paul Carter-Brown
> > >  wrote:
> > >
> > > > Thanks Jon
> > > >
> > > > Worked a charm.
> > > >
> > > > Paul
> > > >
> > > >
> > > > On Wed, Sep 25, 2019 at 9:17 PM Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > >> Looks like the update to EclipseLink 2.7.4 I committed this morning
> > > fixes
> > > >> it. Could you try swapping out the EclipseLink jar in your Plume
> > > >> distribution lib directory for 2.7.4 and let us know how you get on?
> > > >>
> > > >>
> > > >>
> > >
> >
> https://repo1.maven.org/maven2/org/eclipse/persistence/eclipselink/2.7.4/eclipselink-2.7.4.jar
> > > >>
> > > >> Thanks
> > > >>
> > > >> Jon
> > > >>
> > > >> On Wed, Sep 25, 2019 at 4:57 PM Paul Carter-Brown
> > > >>  wrote:
> > > >>
> > > >> > Hi Jonathan,
> > > >> >
> > > >> > Seems like it's related to using PLUME (Eclipselink) where a
> > > >> > persistence.xml is present.
> > > >> >
> > > >> > Logs are as attached along with a simple war that fails. If I
> > comment
> > > >> out
> > > >> > the contents of my persistence.xml file then it boots fine (but
> > > >> > EntityManagers are all null).
> > > >> >
> > > >> > If I include persistence.xml and even comment out my EntityManager
> > > >> > injection points then it fails.
> > > >> >
> > > >> > Should if you need more info.
> > > >> >
> > > >> > Paul
> > > >> >
> > > >> >
> > > >> > On Wed, Sep 25, 2019 at 12:29 PM Jonathan Gallimore <
> > > >> > jonathan.gallim...@gmail.com> wrote:
> > > >> >
> 

Re: Does TomEE 8.0.0 run on Java 11?

[Jonathan Gallimore]

Hi Paul

Using 8.0.1-SNAPSHOT should work already - let me know if it doesn't. There
another pending fix for the standalone server - I was planning to propose a
release once that's in.

Jon

On Fri, Sep 27, 2019 at 10:19 AM Paul Carter-Brown
 wrote:

> Hi Jon,
>
> Any chance 2.7.4 can be pushed into an official TomEE build so that we can
> use the tomee maven plugin and get this fix. Right now we can manually
> upgrade for a normal deployment but our integration tests that use the
> tomee maven plugin use 2.7.3.
>
> Paul
>
>
> On Wed, Sep 25, 2019 at 10:31 PM Paul Carter-Brown
>  wrote:
>
> > Thanks Jon
> >
> > Worked a charm.
> >
> > Paul
> >
> >
> > On Wed, Sep 25, 2019 at 9:17 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> Looks like the update to EclipseLink 2.7.4 I committed this morning
> fixes
> >> it. Could you try swapping out the EclipseLink jar in your Plume
> >> distribution lib directory for 2.7.4 and let us know how you get on?
> >>
> >>
> >>
> https://repo1.maven.org/maven2/org/eclipse/persistence/eclipselink/2.7.4/eclipselink-2.7.4.jar
> >>
> >> Thanks
> >>
> >> Jon
> >>
> >> On Wed, Sep 25, 2019 at 4:57 PM Paul Carter-Brown
> >>  wrote:
> >>
> >> > Hi Jonathan,
> >> >
> >> > Seems like it's related to using PLUME (Eclipselink) where a
> >> > persistence.xml is present.
> >> >
> >> > Logs are as attached along with a simple war that fails. If I comment
> >> out
> >> > the contents of my persistence.xml file then it boots fine (but
> >> > EntityManagers are all null).
> >> >
> >> > If I include persistence.xml and even comment out my EntityManager
> >> > injection points then it fails.
> >> >
> >> > Should if you need more info.
> >> >
> >> > Paul
> >> >
> >> >
> >> > On Wed, Sep 25, 2019 at 12:29 PM Jonathan Gallimore <
> >> > jonathan.gallim...@gmail.com> wrote:
> >> >
> >> >> The short answer is yes - TomEE 8.0.0 should work fine on Java 11. We
> >> >> definitely want to know about your issue and dig into it.
> >> >>
> >> >> Can you provide your boot output? I did just double check with a
> >> vanilla
> >> >> TomEE 8.0.0 Plus and OpenJDK 11 from AdoptOpenJDK on my Mac here -
> its
> >> >> booted fine. Output is here:
> >> >> https://gist.github.com/jgallimore/27997af50014229b702cf8b5710563ec
> >> >>
> >> >> I have actually successfully booted TomEE 8 on a self-built JDK 13 as
> >> >> well.
> >> >> I wouldn't expect it to work with apps whose classes are compiled
> with
> >> >> Java
> >> >> 13 as a target as I suspect that will need an ASM update, but it did
> >> boot
> >> >> and run an application.
> >> >>
> >> >> Jon
> >> >>
> >> >> On Tue, Sep 24, 2019 at 9:44 PM Paul Carter-Brown
> >> >>  wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > Does tomEE 8.0.0 support OpenJDK 11? I've tried and get errors upon
> >> >> boot.
> >> >> > Will elaborate if it is supposed to support java 11.
> >> >> >
> >> >> > Paul
> >> >> >
> >> >>
> >> >
> >>
> >
>

Re: Does TomEE 8.0.0 run on Java 11?

[Jonathan Gallimore]

Looks like the update to EclipseLink 2.7.4 I committed this morning fixes
it. Could you try swapping out the EclipseLink jar in your Plume
distribution lib directory for 2.7.4 and let us know how you get on?

https://repo1.maven.org/maven2/org/eclipse/persistence/eclipselink/2.7.4/eclipselink-2.7.4.jar

Thanks

Jon

On Wed, Sep 25, 2019 at 4:57 PM Paul Carter-Brown
 wrote:

> Hi Jonathan,
>
> Seems like it's related to using PLUME (Eclipselink) where a
> persistence.xml is present.
>
> Logs are as attached along with a simple war that fails. If I comment out
> the contents of my persistence.xml file then it boots fine (but
> EntityManagers are all null).
>
> If I include persistence.xml and even comment out my EntityManager
> injection points then it fails.
>
> Should if you need more info.
>
> Paul
>
>
> On Wed, Sep 25, 2019 at 12:29 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> The short answer is yes - TomEE 8.0.0 should work fine on Java 11. We
>> definitely want to know about your issue and dig into it.
>>
>> Can you provide your boot output? I did just double check with a vanilla
>> TomEE 8.0.0 Plus and OpenJDK 11 from AdoptOpenJDK on my Mac here - its
>> booted fine. Output is here:
>> https://gist.github.com/jgallimore/27997af50014229b702cf8b5710563ec
>>
>> I have actually successfully booted TomEE 8 on a self-built JDK 13 as
>> well.
>> I wouldn't expect it to work with apps whose classes are compiled with
>> Java
>> 13 as a target as I suspect that will need an ASM update, but it did boot
>> and run an application.
>>
>> Jon
>>
>> On Tue, Sep 24, 2019 at 9:44 PM Paul Carter-Brown
>>  wrote:
>>
>> > Hi,
>> >
>> > Does tomEE 8.0.0 support OpenJDK 11? I've tried and get errors upon
>> boot.
>> > Will elaborate if it is supposed to support java 11.
>> >
>> > Paul
>> >
>>
>

Re: Any reason to not follow BouncyCastle latest version ?

[Jonathan Gallimore]

Done - I've updated this across 7.0.x and 7.1.x as well as TomEE 8. Thanks
for the JIRA.

Jon

On Wed, Sep 25, 2019 at 1:24 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> Done: https://issues.apache.org/jira/browse/TOMEE-2691
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mercredi 25 septembre 2019 13:01
> To: users@tomee.apache.org
> Subject: Re: Any reason to not follow BouncyCastle latest version ?
>
> There's no specific reason why - can you file a JIRA, and I'll be happy to
> update it.
>
> Thanks
>
> Jon
>
> On Wed, Sep 25, 2019 at 11:56 AM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello,
> >
> > I have seen that,  in TomEE Plus 8.0.0, the BouncyCastle version
> > embedded is still 1.61 whereas 1.62 and 1.63 have been released.
> >
> > Any reason for that ?
> >
> > Best Regards.
> >
> >
> > 
> > This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: TomEE 8.0.0 MP version compliance ?

[Jonathan Gallimore]

> Regarding Jakarta 8.0 compliancy, it should be good to know about the 10%
non compliant implementation. Is it JMS (not really JMS 2.0 compliant)? Or
other parts ?

I don't have the data right in front of me, but I'll get it and either file
some JIRAs, or get a list of the relevant JIRAs so everyone can dig in.

Jon

On Wed, Sep 25, 2019 at 12:07 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello Jonathan,
>
> Thanks for the info :-)
>
> Just my 2 cents regarding MP:
>  - 8.0.0 (MP 2.1), 8.0.1 (MP2.2)
>  - 8.1.0 (MP 3.0)
>
> Regarding Jakarta 8.0 compliancy, it should be good to know about the 10%
> non compliant implementation. Is it JMS (not really JMS 2.0 compliant)? Or
> other parts ?
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mercredi 25 septembre 2019 12:49
> To: users@tomee.apache.org
> Subject: Re: TomEE 8.0.0 MP version compliance ?
>
> Hi
>
> David posted on the dev@ mailing list a couple of days ago:
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomee-openejb.979440.n4.nabble.com%2FDISCUSSION-Completing-Jakarta-EE-8-and-MicroProfile-3-0-8-0-x-or-8-1-x-td4690606.htmldata=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7Cef1063a601f34a5cf8d808d741a60fd8%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C637050053796582241sdata=v%2BLJ9mNyHKmbURe6Pb3HiyAE8xJu0CobiuZOegvyw9c%3Dreserved=0
>
> Jakarta EE 8 status.  TomEE 8.0.0 is to my understanding about 90%
> complete with the Web Profile.  Open question is where do we want to do the
> work to finish Jakarta EE 8 compliance?  In the past discussions (2 years
> ago), there was a preference to kick out TomEE 7 not certified and aim at a
> 7.1 for certification.  We didn't end up getting the Java EE 7 TCK, but do
> we want to follow this path for Jakarta EE 8? (leave 8.0.x stable fixes
> only, do compliance work in a future 8.1?).  That would mean trunk would
> most likely need to updated to 8.1.0-SNAPSHOT.
>
> MicroProfile status.  TomEE 8.0.0 is MicroProfile 2.1 compliant.  Making
> it MicroProfile 3.0 compliant involves a major upgrade from OpenTracing 1.x
> to 2.x and a breaking change to update to MicroProfile Metrics 2.x.  Do we
> want to do this in 8.0.x or push this in an 8.1.x? (as noted above, would
> most likely mean we need to update trunk to 8.1.0-SNAPSHOT).
>
> I appreciate folks who are only on the user@ list probably didn't see
> this.
> I'd encourage you to post your thoughts either on David's original post,
> or here. I don't know that I have a strong view, but I'd prefer fewer
> branches to maintain rather than more. I think feedback from the community,
> particularly those using MicroProfile and would therefore be impacted by
> the breaking changes to move to MP 3.0 would be very much appreciated.
>
> Jon
>
> On Wed, Sep 25, 2019 at 11:35 AM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello everyone,
> >
> > Any answer to the question below ?
> > I have another one: what about Java EE/Jakarta EE 8 compliancy for
> > TomEE 8 ?
> >
> > Best Regards.
> >
> > From: COURTAULT Francois
> > Sent: lundi 23 septembre 2019 08:38
> > To: users@tomee.apache.org
> > Subject: TomEE 8.0.0 MP version compliance ?
> >
> > Hello every one,
> >
> > Congrats for the 8.0.0 release :)
> > They are some questions about  production usage : I have the same
> concern.
> >
> > Just want also to know if TomEE 8 is MP 2.0, 2.1 or 2.2 compliant:
> > could you please provide this information ?
> >
> > Best Regards.
> >
> >
> >
> > 
> > This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: is tomee8 for evaluation only?

[Jonathan Gallimore]

We didn't release it for 8.0.0 because there was an issue with it, and we
haven't really seen a lot of activity/demand for it for a long time. It's
good to hear that it's still being used. I believe Jean-Louis has found a
fix for your issue, and I see no reason why we couldn't release an 8.0.1
including the standalone server fairly quickly.

Jon

On Wed, Sep 25, 2019 at 12:14 PM Bruce Beaumont 
wrote:

> Related question
>
> Will there be an OpenEJB standalone build for version 8
>
> On 2019-09-25, 12:43, "Jonathan Gallimore" 
> wrote:
>
> >Hi
> >
> >Leaving the evaluation message on the download page when releasing TomEE
> >8.0.0 was a mistake on my part, apologies for the confusion. TomEE 8.0.0
> >is
> >intended for production use, as opposed to a milestone release which the
> >previous -M1, -M2 and -M3 releases were. The page has been corrected and
> >the evaluation notice removed.
> >
> >Jon
> >
> >On Wed, Sep 25, 2019 at 11:37 AM COURTAULT Francois <
> >francois.courta...@thalesgroup.com> wrote:
> >
> >> Hello everyone,
> >>
> >> Any answer for the Emmanuel Touzery's questions ?
> >>
> >> Best Regards.
> >>
> >> -Original Message-
> >> From: Emmanuel Touzery [mailto:emmanuel.touz...@lit-transit.com]
> >> Sent: lundi 23 septembre 2019 07:58
> >> To: users@tomee.apache.org
> >> Subject: is tomee8 for evaluation only?
> >>
> >> Hello,
> >>
> >>  on the download page for TOMEE, there was a for a time this message
> >> related to tomee8:
> >>
> >> Note: Please note the 8.0.0 release is a milestone release intended
> >> for evaluation purposes and should not be used in production.
> >>
> >>  But as of now, this message is not visible anymore on the download
> >> page. I also can't track any official tomee8 announcement to confirm
> >> whether that message still holds or not. Can a tomee developer confirm
> >> whether tomee8 is appropriate or not for production environments? If
> >>it's
> >> not, I guess the plan is that 8.0.1 would be appropriate then?
> >>
> >>  Thank you and regards,
> >>
> >> Emmanuel
> >>
> >> 
> >>  This message and any attachments are intended solely for the addressees
> >> and may contain confidential information. Any unauthorized use or
> >> disclosure, either whole or partial, is prohibited.
> >> E-mails are susceptible to alteration. Our company shall not be liable
> >>for
> >> the message if altered, changed or falsified. If you are not the
> >>intended
> >> recipient of this message, please delete it and notify the sender.
> >> Although all reasonable efforts have been made to keep this transmission
> >> free from viruses, the sender will not be liable for damages caused by a
> >> transmitted virus.
> >>
>
>   Disclaimer
>
>
>  Massmart Ethics: Tell us if we don't do what is Right, Fair, Honest and
> Legal. Free call 0800 20 32 46 or email massm...@ethics-line.com
> (Massmart's Ethics Line is managed confidentially by Deloitte Tip-offs
> Anonymous)
>  To view the Email Disclaimer, click on the hyperlink: Massmart Email
> Disclaimer
>

Re: Any reason to not follow BouncyCastle latest version ?

[Jonathan Gallimore]

There's no specific reason why - can you file a JIRA, and I'll be happy to
update it.

Thanks

Jon

On Wed, Sep 25, 2019 at 11:56 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> I have seen that,  in TomEE Plus 8.0.0, the BouncyCastle version embedded
> is still 1.61 whereas 1.62 and 1.63 have been released.
>
> Any reason for that ?
>
> Best Regards.
>
>
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: is tomee8 for evaluation only?

[Jonathan Gallimore]

Hi

Leaving the evaluation message on the download page when releasing TomEE
8.0.0 was a mistake on my part, apologies for the confusion. TomEE 8.0.0 is
intended for production use, as opposed to a milestone release which the
previous -M1, -M2 and -M3 releases were. The page has been corrected and
the evaluation notice removed.

Jon

On Wed, Sep 25, 2019 at 11:37 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> Any answer for the Emmanuel Touzery's questions ?
>
> Best Regards.
>
> -Original Message-
> From: Emmanuel Touzery [mailto:emmanuel.touz...@lit-transit.com]
> Sent: lundi 23 septembre 2019 07:58
> To: users@tomee.apache.org
> Subject: is tomee8 for evaluation only?
>
> Hello,
>
>  on the download page for TOMEE, there was a for a time this message
> related to tomee8:
>
> Note: Please note the 8.0.0 release is a milestone release intended
> for evaluation purposes and should not be used in production.
>
>  But as of now, this message is not visible anymore on the download
> page. I also can't track any official tomee8 announcement to confirm
> whether that message still holds or not. Can a tomee developer confirm
> whether tomee8 is appropriate or not for production environments? If it's
> not, I guess the plan is that 8.0.1 would be appropriate then?
>
>  Thank you and regards,
>
> Emmanuel
>
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: TomEE 8.0.0 MP version compliance ?

[Jonathan Gallimore]

Hi

David posted on the dev@ mailing list a couple of days ago:
http://tomee-openejb.979440.n4.nabble.com/DISCUSSION-Completing-Jakarta-EE-8-and-MicroProfile-3-0-8-0-x-or-8-1-x-td4690606.html

Jakarta EE 8 status.  TomEE 8.0.0 is to my understanding about 90% complete
with the Web Profile.  Open question is where do we want to do the work to
finish Jakarta EE 8 compliance?  In the past discussions (2 years ago),
there was a preference to kick out TomEE 7 not certified and aim at a 7.1
for certification.  We didn't end up getting the Java EE 7 TCK, but do we
want to follow this path for Jakarta EE 8? (leave 8.0.x stable fixes only,
do compliance work in a future 8.1?).  That would mean trunk would most
likely need to updated to 8.1.0-SNAPSHOT.

MicroProfile status.  TomEE 8.0.0 is MicroProfile 2.1 compliant.  Making it
MicroProfile 3.0 compliant involves a major upgrade from OpenTracing 1.x to
2.x and a breaking change to update to MicroProfile Metrics 2.x.  Do we
want to do this in 8.0.x or push this in an 8.1.x? (as noted above, would
most likely mean we need to update trunk to 8.1.0-SNAPSHOT).

I appreciate folks who are only on the user@ list probably didn't see this.
I'd encourage you to post your thoughts either on David's original post, or
here. I don't know that I have a strong view, but I'd prefer fewer branches
to maintain rather than more. I think feedback from the community,
particularly those using MicroProfile and would therefore be impacted by
the breaking changes to move to MP 3.0 would be very much appreciated.

Jon

On Wed, Sep 25, 2019 at 11:35 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello everyone,
>
> Any answer to the question below ?
> I have another one: what about Java EE/Jakarta EE 8 compliancy for TomEE 8
> ?
>
> Best Regards.
>
> From: COURTAULT Francois
> Sent: lundi 23 septembre 2019 08:38
> To: users@tomee.apache.org
> Subject: TomEE 8.0.0 MP version compliance ?
>
> Hello every one,
>
> Congrats for the 8.0.0 release :)
> They are some questions about  production usage : I have the same concern.
>
> Just want also to know if TomEE 8 is MP 2.0, 2.1 or 2.2 compliant: could
> you please provide this information ?
>
> Best Regards.
>
>
>
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: Tomee 7.1.1: when there is an exception during JAXB marshaling, an incomplete response is sent with a 200 code

[Jonathan Gallimore]

Hi

Thanks for reporting this. I haven't tried your code, and I'll give it a go
today - does this happen consistently or randomly when accessing this
endpoint?

Jon

On Wed, Sep 25, 2019 at 12:50 AM Kean Erickson 
wrote:

> I would file this in JIRA but I'm having login troubles at the minute, I
> want to put this here in case I forget because it definitely seems like a
> bug, albeit one that only happens in a buggy usecase. The line "for (String
> s : stuffs)" below creates an NPE, but the problem is that the response is
> sent back with as a 200 and a clipped body.. which is simply "[{". It
> stopped generating the response body when the property getter method was
> hit.
>
>
> My resource:
>
>
> @GET
> @ApiOperation(value = "Get stuff")
> @Produces(MediaType.APPLICATION_JSON)
> public List list(@Context HttpServletResponse response) {
> TestDO stuff = new TestDO();
> stuff.setId(1);
>
> List things = new ArrayList<>();
> things.add(stuff);
> return things;
> }
>
> My data object:
>
> @XmlRootElement(name = "Test")
> @XmlAccessorType(XmlAccessType.FIELD)
> @ApiModel(value = "Test", description = "Test object")
> public class TestDO {
>
> private int id;
> private List stuffs = null;
>
> /**
>  * Empty constructor, required by JAXB.
>  */
> public TestDO() {
> }
>
> public TestDO(int id, String stuffs) {
> this.id = id;
> }
>
> public int getId() {
> return id;
> }
>
> public void setId(int id) {
> this.id = id;
> }
>
> public List getStuffs() {
> for (String s : stuffs)
> System.out.println(s);
> return stuffs;
> }
>
> public void setStuffs(List stuffs) {
> this.stuffs = null;
> }
>
> }
>
>
>
> This error is shown in log when this happens:
>
> 24-Sep-2019 16:42:53.779 SEVERE [ouc5]
> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem Problem with
> writing the data, class java.util.ArrayList, ContentType: application/json
>

Re: Does TomEE 8.0.0 run on Java 11?

[Jonathan Gallimore]

The short answer is yes - TomEE 8.0.0 should work fine on Java 11. We
definitely want to know about your issue and dig into it.

Can you provide your boot output? I did just double check with a vanilla
TomEE 8.0.0 Plus and OpenJDK 11 from AdoptOpenJDK on my Mac here - its
booted fine. Output is here:
https://gist.github.com/jgallimore/27997af50014229b702cf8b5710563ec

I have actually successfully booted TomEE 8 on a self-built JDK 13 as well.
I wouldn't expect it to work with apps whose classes are compiled with Java
13 as a target as I suspect that will need an ASM update, but it did boot
and run an application.

Jon

On Tue, Sep 24, 2019 at 9:44 PM Paul Carter-Brown
 wrote:

> Hi,
>
> Does tomEE 8.0.0 support OpenJDK 11? I've tried and get errors upon boot.
> Will elaborate if it is supposed to support java 11.
>
> Paul
>

Re: Openejb standalone

[Jonathan Gallimore]

I think we still put the standalone server in Maven, but it shouldn't be in
the dist area or on the website for 8.0.0. Same for the .war files.

Jon

On Mon, 23 Sep 2019, 17:56 Jean-Louis Monteiro, 
wrote:

> I double check in the last TomEE 8.0.0 final and looks like there is the
> same issue happening.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Sep 23, 2019 at 9:03 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Hi,
> >
> > Thanks for reporting the issue.
> > I'll download it and have a look quickly to see if I can point out
> > something.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Mon, Sep 23, 2019 at 6:23 AM Bruce Beaumont <
> bruce.beaum...@makro.co.za>
> > wrote:
> >
> >> HI
> >>
> >> I have downloaded and extracted the latest openejb standalone (7.1.1)
> >> When I run it (bin/openejb start) it does not start and throws the
> >> following stack trace.
> >> I have tried this on Linux and OSX with a variety of Java version 8
> >> (Openjdk and oracle)
> >>
> >> Is there something else I need to add to the class path or configure?
> >>
> >>
> >> INFO: Creating SecurityService(id=Default Security Service)
> >>
> >> org.apache.openejb.OpenEJBException:
> >> org.apache.xbean.recipe.ConstructionException: Error invoking
> constructor:
> >> public org.apache.openejb.core.security.SecurityServiceImpl(): Error
> >> invoking constructor: public
> >> org.apache.openejb.core.security.SecurityServiceImpl()
> >>
> >> at
> >> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:497)
> >>
> >> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:150)
> >>
> >> at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> >>
> >> at org.apache.openejb.server.Server.init(Server.java:65)
> >>
> >> at org.apache.openejb.server.Main.initServer(Main.java:154)
> >>
> >> at org.apache.openejb.server.Main.main(Main.java:128)
> >>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >>
> >> at org.apache.openejb.cli.MainImpl.main(MainImpl.java:149)
> >>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >>
> >> at org.apache.openejb.cli.Bootstrap.main(Bootstrap.java:189)
> >>
> >> Caused by: org.apache.xbean.recipe.ConstructionException: Error invoking
> >> constructor: public
> org.apache.openejb.core.security.SecurityServiceImpl()
> >>
> >> at
> >>
> org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:979)
> >>
> >> at
> >>
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:279)
> >>
> >> at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
> >>
> >> at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
> >>
> >> at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49)
> >>
> >> at
> >>
> org.apache.openejb.assembler.classic.Assembler.createSecurityService(Assembler.java:3533)
> >>
> >> at
> >>
> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:566)
> >>
> >> at
> >> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:484)
> >>
> >> ... 15 more
> >>
> >> Caused by: java.lang.NoClassDefFoundError:
> >> org/apache/geronimo/osgi/locator/ProviderLocator
> >>
> >> at
> >>
> javax.security.jacc.PolicyConfigurationFactory$1.run(PolicyConfigurationFactory.java:89)
> >>
> >> at java.security.AccessController.doPrivileged(Native Method)
> >>
> >> at
> >>
> javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory(PolicyConfigurationFactory.java:80)
> >>
> >> at
> >>
> org.apache.openejb.core.security.AbstractSecurityService.installJacc(AbstractSecurityService.java:352)
> >>
> >> at
> >>
> org.apache.openejb.core.security.AbstractSecurityService.(AbstractSecurityService.java:78)
> >>
> >> at
> >>
> org.apache.openejb.core.security.SecurityServiceImpl.(SecurityServiceImpl.java:46)
> >>
> >> at
> >>
> org.apache.openejb.core.security.SecurityServiceImpl.(SecurityServiceImpl.java:42)
> >>
> >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> >>
> >> at
> >>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> >>
> >> at
> >>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>
> >> at 

Re: HikariCp to set JtaManaged

[Jonathan Gallimore]

We'll need to wire it into a ManagedConnection. Not sure how to do that off
the top of my head, but I'm working in that area on Monday, so I'll help
you out.

Jon

On Fri, 28 Jun 2019, 22:18 Kalyan,  wrote:

> Hello,
> Does Hikari supports JTA ?
>
> In the openejb how can i set to JtaManaged = true for the HikariCP?
>
> p.put("DS1",
>
> "new://Resource?type=javax.sql.DataSource=org.superbiz.ConnectionPoolFactory=create");
> p.put("DS1.JdbcDriver", "oracle.jdbc.OracleDriver");
> p.put("DS1.JdbcUrl", "jdbc:oracle:thin:@xx1521/rwdb");
> p.put("DS1.UserName", "admin");
> p.put("DS1.Password", "xx");
> p.put("DS1.LogSql", "true");
> p.put("DS1.JtaManaged", "true");
>
> Even though i set to true. Looks like its ignored.
>
> WARN - unused property 'JtaManaged' for resource 'DS1'
>
>
>
> public class ConnectionPoolFactory {
> private Properties properties;
> public Properties getProperties() {
> return properties;
> }
> public void setProperties(final Properties properties) {
> this.properties = properties;
> }
>
> public Object create() {
> HikariConfig hikariConfig = new HikariConfig();
> int connIdleTimeInMinutes = 10;
> int connWaitTimeInMilliSec = 1000;
> // Initialize connection pool
>
> hikariConfig.setPoolName(properties.getProperty("HikariDS.PoolName"));
> hikariConfig.setJdbcUrl(properties.getProperty("JdbcUrl"));
> hikariConfig.setAutoCommit(false);
> hikariConfig.setUsername(properties.getProperty("Username"));
> hikariConfig.setPassword(properties.getProperty("Password"));
>
>
> hikariConfig.setMaximumPoolSize(Integer.parseInt(properties.getProperty("MaximumPoolSize",
> "20")));
>
>
> hikariConfig.setMinimumIdle(Integer.parseInt(properties.getProperty("MinimumIdle",
> "20")));
> hikariConfig.setIdleTimeout(connIdleTimeInMinutes * 60 * 1000);
> hikariConfig.setConnectionTimeout(connWaitTimeInMilliSec);
> HikariDataSource resource = new HikariDataSource(hikariConfig);
> return resource;
> }
> }
>
>
> Due to this the transactions are not performing. As it suppose to.
> Please help me with this.
>
> thanks
> Kalyan
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
>

Re: TomEE 7.0.6 and 7.1.1 releases

[Jonathan Gallimore]

At the time of the rollback, the artifacts hadn't been released, and
therefore the change ended up breaking the build. I see no reason why we
can't update this to 3.1.18 now, and I'll commit that change.

Jon

On Thu, Jun 27, 2019 at 4:31 PM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> Any reason for the rollback ?
>
> I ask this question because we have a CXF issue (CXF-7869) which has been
> fixed in cxf 3.1.18 when using TomEE 7.1.0.
> So I would be pleased to have this version included in TomEE 7.x.
>
> Best Regards.
>
> -Original Message-
> From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> Sent: mardi 25 juin 2019 22:20
> To: users@tomee.apache.org
> Cc: d...@tomee.apache.org
> Subject: Re: TomEE 7.0.6 and 7.1.1 releases
>
> Correct - apologies for the mistake. We'll update that ticket and
> (hopefully) it'll drop off the release notes.
>
> On Tue, Jun 25, 2019 at 9:12 PM Jonathan S. Fisher 
> wrote:
>
> > IIRC that was my patch and we rolled it back...
> >
> > On Tue, Jun 25, 2019 at 2:11 PM COURTAULT Francois <
> > francois.courta...@thalesgroup.com> wrote:
> >
> > > Hello Jonathan,
> > >
> > > In the release note you provide, it's written: [TOMEE-2268] -
> > > Upgrade to CXF to 3.1.18 But after downloading TomEE 7.1.1 web
> > > profile, TomEE 7.1.1 micro profile and TomEE 7.1.1 plus, and looking
> > > under the lib folder, I only see:
> > > cxf-core-3.1.17.jar and cxf-rt-*-3.1.17.jar.
> > > No 3.1.18 at all.
> > >
> > > Mistake ?
> > >
> > > Best Regards.
> > >
> > >
> > > -Original Message-
> > > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> > > Sent: vendredi 21 juin 2019 15:12
> > > To: users@tomee.apache.org; d...@tomee.apache.org
> > > Subject: TomEE 7.0.6 and 7.1.1 releases
> > >
> > > Hi All,
> > >
> > > I'm pleased to announce that new releases of TomEE - versions 7.0.6
> > > and
> > > 7.1.1 - are now available. These are maintenance releases of the
> > > 7.0.x
> > and
> > > 7.1.x branches respectively.
> > >
> > > The JIRAs for each release are here:
> > >
> > > 7.0.6:
> > >
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissu
> > es.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D1231232
> > 0%26version%3D12342069data=02%7C01%7CFrancois.COURTAULT%40gemalto
> > .com%7C37c9b3e7ef43408c267408d6f9aa8312%7C37d0a9db7c464096bfe31add5b49
> > 5d6d%7C0%7C0%7C636970908073437656sdata=w%2BE%2FfaAS9mOQAfaF2TflFn
> > lDRxmDlsuTVGyWBX46UHo%3Dreserved=0
> > >
> > > 7.1.1:
> > >
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissu
> > es.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D1231232
> > 0%26version%3D12344119data=02%7C01%7CFrancois.COURTAULT%40gemalto
> > .com%7C37c9b3e7ef43408c267408d6f9aa8312%7C37d0a9db7c464096bfe31add5b49
> > 5d6d%7C0%7C0%7C636970908073437656sdata=Jo6DO9MIcyOMZzCFi1h0SNtk0a
> > %2FvUTSYZFGYNdZn%2FAc%3Dreserved=0
> > >
> > > Jon
> > > 
> > >  This message and any attachments are intended solely for the
> > > addressees and may contain confidential information. Any
> > > unauthorized use or disclosure, either whole or partial, is prohibited.
> > > E-mails are susceptible to alteration. Our company shall not be
> > > liable
> > for
> > > the message if altered, changed or falsified. If you are not the
> > > intended recipient of this message, please delete it and notify the
> sender.
> > > Although all reasonable efforts have been made to keep this
> > > transmission free from viruses, the sender will not be liable for
> > > damages caused by a transmitted virus.
> > >
> >
> >
> > --
> > Jonathan | exabr...@gmail.com
> > Pessimists, see a jar as half empty. Optimists, in contrast, see it as
> > half full.
> > Engineers, of course, understand the glass is twice as big as it needs
> > to be.
> >
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: TomEE 7.0.6 and 7.1.1 releases

[Jonathan Gallimore]

Correct - apologies for the mistake. We'll update that ticket and
(hopefully) it'll drop off the release notes.

On Tue, Jun 25, 2019 at 9:12 PM Jonathan S. Fisher 
wrote:

> IIRC that was my patch and we rolled it back...
>
> On Tue, Jun 25, 2019 at 2:11 PM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
>
> > Hello Jonathan,
> >
> > In the release note you provide, it's written: [TOMEE-2268] - Upgrade to
> > CXF to 3.1.18
> > But after downloading TomEE 7.1.1 web profile, TomEE 7.1.1 micro profile
> > and TomEE 7.1.1 plus, and looking under the lib folder, I only see:
> > cxf-core-3.1.17.jar and cxf-rt-*-3.1.17.jar.
> > No 3.1.18 at all.
> >
> > Mistake ?
> >
> > Best Regards.
> >
> >
> > -Original Message-
> > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
> > Sent: vendredi 21 juin 2019 15:12
> > To: users@tomee.apache.org; d...@tomee.apache.org
> > Subject: TomEE 7.0.6 and 7.1.1 releases
> >
> > Hi All,
> >
> > I'm pleased to announce that new releases of TomEE - versions 7.0.6 and
> > 7.1.1 - are now available. These are maintenance releases of the 7.0.x
> and
> > 7.1.x branches respectively.
> >
> > The JIRAs for each release are here:
> >
> > 7.0.6:
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D12312320%26version%3D12342069data=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7C2dba21e784d94e84ec1908d6f64a1b3b%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636967195474769730sdata=mwJ5H7GANFODrnuQxk62sf3m18OuFDAtjPaJDBcj4vQ%3Dreserved=0
> >
> > 7.1.1:
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D12312320%26version%3D12344119data=02%7C01%7CFrancois.COURTAULT%40gemalto.com%7C2dba21e784d94e84ec1908d6f64a1b3b%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636967195474769730sdata=vWlP3n7BSzQxZjXsBrHOdnAo4mUdDBVdXL1D6TI5uiE%3Dreserved=0
> >
> > Jon
> > 
> >  This message and any attachments are intended solely for the addressees
> > and may contain confidential information. Any unauthorized use or
> > disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> for
> > the message if altered, changed or falsified. If you are not the intended
> > recipient of this message, please delete it and notify the sender.
> > Although all reasonable efforts have been made to keep this transmission
> > free from viruses, the sender will not be liable for damages caused by a
> > transmitted virus.
> >
>
>
> --
> Jonathan | exabr...@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
> full.
> Engineers, of course, understand the glass is twice as big as it needs to
> be.
>