Re: setting up the hikari connection pool with tomee

[Emmanuel Touzery]

Hello,

 thank you for the answer!

 These links focus on the DataSource approach, which I've failed to make work 
as well. What I did get to work was through the persistence.xml, completely 
bypassing TOMEE's datasources (as described in the stackoverflow link I gave), 
but then I'm not sure whether UserTransactions and container-managed 
transactions are supported (at first sight things seem to work, but the devil 
is in the details).

 I hope maybe someone can answer on that?

 Thank you again,

Emmanuel

- Original Message -
From: "Zowalla, Richard" 
To: users@tomee.apache.org
Sent: Tuesday, 23 March, 2021 20:28:01
Subject: Re: setting up the hikari connection pool with tomee

Hi,

there were some discussions related to HikariCP on the lists a few days
ago [1], [2], and [3]. I would try with [1] and [2]. Hope it helps.

Gruss
Richard


[1] 
http://tomee-openejb.979440.n4.nabble.com/HikariCP-configuration-in-TomEE-td4678838.html
[2] 
http://tomee-openejb.979440.n4.nabble.com/Configuring-HikariCP-with-OpenEjb-need-inputs-td4691576.html
[3] 
http://tomee-openejb.979440.n4.nabble.com/HikariCp-to-set-JtaManaged-td4689571.html

Am Dienstag, den 23.03.2021, 17:01 +0100 schrieb Emmanuel Touzery:
> Hello,
> 
>  I'm trying to configure hibernate+hikarip connection pool for
> TOMEE.
> 
>  I made it work without issues (at first sight), by configuring 
> everything in the persistence.xml, basically as described in the
> answer 
> to this stackoverflow question:
> 
> https://stackoverflow.com/questions/49366198/how-to-configure-hikaricp-via-tomee-xml
> 
>  I would rather configure it through TOMEE data sources, as I'm
> used 
> to, in the conf/tomee.xml or conf/context.xml
> 
>  I've attempted to do so, also helping myself with 
> https://github.com/brettwooldridge/HikariCP/wiki/JNDI-DataSource-Factory-(Tomcat,-etc.)
> 
>  But I didn't manage to. I got errors like described in the 
> stackoverflow question, but also some others.
> 
>  I have two questions:
> 
>  1. is it supported to specify the connection purely through the
> persistence.xml without any datasource in the tomee.xml? Will
> UserTransactions, container-managed transactions work as
> expected?
>  2. could I configure tomee+hibernate+hikaricp through a tomee
> datasource? If so, how? (One reason I'd rather have a datasource
> is
> also so that it's possible to edit the  JDBC configuration (eg
> IP,
> password, connection pool size..) without redeploying the
> application (because the persistence.xml is in the war)
> 
>  Thank you!
> 
> Emmanuel
> 
>

setting up the hikari connection pool with tomee

[Emmanuel Touzery]

Hello,

    I'm trying to configure hibernate+hikarip connection pool for TOMEE.

    I made it work without issues (at first sight), by configuring 
everything in the persistence.xml, basically as described in the answer 
to this stackoverflow question:


https://stackoverflow.com/questions/49366198/how-to-configure-hikaricp-via-tomee-xml

    I would rather configure it through TOMEE data sources, as I'm used 
to, in the conf/tomee.xml or conf/context.xml


    I've attempted to do so, also helping myself with 
https://github.com/brettwooldridge/HikariCP/wiki/JNDI-DataSource-Factory-(Tomcat,-etc.)


    But I didn't manage to. I got errors like described in the 
stackoverflow question, but also some others.


    I have two questions:

1. is it supported to specify the connection purely through the
   persistence.xml without any datasource in the tomee.xml? Will
   UserTransactions, container-managed transactions work as expected?
2. could I configure tomee+hibernate+hikaricp through a tomee
   datasource? If so, how? (One reason I'd rather have a datasource is
   also so that it's possible to edit the  JDBC configuration (eg IP,
   password, connection pool size..) without redeploying the
   application (because the persistence.xml is in the war)

    Thank you!

Emmanuel

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

[Emmanuel Touzery]

Hello,

    I have enabled also "logAbandoned" and I see some connections are 
getting abandoned:


22-Jan-2021 10:55:34.306 WARNING [Tomcat JDBC Pool 
Cleaner[54495403:1611312334268]] 
org.apache.tomcat.jdbc.pool.ConnectionPool.abandon Connection has been 
abandoned 
PooledConnection[org.postgresql.jdbc.PgConnection@28094e6f]:java.lang.Exception


    However right now I triggered the issue and no connections are 
getting abandoned even after 12 minutes, and I can see that the 
application won't recover until it's restarted.


    Any suggestion?

    Thank you,

Emmanuel

PS: the way i'm reading the "removeAbandoned" documentation, shouldn't 
this setting be named "removeLongRunningConnections"?


On 22/01/2021 11:28, Emmanuel Touzery wrote:

Hello,

Note that also setting:

removeAbandoned = true
removeAbandonedTimeout = 60

does not help. Even 6 minutes after the the disconnection, we keep 
getting "PooledConnection has already been closed." exceptions.


Regards,

Emmanuel

On 22/01/2021 09:48, Emmanuel Touzery wrote:

Hello,

    if I understand you correctly, you're suggesting to remove these 
settings:


 removeAbandoned = true
 removeAbandonedTimeout = 4400

    I did that now, we don't really need them. Unfortunately I can 
still reproduce the issue even after removing both settings.


    We are aware of the memory leak yes, we stumbled on it before a 
released version of tomee fixed it, so we disabled bean validation. 
We'll reenable it when we upgrade TOMEE.


    So that means for now we're still unsure what's causing this 
issue for us :-(


    Thank you!

Emmanuel

On 19/01/2021 19:18, Kean Erickson wrote:
Hi Emmanual, I believe that is how connections that were discarded 
due to
removeAbandoned = true. In an ideal setup you shouldnt need that 
flag or
its timeout, becaise the transactions should be too fast to go that 
long


Also some versions before tomee 8.0.5 have a memory leak in the 
version of

bval that is used. Not sure if 8.0.1 has that problem version but try
updatng tomee to 8.0.5

On Tue, Jan 19, 2021, 2: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(

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

[Emmanuel Touzery]

Hello,

Note that also setting:

removeAbandoned = true
removeAbandonedTimeout = 60

does not help. Even 6 minutes after the the disconnection, we keep 
getting "PooledConnection has already been closed." exceptions.


Regards,

Emmanuel

On 22/01/2021 09:48, Emmanuel Touzery wrote:

Hello,

    if I understand you correctly, you're suggesting to remove these 
settings:


 removeAbandoned = true
 removeAbandonedTimeout = 4400

    I did that now, we don't really need them. Unfortunately I can 
still reproduce the issue even after removing both settings.


    We are aware of the memory leak yes, we stumbled on it before a 
released version of tomee fixed it, so we disabled bean validation. 
We'll reenable it when we upgrade TOMEE.


    So that means for now we're still unsure what's causing this issue 
for us :-(


    Thank you!

Emmanuel

On 19/01/2021 19:18, Kean Erickson wrote:
Hi Emmanual, I believe that is how connections that were discarded 
due to

removeAbandoned = true. In an ideal setup you shouldnt need that flag or
its timeout, becaise the transactions should be too fast to go that long

Also some versions before tomee 8.0.5 have a memory leak in the 
version of

bval that is used. Not sure if 8.0.1 has that problem version but try
updatng tomee to 8.0.5

On Tue, Jan 19, 2021, 2: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(DisposableConnecti

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

[Emmanuel Touzery]

Hello,

    if I understand you correctly, you're suggesting to remove these 
settings:


 removeAbandoned = true
 removeAbandonedTimeout = 4400

    I did that now, we don't really need them. Unfortunately I can 
still reproduce the issue even after removing both settings.


    We are aware of the memory leak yes, we stumbled on it before a 
released version of tomee fixed it, so we disabled bean validation. 
We'll reenable it when we upgrade TOMEE.


    So that means for now we're still unsure what's causing this issue 
for us :-(


    Thank you!

Emmanuel

On 19/01/2021 19:18, Kean Erickson wrote:

Hi Emmanual, I believe that is how connections that were discarded due to
removeAbandoned = true. In an ideal setup you shouldnt need that flag or
its timeout, becaise the transactions should be too fast to go that long

Also some versions before tomee 8.0.5 have a memory leak in the version of
bval that is used. Not sure if 8.0.1 has that problem version but try
updatng tomee to 8.0.5

On Tue, Jan 19, 2021, 2: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
jav

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

[Emmanuel Touzery]

Hello,

    I have to say it's not necessarily about the failover. We can also 
see this if there is something wrong with the connection to the server. 
I believe including if the SQL server is restarted.


    My understanding is that it's normal that there is an error, but I 
would expect TOMEE to recover -- to stop handling to the application a 
JDBC connection which is in fact closed and has shown itself in the past 
to be invalid. Especially since we configure a validation query.


    This is otherwise Enterprise DB 12. My understanding is that it's 
mostly a rebranded Postgresql. We are using the normal postgresql 
driver, although an older version (we didn't try a newer version, 
assuming that's not related to the issue at hand). We're using the 
postgresql jdbc driver version 42.1.4.

    For the failover, we're using EFM:
https://www.enterprisedb.com/edb-docs/d/edb-postgres-failover-manager/user-guides/user-guide/3.7/using_efm_utility.html

    There is a "virtual IP" that we connect to through JDBC, and it 
links to one or the other true IP, over 3 EDB nodes.


    We actually don't get an issue at every switchover. Even load 
testing the app (with a relatively light load though), we need ~4 
failovers to reproduce the issue. Meaning, an OK failover means that we 
get JDBC errors during the failover, but then the application recovers. 
A bad failover is when we keep getting errors long after the failover 
finished. I think it's tied to whether we had a compromised connection 
in the pool before the failover.


    Thank you for the answer!

Emmanuel

On 19/01/2021 13:26, Jonathan Gallimore wrote:

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)

connection pool: poisoned connection not being removed from pool

[Emmanuel Touzery]

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 
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:149) 

    at 
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:176) 


    ... 88 more

sometimes getting null when injecting TransactionSynchronizationRegistry

[Emmanuel Touzery]

Hello,

    we're injecting TransactionSynchronizationRegistry in some error 
handling path in our application:


    @Resource
    private TransactionSynchronizationRegistry 
transactionSynchronizationRegistry;


    What we do is that we store some meta-data which is valid for the 
SQL transaction scope in that registry, so that if there is an error 
down the line, we can tie the error to this meta-data. And this works 
fine but after days of running a production workload, we get errors 
because this injection fails.


    We get this error concurrently on multiple threads:

17-Jun-2020 10:54:53.809 WARNING [managed-thread-18] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry17-Jun-2020 
10:54:53.810 WARNING [managed-thread-8] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.810 WARNING [managed-thread-16] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.809 WARNING [managed-thread-7] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.811 WARNING [managed-thread-16] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.812 INFO [managed-thread-16] 
com.littransit.rabbitmq.RabbitChangesPublisher.handleEventInternal em: 
org.apache.openejb.persistence.JtaEntityManager@619cca3f - managed-thread-16
17-Jun-2020 10:54:53.812 WARNING [managed-thread-10] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.812 WARNING [managed-thread-18] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry


And very shortly afterwards:

17-Jun-2020 10:54:53.814 SEVERE [managed-thread-16] 
com.littransit.rabbitmq.RabbitChangesPublisher.handleEventInternal 
Failed publishing rabbit message

    java.lang.NullPointerException
    at 
com.littransit.rabbitmq.RabbitChangesPublisher.writeRabbitOutboxAccountItem(RabbitChangesPublisher.java:50)


And this is a NPE reading the transactionSynchronizationRegistry 
injected field.


Shortly afterwards we see this issue again in other managed threads:

17-Jun-2020 10:54:53.836 WARNING [managed-thread-12] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.843 WARNING [managed-thread-12] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry
17-Jun-2020 10:54:53.844 WARNING [managed-thread-19] 
org.apache.openejb.cdi.CdiResourceInjectionService.fillInjectionProperties 
Injection data not found in JNDI context: 
jndiName='comp/env/com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry', 
target=com.littransit.rabbitmq.RabbitChangesPublisher/transactionSynchronizationRegistry


This is happening in managed threads that 

is tomee8 for evaluation only?

[Emmanuel Touzery]

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

Re: tomee+activemq: JMS reading sometimes hang with full queue

[Emmanuel Touzery]

Hello,

    noone has any suggestion?

    Regards,

emmanuel

On 22/10/2018 16:04, Emmanuel Touzery wrote:

Hello,

    we have a tomee+ 7.0.3 installation with activemq, using kahadb as 
a persistent message storage. We have an activemq.xml, we plugged it 
though :


BrokerXmlConfig = xbean:file:/opt/app/tomee/conf/activemq.xml

    in the tomee.xml. The activemq broken runs within TOMEE:

ServerUrl   =  tcp://127.0.0.1:61616

    We have a prefetch of 2000:

uri="nio://0.0.0.0:61616?jms.prefetchPolicy.all=2000"/>


    We use mKaha. We disabled flow control.

    So that everything would work, we had to add a couple of JARs in 
the TOMEE lib folder:


activemq-spring-5.14.3.jar
spring-beans-3.2.9.RELEASE.jar
spring-context-3.2.9.RELEASE.jar
spring-core-3.2.9.RELEASE.jar
spring-expression-3.2.9.RELEASE.jar
spring-web-3.2.9.RELEASE.jar
xbean-spring-3.9.jar

    We are "reading" from JMS through message-driven beans, 
implementing MessageListener and with @MessageDriven annotations.


    The application is pretty simple... Receive the data from 
HTTP/JSON, and store it to SQL (through hibernate).


    Everything works fine as long as the traffic is normal. However 
when there is a surge of incoming traffic, sometimes the JMS consumers 
stop getting called, and the queue only grows. The issue does not get 
fixed until TOMEE is restarted. And then we've seen the issue 
re-appear again maybe 40 minutes later. After a while, the server 
clears the queue and everything is fine again.


    We took a jstack thread dump of the application when it's in that 
"hung" state:

https://www.dropbox.com/s/p8wy7uz6inzsmlj/jstack.txt?dl=0

    What's interesting is that writes fall quite fast, and in steps, 
in general not all at once, but as well not slowly:

https://www.dropbox.com/s/nhm5s2zc7r9mk9z/graph_writes.png?dl=0

    After a restart things are fine again immediately.

    We're not sure what is the cause. From what we can tell from the 
thread dump, the consumers are idle, they just don't get notified that 
work is available. The server is certainly aware there are items in 
the queue, we monitor the queue through JMX and the queue size keeps 
growing during these episodes. We don't see anything out of the 
ordinary in the logs. We looked at thread IDs for consumers just 
before the issue, it doesn't look like the consumers get some deadlock 
one after the other for instance. It seems like a bunch of them are 
called in the last minute before the dropoff for instance. Also, 
during a blackout the JDBC pool usage is at 0 according to our JMX 
monitoring, so it doesn't seem to be about a deadlocked JDBC connection.


    We did notice the following activemq warnings in the log file, but 
the timestamps don't match with any particular events and from what we 
found out, they don't seem to be particularly worrying or likely to be 
related to the issue:


WARNING [ActiveMQ Journal Checkpoint Worker] 
org.apache.activemq.store.kahadb.MessageDatabase.getNextLocationForAckForward 
Failed to load next journal location: null


WARNING [ActiveMQ NIO Worker 6] 
org.apache.activemq.broker.TransportConnection.serviceTransportException 
Transport Connection to: tcp://127.0.0.1:37024 failed: 
java.io.EOFException


    Do you have any suggestion to try to fix this issue (which we 
sadly can't reproduce at will.. and it only happens pretty rarely)? 
Should we rather ask on the activemq mailing list?


    Regards,

emmanuel

Re: tomee+activemq: JMS reading sometimes hang with full queue

[Emmanuel Touzery]

Hello,

    sure! Regarding the runtime, we also have the postgresql driver in 
lib, I think that's all. Hibernate is in our WAR for instance.


    here's the activemq.xml =>
https://www.dropbox.com/s/ukttiupouyiv779/activemq.xml?dl=0

    tomee.xml =>
https://www.dropbox.com/s/452s6d6vknp59a4/tomee.xml?dl=0

    startup log =>
https://www.dropbox.com/s/52uqfatlisodayg/catalina.2018-10-21.log?dl=0

    Regards,

Emmanuel

On 22/10/2018 16:33, exabrial12 wrote:

Hello Emmanuel, can we see the full log of the tomee startup, the full
tomee.xml, the full activemq.xml, and any other differences between your
runtime and the downloaded runtime? thanks!



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html

tomee+activemq: JMS reading sometimes hang with full queue

[Emmanuel Touzery]

Hello,

    we have a tomee+ 7.0.3 installation with activemq, using kahadb as 
a persistent message storage. We have an activemq.xml, we plugged it 
though :


BrokerXmlConfig = xbean:file:/opt/app/tomee/conf/activemq.xml

    in the tomee.xml. The activemq broken runs within TOMEE:

ServerUrl   =  tcp://127.0.0.1:61616

    We have a prefetch of 2000:

uri="nio://0.0.0.0:61616?jms.prefetchPolicy.all=2000"/>


    We use mKaha. We disabled flow control.

    So that everything would work, we had to add a couple of JARs in 
the TOMEE lib folder:


activemq-spring-5.14.3.jar
spring-beans-3.2.9.RELEASE.jar
spring-context-3.2.9.RELEASE.jar
spring-core-3.2.9.RELEASE.jar
spring-expression-3.2.9.RELEASE.jar
spring-web-3.2.9.RELEASE.jar
xbean-spring-3.9.jar

    We are "reading" from JMS through message-driven beans, 
implementing MessageListener and with @MessageDriven annotations.


    The application is pretty simple... Receive the data from 
HTTP/JSON, and store it to SQL (through hibernate).


    Everything works fine as long as the traffic is normal. However 
when there is a surge of incoming traffic, sometimes the JMS consumers 
stop getting called, and the queue only grows. The issue does not get 
fixed until TOMEE is restarted. And then we've seen the issue re-appear 
again maybe 40 minutes later. After a while, the server clears the queue 
and everything is fine again.


    We took a jstack thread dump of the application when it's in that 
"hung" state:

https://www.dropbox.com/s/p8wy7uz6inzsmlj/jstack.txt?dl=0

    What's interesting is that writes fall quite fast, and in steps, in 
general not all at once, but as well not slowly:

https://www.dropbox.com/s/nhm5s2zc7r9mk9z/graph_writes.png?dl=0

    After a restart things are fine again immediately.

    We're not sure what is the cause. From what we can tell from the 
thread dump, the consumers are idle, they just don't get notified that 
work is available. The server is certainly aware there are items in the 
queue, we monitor the queue through JMX and the queue size keeps growing 
during these episodes. We don't see anything out of the ordinary in the 
logs. We looked at thread IDs for consumers just before the issue, it 
doesn't look like the consumers get some deadlock one after the other 
for instance. It seems like a bunch of them are called in the last 
minute before the dropoff for instance. Also, during a blackout the JDBC 
pool usage is at 0 according to our JMX monitoring, so it doesn't seem 
to be about a deadlocked JDBC connection.


    We did notice the following activemq warnings in the log file, but 
the timestamps don't match with any particular events and from what we 
found out, they don't seem to be particularly worrying or likely to be 
related to the issue:


WARNING [ActiveMQ Journal Checkpoint Worker] 
org.apache.activemq.store.kahadb.MessageDatabase.getNextLocationForAckForward 
Failed to load next journal location: null


WARNING [ActiveMQ NIO Worker 6] 
org.apache.activemq.broker.TransportConnection.serviceTransportException 
Transport Connection to: tcp://127.0.0.1:37024 failed: java.io.EOFException


    Do you have any suggestion to try to fix this issue (which we sadly 
can't reproduce at will.. and it only happens pretty rarely)? Should we 
rather ask on the activemq mailing list?


    Regards,

emmanuel

Re: No Factories configured for this Application. This happens if the faces-initialization does not work at all

[Emmanuel Touzery]

Hello,

    thank you for the answer! To be clear, by duplicate jars, you mean 
in the tomee lib/ folder, or the pom.xml, correct?
    If that's what you mean, I think both are OK, as I wrote in another 
email to this list, in the lib/ folder we've only added the postgresql 
driver, and in the pom.xml the only non-test or provided dependency 
which seemed related was the prettyfaces library, which could have 
possibly caused the issue, and that we removed now.


    Regards,

Emmanuel

On 17/07/18 06:32, Gurkan Erdogdu wrote:

Hello Emmanuel
This exception sometimes (generally) occurred because of duplicate JSF jars
in your application and some classloader issues. Could you please check
your application that has any duplicate JSF (myfaces for example) JARS?
Regards.
Gurkan

On Mon, Jul 16, 2018 at 2:54 PM, Emmanuel Touzery <
emmanuel.touz...@lit-transit.com> wrote:


Hello,

 we have a TOMEE 7.0.3 application, which uses also JMS, which works
without issues. We've recently made a new version of the application (one
of the notable changes is a migration from using the JMS1.1 to the JMS2
API).

 With the new version, we have an issue, but only on our PROD
environment, where we get no errors in the catalina.out log file (but the
application doesn't work), but an error in the localhost log file, the
error being as in the title of the email, I put the info from the localhost
log file at the end of this email.

 I can't put the source on github or something like that,
unfortunately. What is strange is that this error does not occur on our
staging or UAT environments, but it does occur every time (well, we tried
multiple times to restart the application and it failed consistently) on
the PROD environment. We copied the entire PROD tomee folder on another
machine and failed to reproduce the issue. We also tried to simulate
incoming traffic when restarting the application, and run it against a
backup of the PROD database... Somehow we can't reproduce the error. We are
guessing that maybe the PROD traffic is higher than what we can simulate
and some incoming message comes at just the wrong time? But we don't know
for sure.

 Now, studying the issue, we realized that we used to have this in our
src/main/webapp/WEB-INF/faces-config.xml:

http://java.sun.com/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2
001/XMLSchema-instance" xsi:schemaLocation="http://jav
a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
aee/web-facesconfig_2_1.xsd" version="2.1">logincom.lecip.tms.tms_core.application.Loginview


 We believe the JSF version is not correct for JEE7 anymore, in
addition the managed-bean annotation is not necessary, so we changed the
file to now contain:


http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;
   version="2.2">


 Could this be the cause for that error that we saw in our PROD
environment? Or you would think the root cause would be something else? The
problem is that it's pretty difficult for us to experiment with changes
since any deployment on PROD must be first validated on staging and UAT...
Any hints? Is there maybe some logging configuration flag we could activate
to get more information about the error? Or any other place to look to get
more information about the issue?

 The irony is that we use JSF only for the login screen and nowhere
else...

 Regards,

Emmanuel

12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
For security constraints with URL pattern [/*] only the HTTP methods [TRACE
HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
uncovered.
12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
  java.lang.IllegalStateException: No Factories configured for this
Application. This happens if the faces-initialization does not work at all
- make sure that you properly include all configuration settings necessary
for a basic faces application and that all the necessary libs are included.
Also check the logging output of your web application and your container
for any exceptions!
If you did that and find nothing, the mistake might be due to the fact
that you use some special web-containers which do not support registering
context-listeners via TLD files and a context listener is not setup in your
web.xml.
A typical config looks like this;

org.apache.myfaces.webapp.StartupServletCont
extListener


 at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
 at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
 at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
 at org.apache.catali

Re: No Factories configured for this Application. This happens if the faces-initialization does not work at all

[Emmanuel Touzery]

Hello,

    thank you for the advice. Yes it's by checking the web.xml that we 
stumbled upon the prettyfaces dependency which we now removed. I'm 
attaching the web.xml in case you maybe spot another oddity.
    Compared to the lib/ folder from the tomee 7.0.3 distribution, we 
have added in our lib folder only the postgresql driver.


    In terms of the classpath, and apart from the prettyfaces 
dependency which was present when we hit the issue, but that we've 
removed now, all the dependencies which would be suspicious are listed 
as 'provided' or 'test' in the pom, so shouldn't affect anything.


    Regards,

Emmanuel


On 17/07/18 06:36, Romain Manni-Bucau wrote:

Hi

Maybe check your web.xml declaration of faces servlet, you classpath and
webapp lib folder (some jsf api or impl leaking?) and finally ensure when
you redeployed that you cleaned work/, conf/ and other temporary
folders in your catalina.base folder.

Le mar. 17 juil. 2018 00:22, Jean-Louis Monteiro 
a écrit :


Hi,

Thanks for the detailed email with context and useful information.

Is it random, or can you reproduce easily?
Are you using JDK 8?

Regards
Jean-Louis

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

On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
emmanuel.touz...@lit-transit.com> wrote:


Hello,

 we have a TOMEE 7.0.3 application, which uses also JMS, which works
without issues. We've recently made a new version of the application (one
of the notable changes is a migration from using the JMS1.1 to the JMS2
API).

 With the new version, we have an issue, but only on our PROD
environment, where we get no errors in the catalina.out log file (but the
application doesn't work), but an error in the localhost log file, the
error being as in the title of the email, I put the info from the

localhost

log file at the end of this email.

 I can't put the source on github or something like that,
unfortunately. What is strange is that this error does not occur on our
staging or UAT environments, but it does occur every time (well, we tried
multiple times to restart the application and it failed consistently) on
the PROD environment. We copied the entire PROD tomee folder on another
machine and failed to reproduce the issue. We also tried to simulate
incoming traffic when restarting the application, and run it against a
backup of the PROD database... Somehow we can't reproduce the error. We

are

guessing that maybe the PROD traffic is higher than what we can simulate
and some incoming message comes at just the wrong time? But we don't know
for sure.

 Now, studying the issue, we realized that we used to have this in our
src/main/webapp/WEB-INF/faces-config.xml:

http://java.sun.com/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2
001/XMLSchema-instance" xsi:schemaLocation="http://jav
a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
aee/web-facesconfig_2_1.xsd" version="2.1">logincom.lecip.tms.tms_core.application.Loginview


 We believe the JSF version is not correct for JEE7 anymore, in
addition the managed-bean annotation is not necessary, so we changed the
file to now contain:


http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;
   version="2.2">


 Could this be the cause for that error that we saw in our PROD
environment? Or you would think the root cause would be something else?

The

problem is that it's pretty difficult for us to experiment with changes
since any deployment on PROD must be first validated on staging and

UAT...

Any hints? Is there maybe some logging configuration flag we could

activate

to get more information about the error? Or any other place to look to

get

more information about the issue?

 The irony is that we use JSF only for the login screen and nowhere
else...

 Regards,

Emmanuel

12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]


org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods

For security constraints with URL pattern [/*] only the HTTP methods

[TRACE

HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
uncovered.
12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
  java.lang.IllegalStateException: No Factories configured for this
Application. This happens if the faces-initialization does not work at

all

- make sure that you properly include all configuration settings

necessary

for a basic faces application and that all the necessary libs are

included.

Also check the logging output of your web application and your container
for any exceptions!
If you did that and find nothing, the mistake might be due to the fact
that you use some special web-contain

Re: No Factories configured for this Application. This happens if the faces-initialization does not work at all

[Emmanuel Touzery]

Hello,

    we have two products using the same core library. On one product 
we've seen this error once and a restart fixed it. On the other product 
we've had to abort an upgrade, tried to restart the app more than 5 
times and it would fail every time. But we can't "experiment" on that 
environment because it's PROD.

    We are using JDK8 yes.

    Since I wrote that we also realized that we were using prettyfaces 
http://www.ocpsoft.org/prettyfaces/ 3.3.3 although it was not needed 
anymore (affected pom.xml, web.xml, and we had a pretty-config.xml). 
That version 
https://mvnrepository.com/artifact/com.ocpsoft/prettyfaces-jsf2/3.3.3 is 
from 2012 so I'm hoping that may also have been related to our issues 
(being too old for JEE7), but we need to follow the procedure to deploy 
to PROD so I can't be 100% sure yet.


    I'll also send the web.xml in a reply to another mail on this list.

    Thank you for your answer!

Emmanuel

On 17/07/18 00:21, Jean-Louis Monteiro wrote:

Hi,

Thanks for the detailed email with context and useful information.

Is it random, or can you reproduce easily?
Are you using JDK 8?

Regards
Jean-Louis

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

On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
emmanuel.touz...@lit-transit.com> wrote:


Hello,

 we have a TOMEE 7.0.3 application, which uses also JMS, which works
without issues. We've recently made a new version of the application (one
of the notable changes is a migration from using the JMS1.1 to the JMS2
API).

 With the new version, we have an issue, but only on our PROD
environment, where we get no errors in the catalina.out log file (but the
application doesn't work), but an error in the localhost log file, the
error being as in the title of the email, I put the info from the localhost
log file at the end of this email.

 I can't put the source on github or something like that,
unfortunately. What is strange is that this error does not occur on our
staging or UAT environments, but it does occur every time (well, we tried
multiple times to restart the application and it failed consistently) on
the PROD environment. We copied the entire PROD tomee folder on another
machine and failed to reproduce the issue. We also tried to simulate
incoming traffic when restarting the application, and run it against a
backup of the PROD database... Somehow we can't reproduce the error. We are
guessing that maybe the PROD traffic is higher than what we can simulate
and some incoming message comes at just the wrong time? But we don't know
for sure.

 Now, studying the issue, we realized that we used to have this in our
src/main/webapp/WEB-INF/faces-config.xml:

http://java.sun.com/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2
001/XMLSchema-instance" xsi:schemaLocation="http://jav
a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
aee/web-facesconfig_2_1.xsd" version="2.1">logincom.lecip.tms.tms_core.application.Loginview


 We believe the JSF version is not correct for JEE7 anymore, in
addition the managed-bean annotation is not necessary, so we changed the
file to now contain:


http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;
   version="2.2">


 Could this be the cause for that error that we saw in our PROD
environment? Or you would think the root cause would be something else? The
problem is that it's pretty difficult for us to experiment with changes
since any deployment on PROD must be first validated on staging and UAT...
Any hints? Is there maybe some logging configuration flag we could activate
to get more information about the error? Or any other place to look to get
more information about the issue?

 The irony is that we use JSF only for the login screen and nowhere
else...

 Regards,

Emmanuel

12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
For security constraints with URL pattern [/*] only the HTTP methods [TRACE
HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
uncovered.
12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
  java.lang.IllegalStateException: No Factories configured for this
Application. This happens if the faces-initialization does not work at all
- make sure that you properly include all configuration settings necessary
for a basic faces application and that all the necessary libs are included.
Also check the logging output of your web application and your container
for any exceptions!
If you did that and find nothing, the mistake might be due to the fact
that you use some special web-containers which 

No Factories configured for this Application. This happens if the faces-initialization does not work at all

[Emmanuel Touzery]

Hello,

    we have a TOMEE 7.0.3 application, which uses also JMS, which works 
without issues. We've recently made a new version of the application 
(one of the notable changes is a migration from using the JMS1.1 to the 
JMS2 API).


    With the new version, we have an issue, but only on our PROD 
environment, where we get no errors in the catalina.out log file (but 
the application doesn't work), but an error in the localhost log file, 
the error being as in the title of the email, I put the info from the 
localhost log file at the end of this email.


    I can't put the source on github or something like that, 
unfortunately. What is strange is that this error does not occur on our 
staging or UAT environments, but it does occur every time (well, we 
tried multiple times to restart the application and it failed 
consistently) on the PROD environment. We copied the entire PROD tomee 
folder on another machine and failed to reproduce the issue. We also 
tried to simulate incoming traffic when restarting the application, and 
run it against a backup of the PROD database... Somehow we can't 
reproduce the error. We are guessing that maybe the PROD traffic is 
higher than what we can simulate and some incoming message comes at just 
the wrong time? But we don't know for sure.


    Now, studying the issue, we realized that we used to have this in 
our src/main/webapp/WEB-INF/faces-config.xml:


xmlns="http://java.sun.com/xml/ns/javaee; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_1.xsd; 
version="2.1">logincom.lecip.tms.tms_core.application.Loginview


    We believe the JSF version is not correct for JEE7 anymore, in 
addition the managed-bean annotation is not necessary, so we changed the 
file to now contain:



http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;

  version="2.2">


    Could this be the cause for that error that we saw in our PROD 
environment? Or you would think the root cause would be something else? 
The problem is that it's pretty difficult for us to experiment with 
changes since any deployment on PROD must be first validated on staging 
and UAT... Any hints? Is there maybe some logging configuration flag we 
could activate to get more information about the error? Or any other 
place to look to get more information about the issue?


    The irony is that we use JSF only for the login screen and nowhere 
else...


    Regards,

Emmanuel

12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1] 
org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods 
For security constraints with URL pattern [/*] only the HTTP methods 
[TRACE HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods 
are uncovered.
12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1] 
org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
 java.lang.IllegalStateException: No Factories configured for this 
Application. This happens if the faces-initialization does not work at 
all - make sure that you properly include all configuration settings 
necessary for a basic faces application and that all the necessary libs 
are included. Also check the logging output of your web application and 
your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact 
that you use some special web-containers which do not support 
registering context-listeners via TLD files and a context listener is 
not setup in your web.xml.

A typical config looks like this;

org.apache.myfaces.webapp.StartupServletContextListener


    at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
    at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
    at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
    at 
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1183)
    at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1099)
    at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:989)
    at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4913)
    at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5223)
    at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
    at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
    at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
    at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:596)
    at 

Re: UnsatisfiedResolutionException with qualifiers -- what am I doing wrong?

[Emmanuel Touzery]

Hi,

       finally tracked it down to a  clause in the 
pom.xml...


    Thank you!

Emmanuel

On 08/03/18 14:23, Romain Manni-Bucau wrote:

yes, try reproducing it in a sample maybe


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-08 14:20 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:


Hello,

 thank you for the answer! No, definitely it's not in the default
excludes. Already injecting bunch of things from that JAR. Also, the
interface is in a JAR, but the producer is in the main code of the app. And
it's the producer which can't be found.
 From your answer I take it that it should work :-(

emmanuel

On 08/03/18 14:12, Romain Manni-Bucau wrote:


Hi Emmanuel,

did you check your jar was not in the default excludes? (try renaming it
"foo.jar" to test quickly)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-
high-performance>


2018-03-08 13:32 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:

Hello,

  I'm confused about a CDI error, I would expect this to work... What
am
I doing wrong? It's true otherwise that the interface is defined in
another
JAR than the producer but I wouldn't expect it to be a problem...

  At runtime I get:

08-Mar-2018 12:27:57.287 SEVERE [localhost-startStop-1]
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication CDI Beans
module
deployment failed
   org.apache.webbeans.exception.WebBeansDeploymentException:
javax.enterprise.inject.UnsatisfiedResolutionException: Api type [
com.lecip.core.application.customer_profiles.CustomerProfile] is not
found with the qualifiers
Qualifiers: [@com.lecip.core.application.customer_profiles.CustomerConte
xt()]
for injection into Field Injection Point, field name : _customerProfile,
Bean Owner : [TmsAllFunctionalitiesProvider, WebBeansType:MANAGED,
Name:null, API Types:[java.lang.Object,com.le
cip.tms.tms_core.authorization.TmsAllFunctionalitiesProvider
,com.lecip.core.authorization.AllFunctionalitiesProvider],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise
.inject.Any]]

  Any ideas?

--- beans.xml --


http://xmlns.jcp.org/xml/ns/javaee;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_2.xsd;
 version="1.2" bean-discovery-mode="all">


-- CustomerContext.java --

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface CustomerContext {}

-- CustomerProfileProducer.java --

public class CustomerProfileProducer {
  @Produces
  @CustomerContext
   public CustomerProfile getCustomerProfile() {
   return null;
 }
}

   -- Injecting class --

  @Inject @CustomerContext
  CustomerProfile customerProfile;

Re: UnsatisfiedResolutionException with qualifiers -- what am I doing wrong?

[Emmanuel Touzery]

Hello,

    thank you for the answer! No, definitely it's not in the default 
excludes. Already injecting bunch of things from that JAR. Also, the 
interface is in a JAR, but the producer is in the main code of the app. 
And it's the producer which can't be found.

    From your answer I take it that it should work :-(

emmanuel

On 08/03/18 14:12, Romain Manni-Bucau wrote:

Hi Emmanuel,

did you check your jar was not in the default excludes? (try renaming it
"foo.jar" to test quickly)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-08 13:32 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:


Hello,

 I'm confused about a CDI error, I would expect this to work... What am
I doing wrong? It's true otherwise that the interface is defined in another
JAR than the producer but I wouldn't expect it to be a problem...

 At runtime I get:

08-Mar-2018 12:27:57.287 SEVERE [localhost-startStop-1]
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication CDI Beans module
deployment failed
  org.apache.webbeans.exception.WebBeansDeploymentException:
javax.enterprise.inject.UnsatisfiedResolutionException: Api type [
com.lecip.core.application.customer_profiles.CustomerProfile] is not
found with the qualifiers
Qualifiers: [@com.lecip.core.application.customer_profiles.CustomerConte
xt()]
for injection into Field Injection Point, field name : _customerProfile,
Bean Owner : [TmsAllFunctionalitiesProvider, WebBeansType:MANAGED,
Name:null, API Types:[java.lang.Object,com.le
cip.tms.tms_core.authorization.TmsAllFunctionalitiesProvider
,com.lecip.core.authorization.AllFunctionalitiesProvider],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]

 Any ideas?

--- beans.xml --


http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_2.xsd;
version="1.2" bean-discovery-mode="all">


-- CustomerContext.java --

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface CustomerContext {}

-- CustomerProfileProducer.java --

public class CustomerProfileProducer {
 @Produces
 @CustomerContext
  public CustomerProfile getCustomerProfile() {
  return null;
}
}

  -- Injecting class --

 @Inject @CustomerContext
 CustomerProfile customerProfile;

UnsatisfiedResolutionException with qualifiers -- what am I doing wrong?

[Emmanuel Touzery]

Hello,

    I'm confused about a CDI error, I would expect this to work... What 
am I doing wrong? It's true otherwise that the interface is defined in 
another JAR than the producer but I wouldn't expect it to be a problem...


    At runtime I get:

08-Mar-2018 12:27:57.287 SEVERE [localhost-startStop-1] 
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication CDI Beans 
module deployment failed
 org.apache.webbeans.exception.WebBeansDeploymentException: 
javax.enterprise.inject.UnsatisfiedResolutionException: Api type 
[com.lecip.core.application.customer_profiles.CustomerProfile] is not 
found with the qualifiers
Qualifiers: 
[@com.lecip.core.application.customer_profiles.CustomerContext()]
for injection into Field Injection Point, field name : _customerProfile, 
Bean Owner : [TmsAllFunctionalitiesProvider, WebBeansType:MANAGED, 
Name:null, API 
Types:[java.lang.Object,com.lecip.tms.tms_core.authorization.TmsAllFunctionalitiesProvider,com.lecip.core.authorization.AllFunctionalitiesProvider], 
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]


    Any ideas?

--- beans.xml --


http://xmlns.jcp.org/xml/ns/javaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/beans_1_2.xsd;

   version="1.2" bean-discovery-mode="all">


-- CustomerContext.java --

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface CustomerContext {}

-- CustomerProfileProducer.java --

public class CustomerProfileProducer {
    @Produces
    @CustomerContext
 public CustomerProfile getCustomerProfile() {
 return null;
   }
}

 -- Injecting class --

    @Inject @CustomerContext
    CustomerProfile customerProfile;

Re: monitoring stateless bean pool usage through JMX?

[Emmanuel Touzery]

Hello,

    thank you for the advice regarding the relevance. We've had issues 
where we ran out of statelesses from the pool but it was mostly due to, 
for instance, overloaded SQL so the real issue what elsewhere. Still it 
made us wonder whether we should consider tuning this parameter too.


    Given that it's per bean, I guess the default of 10 is likely 
appropriate after all yes..


    Thank you!

Emmanuel

On 20/12/17 16:45, Romain Manni-Bucau wrote:

it is per bean yes, you can poll them all at once through JMX API

now on the impl itself there are almost no case where a stateless is really
relevant today with CDI (and potentially microprofile or deltaspike
throttler) so maybe check the app really need it before adding tooling on
top of it


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-12-20 16:43 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:




 Certainly I can't poll every stateless bean in my app, too many of
them, I think it'd have a performance impact on the app.


(I meant I can't poll the active instances through JMX)

emmanuel

Re: monitoring stateless bean pool usage through JMX?

[Emmanuel Touzery]

    Certainly I can't poll every stateless bean in my app, too many of 
them, I think it'd have a performance impact on the app. 


(I meant I can't poll the active instances through JMX)

emmanuel

Re: monitoring stateless bean pool usage through JMX?

[Emmanuel Touzery]

Hello,

    oh so we have accounting per-stateless bean? For a stateless bean 
for instance, I see:


  MaxSize = 10
  MinSize = 0
  InstancesActive = 0
  InstancesIdle = 0

    and I guess that's what interesting to me. But I didn't expect 
per-bean accounting.


    Isn't that a bit coarse then, we have accounting per individual 
bean, but to set the maximum for instance, we must do it app-wide, 
through a container "type=STATELESS" in the tomee.xml, right?


    so in the end if i was worried that my maxSize for my stateless 
container was too low... I'd have to monitor "InstancesActive" for every 
stateless bean in my application? Do I understand right? And if some 
stateless bean has many more instances than the others, that may mean I 
should consider redesigning my application right? Or would it make sense 
to raise the maxSize which will affect other stateless beans too?


    Certainly I can't poll every stateless bean in my app, too many of 
them, I think it'd have a performance impact on the app.


    Thank you!

Emmanuel


On 20/12/17 15:44, Romain Manni-Bucau wrote:

Hello

did you check

openejb.management:J2EEServer=openejb,J2EEApplication=,EJBModule=app,StatelessSessionBean=TheBean,name=TheBean,j2eeType=Pool


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-12-20 15:32 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:


Hello,

 I'm interested in monitoring the tomee stateless bean pool usage
through JMX. I can't find the relevant object name. I was looking at:

openejb.management:ObjectType=containers,DataSource=Default Stateless
Container

 But I would not find information about the current pool usage (I would
be interested in pool capacity & current usage).

 Thank you!

Emmanuel

Re: monitoring stateless bean pool usage through JMX?

[Emmanuel Touzery]

Hello,

    I'm interested in monitoring the tomee stateless bean pool usage 
through JMX. I can't find the relevant object name. I was looking at:


openejb.management:ObjectType=containers,DataSource=Default Stateless 
Container


    But I would not find information about the current pool usage (I 
would be interested in pool capacity & current usage).


    Thank you!

Emmanuel

monitoring stateless bean pool usage through JMX?

[Emmanuel Touzery]

Hello,

    I'm interested in monitoring the tomee stateless bean pool usage 
through JMX. I can't find the relevant object name. I was looking at:

per-application settings outside of the WAR file

[Emmanuel Touzery]

Hello,

    in our setup we have a series of key-value low-level config 
settings in the WAR file, however we'd like to move those out of the war 
file.


    I was looking at possible options, and 
|$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml seems like a good 
option.

|

    I was checking https://stackoverflow.com/a/26146742/516188 and 
https://stackoverflow.com/a/26147130/516188


    However when I add such an extra context.xml file, the app startup 
fails (message at the end of this email).


    I think this is probably because we already have a server-wide 
context.xml and one in our war file (the one in the war file is empty 
though). I wonder is there a way we could create such a file in 
conf/engine/hostname/app.xml containing for instance 'Environment' 
entries which we could read through JNDI without impacting our app setup 
in other ways?


Emmanuel

Startup error =>

Caused by: java.lang.IllegalStateException: No Factories configured for 
this Application. This happens if the faces-initialization does not work 
at all - make sure that you properly include all configuration settings 
necessary for a basic faces application and that all the necessary libs 
are included. Also check the logging output of your web application and 
your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact 
that you use some special web-containers which do not support 
registering context-listeners via TLD files and a context listener is 
not setup in your web.xml.

A typical config looks like this;

org.apache.myfaces.webapp.StartupServletContextListener


    at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
    at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
    at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
    at 
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1183)

    ... 24 more

Re: two applications using ActiveMQ: tomee attempts to start ActiveMQ twice

[Emmanuel Touzery]

Hello,

it seems you were right regarding explicit JMS configuration. We 
had configured only a ActiveMQResourceAdapter resource in the tomee.xml. 
We've now added a javax.jms.ConnectionFactory resource and:



ResourceAdapter = MyJmsResourceAdapter


As per: http://tomee.apache.org/jms-resources-and-mdb-container.html

And the warnings are now gone!

Thank you!

Emmanuel

On 11/05/17 15:01, Romain Manni-Bucau wrote:

Hi

think we miss some logs but looks like you can use multiple MDB
configuration which starts one instance each (or default to one instance
each), maybe configure explicitly JMS resources.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-05-11 11:43 GMT+02:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>
:


Hello,

 we are running multiple applications on one TomEE+ instance, and
several of them make use of ActiveMQ.

 What happens then is that TomEE attempts to start ActiveMQ several
times. It results in errors in the log file as the extra startup attempts
fail due to the port already being used, but as far as we can tell, despite
the error, everything works fine. It seems as though TomEE should just skip
start ActiveMQ if it's already running. Should we configure TomEE
differently to avoid this issue?

 Regards,

Emmanuel

PS: the logs:

11-May-2017 09:14:49.531 INFO [main] org.apache.openejb.resource.ac
tivemq.ActiveMQ5Factory.createBroker ActiveMQ5Factory creating broker
11-May-2017 09:14:49.908 INFO [main] 
org.apache.activemq.broker.BrokerService.
Loaded the Bouncy Castle security provider.
11-May-2017 09:14:50.008 INFO [main] org.apache.openejb.resource.ac
tivemq.ActiveMQ5Factory.createBroker Using ActiveMQ startup timeout of
1ms
11-May-2017 09:14:50.009 INFO [ActiveMQFactory start and checkpoint]
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting
ActiveMQ BrokerService
11-May-2017 09:14:50.335 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using
Persistence Adapter: MemoryPersistenceAdapter
11-May-2017 09:14:50.545 INFO [34] 
org.apache.activemq.broker.jmx.ManagementContext$1.run
JMX consoles can connect to service:jmx:rmi:///jndi/rmi://
localhost:1099/jmxrmi
11-May-2017 09:14:50.611 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) is starting
11-May-2017 09:14:50.633 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.transport.TransportServerThreadSupport.doStart
Listening for connections at: tcp://localhost:61616
11-May-2017 09:14:50.634 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.TransportConnector.start Connector
tcp://localhost:61616 started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.BrokerService.doStartBroker For help or more
information please see: http://activemq.apache.org
11-May-2017 09:14:50.639 WARNING [ActiveMQFactory start and checkpoint]
org.apache.activemq.broker.BrokerService.checkUsageLimit Temporary Store
limit is 51200 mb (current store usage is 0 mb). The data directory:
/opt/app/apache-tomee-plus-7.0.3-LECIP/logs only has 10861 mb of usable
space. - resetting to maximum available disk space: 10861 mb
11-May-2017 09:14:50.707 INFO [32] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run
Starting ActiveMQ checkpoint
11-May-2017 09:14:50.708 INFO [main] org.apache.openejb.resource.ac
tivemq.ActiveMQ5Factory.createBroker ActiveMQ broker started

 And then later in the startup sequence:

11-May-2017 09:14:59.014 INFO [localhost-startStop-1]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker
ActiveMQ5Factory creating broker
11-May-2017 09:14:59.017 SEVERE [localhost-startStop-1]
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.createInternalBroker
Failed to start ActiveMQ
  java.lang.Exception: ActiveMQFactory.createBroker.I
nvocationTargetException
 at org.apache.openejb.resource.activemq.ActiveMQFactory.createB
roker(ActiveMQFactory.java:128)
 at org.apache.openejb.resource.activemq.ActiveMQResourceAdapter
.createInternalBroker(ActiveMQResourceAdapter.java:150)
 at org.apache.openejb.resource.activemq.ActiveMQResourceAdapter
.start(ActiveMQResourceAdapter.java:140)
 at org.apache.openejb.assembler.classic.Assem

two applications using ActiveMQ: tomee attempts to start ActiveMQ twice

[Emmanuel Touzery]

Hello,

we are running multiple applications on one TomEE+ instance, and 
several of them make use of ActiveMQ.


What happens then is that TomEE attempts to start ActiveMQ several 
times. It results in errors in the log file as the extra startup 
attempts fail due to the port already being used, but as far as we can 
tell, despite the error, everything works fine. It seems as though TomEE 
should just skip start ActiveMQ if it's already running. Should we 
configure TomEE differently to avoid this issue?


Regards,

Emmanuel

PS: the logs:

11-May-2017 09:14:49.531 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ5Factory creating broker
11-May-2017 09:14:49.908 INFO [main] 
org.apache.activemq.broker.BrokerService. Loaded the Bouncy 
Castle security provider.
11-May-2017 09:14:50.008 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker Using 
ActiveMQ startup timeout of 1ms
11-May-2017 09:14:50.009 INFO [ActiveMQFactory start and checkpoint] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting 
ActiveMQ BrokerService
11-May-2017 09:14:50.335 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using 
Persistence Adapter: MemoryPersistenceAdapter
11-May-2017 09:14:50.545 INFO [34] 
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can 
connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
11-May-2017 09:14:50.611 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ 
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) is starting
11-May-2017 09:14:50.633 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.transport.TransportServerThreadSupport.doStart 
Listening for connections at: tcp://localhost:61616
11-May-2017 09:14:50.634 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.TransportConnector.start Connector 
tcp://localhost:61616 started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ 
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker For help or more 
information please see: http://activemq.apache.org
11-May-2017 09:14:50.639 WARNING [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.checkUsageLimit Temporary Store 
limit is 51200 mb (current store usage is 0 mb). The data directory: 
/opt/app/apache-tomee-plus-7.0.3-LECIP/logs only has 10861 mb of usable 
space. - resetting to maximum available disk space: 10861 mb
11-May-2017 09:14:50.707 INFO [32] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting 
ActiveMQ checkpoint
11-May-2017 09:14:50.708 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ broker started


And then later in the startup sequence:

11-May-2017 09:14:59.014 INFO [localhost-startStop-1] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ5Factory creating broker
11-May-2017 09:14:59.017 SEVERE [localhost-startStop-1] 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.createInternalBroker 
Failed to start ActiveMQ
 java.lang.Exception: 
ActiveMQFactory.createBroker.InvocationTargetException
at 
org.apache.openejb.resource.activemq.ActiveMQFactory.createBroker(ActiveMQFactory.java:128)
at 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.createInternalBroker(ActiveMQResourceAdapter.java:150)
at 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:140)
at 
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:3051)
at 
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at 
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at 
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at 
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:2043)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:1978)
at 
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2181)
at 
org.apache.openejb.config.AutoConfig.autoCreateResource(AutoConfig.java:2068)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:2056)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:1978)
at 
org.apache.openejb.config.AutoConfig.processResourceRef(AutoConfig.java:1218)

at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:873)
at 

two applications using ActiveMQ: tomee attempts to start ActiveMQ twice

[Emmanuel Touzery]

Hello,

we are running multiple applications on one TomEE+ instance, and 
several of them make use of ActiveMQ.


What happens then is that TomEE attempts to start ActiveMQ several 
times. It results in errors in the log file as the extra startup 
attempts fail due to the port already being used, but as far as we can 
tell, despite the error, everything works fine. It seems as though TomEE 
should just skip start ActiveMQ if it's already running. Should we 
configure TomEE differently to avoid this issue?


Regards,

Emmanuel

PS: the logs:

11-May-2017 09:14:49.531 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ5Factory creating broker
11-May-2017 09:14:49.908 INFO [main] 
org.apache.activemq.broker.BrokerService. Loaded the Bouncy 
Castle security provider.
11-May-2017 09:14:50.008 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker Using 
ActiveMQ startup timeout of 1ms
11-May-2017 09:14:50.009 INFO [ActiveMQFactory start and checkpoint] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting 
ActiveMQ BrokerService
11-May-2017 09:14:50.335 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using 
Persistence Adapter: MemoryPersistenceAdapter
11-May-2017 09:14:50.545 INFO [34] 
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can 
connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
11-May-2017 09:14:50.611 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ 
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) is starting
11-May-2017 09:14:50.633 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.transport.TransportServerThreadSupport.doStart 
Listening for connections at: tcp://localhost:61616
11-May-2017 09:14:50.634 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.TransportConnector.start Connector 
tcp://localhost:61616 started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker Apache ActiveMQ 
5.14.3 (localhost, ID:localhost-46298-1494494090400-0:1) started
11-May-2017 09:14:50.635 INFO [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.doStartBroker For help or more 
information please see: http://activemq.apache.org
11-May-2017 09:14:50.639 WARNING [ActiveMQFactory start and checkpoint] 
org.apache.activemq.broker.BrokerService.checkUsageLimit Temporary Store 
limit is 51200 mb (current store usage is 0 mb). The data directory: 
/opt/app/apache-tomee-plus-7.0.3-LECIP/logs only has 10861 mb of usable 
space. - resetting to maximum available disk space: 10861 mb
11-May-2017 09:14:50.707 INFO [32] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting 
ActiveMQ checkpoint
11-May-2017 09:14:50.708 INFO [main] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ broker started


And then later in the startup sequence:

11-May-2017 09:14:59.014 INFO [localhost-startStop-1] 
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker 
ActiveMQ5Factory creating broker
11-May-2017 09:14:59.017 SEVERE [localhost-startStop-1] 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.createInternalBroker 
Failed to start ActiveMQ
 java.lang.Exception: 
ActiveMQFactory.createBroker.InvocationTargetException
at 
org.apache.openejb.resource.activemq.ActiveMQFactory.createBroker(ActiveMQFactory.java:128)
at 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.createInternalBroker(ActiveMQResourceAdapter.java:150)
at 
org.apache.openejb.resource.activemq.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:140)
at 
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:3051)
at 
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at 
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at 
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at 
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:2043)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:1978)
at 
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2181)
at 
org.apache.openejb.config.AutoConfig.autoCreateResource(AutoConfig.java:2068)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:2056)
at 
org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java:1978)
at 
org.apache.openejb.config.AutoConfig.processResourceRef(AutoConfig.java:1218)

at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:873)
at 

Re: registering a JMS MDB works through annotations, not through ejb-jar.xml

[Emmanuel Touzery]

Hi,

yes I typed in the right class & package name, actually if I 
introduce a typo on purpose the app doesn't start (which is nice):


org.apache.openejb.OpenEJBRuntimeException: 
at 
org.apache.openejb.config.rules.CheckClasses.validate(CheckClasses.java:148)
at 
org.apache.openejb.config.rules.ValidationBase.validate(ValidationBase.java:50)
at 
org.apache.openejb.config.AppValidator.validate(AppValidator.java:102)
at 
org.apache.openejb.config.ValidateModules.deploy(ValidateModules.java:38)


Ok, I'll see what I can do with regards to that, thanks for the tip...

emmanuel

On 23/03/17 11:56, Romain Manni-Bucau wrote:

Hi

Are you sure you matched the right ejb name?

If you are not afraid by debugging tomee (it is really just like debugging
your app once you got the sources ;)), you can put a breakpoint
in org.apache.openejb.config.ActivationConfigPropertyOverride in the for
loop


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-03-23 10:27 GMT+01:00 Emmanuel Touzery <
emmanuel.touz...@lit-transit.com>:


Hello,

 I'm having trouble registering an MDB through the ejb-jar.xml.

 If I have the annotations on the MDB, like so:

@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue
= "tmsAlertQueue")},
mappedName = "jms/tmsAlertQueue")
public class AlertMessageHandler extends BaseMessageHandler
implements MessageListener {

 Everything works fine. But I'd rather have the annotations in the
ejb-jar.xml (so I can turn them on or off through config). I have this (and
those exact annotations worked on glassfish 3.1.2.2) =>


http://java.sun.com/xml/ns/javaee;
  version = "3.1"
  xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd;>
 
 
AlertMessageHandler
 AlertMessageHandler
jms/tmsAlertQueue
tms.tms_core.handlers.alerts.AlertMessageHandler
javax.jms.Queue
 
 
destination

tmsAlertQueue

 
 
destinationType

javax.jms.Queue

 
 
 


 But that doesn't work. I know tomee parses the ejb-jar.xml, because if
I put garbage in it, I get an error. I'm testing in arquillian right now
actually, and registering the ejb-jar through shrinkwrap like so:

 .addAsWebInfResource("WEB-INF/ejb-jar.xml", "ejb-jar.xml")

 I've tried modifying the ejb-jar root element for JEE7, like so:

http://xmlns.jcp.org/xml/ns/javaee;
 version="3.2"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd;>

 And also adding the metadata-complete attribute (both to true and
false), to no avail. The log file doesn't tell me much.

 Any idea what I can do next?

 Thank you!

emmanuel

Re: tomee-embedded-maven-plugin and resources maven filtering

[Emmanuel Touzery]

Hi,


If you really want it there are few options like using a jsCustomizer to
synchronize 2 folders and change the docBase


get it!


  or just use standard maven
output folder and use another synchro way.


I don't understand that option? tomee embedded could work on the target/ 
folder where the build is being made? If yes, how can that be 
configured, I don't see such an option?


Thank you!

Emmanuel

Re: tomee-embedded-maven-plugin and resources maven filtering

[Emmanuel Touzery]

Hello,

thank you! I'm getting close. One more thing.. When it starts, it 
gets the application name "":


[INFO] Deployed Application(path=)

well, that may be OK I guess. But more problematic, in the web.xml 
we specified that rest calls should go under REST and it ignores that 
and puts them straight at the root. I know you advised for 
ServletContextInitializer, but I wouldn't change too much at once. How 
would tomee-embedded behave differently than the normal tomee on that, 
isn't that strange? The web.xml is read otherwise, although I don't see 
much in the logs regarding that.


Thank you!

Emmanuel

Re: tomee-embedded-maven-plugin and resources maven filtering

[Emmanuel Touzery]

Hello,


 I see we can define an inline server.xml & tomee.xml, what about

beans.xml, web.xml, context.xml, resources.xml..., how should we handle
this?
Beans.xml is almost useless with cdi 1.1 with @Priority, web.xml too with
ServletContextInitializer and resources.xml  can be fully replaced by
container properties in the plugin config.

If you really want it there are few options like using a jsCustomizer to
synchronize 2 folders and change the docBase or just use standard maven
output folder and use another synchro way.


thank you, that helps! Focusing on the resources.xml for now. This takes 
me further =>



new://Resource?type=javax.sql.DataSource
org.postgresql.Driver
jdbc:postgresql://localhost/generic
postgres
postgres
20
20
select 
version();

true
true
false
1 
millisecond

4400
true
3 millisecond


My next issue is that the postgresql driver is not found. With 
tomee-maven-plugin, I could do =>



org.postgresql:postgresql:9.4-1201-jdbc41


Not sure how to handle that with tomee-embedded-maven-plugin?

Thank you!

Emmanuel

Re: CDI issues tomee 7.0.2

[Emmanuel Touzery]

Hello,

thank you. Darjan is my colleague, I can confirm both solutions 
solve the issue.


May I ask... My understanding is that tomee.jpa.cdi=false is the 
7.0.1 behaviour (which worked fine for us), while 
"tomee.jpa.factory.lazy=true" is a "trick" to avoid the problem we've 
just hit while enabling a new feature.


So for us, cdi=false is a safe, known state, while lazy=true could 
be risky (from what I understand, there could be problems if hibernate 
attempts to make use of CDI in the early startup?). But then if 
lazy=true is the "future" and it's likely hibernate will make use or 
require the feature in the future, it's probably best to go that way?


Can you tell us more about the compromise here?

Thank you!

Emmanuel

On 18/11/16 09:43, Romain Manni-Bucau wrote:

Hello

You can disable cdi for hibernate tomee.jpa.cdi=false in the persistence
unit or system properties.

If you want it - was not part if 7.0.1 - you can in the same locations set
tomee.jpa.factory.lazy to true.

Idea is to let hibernate initialize ince cdi is started but let cdi have
jpa entity manager or factory - yes chicken egg problem but spec is written
this way ;).

Le 18 nov. 2016 09:25, "Darjan Oblak"  a écrit :


Hi,

our app deployed successfully on 7.0.1, but fails on 7.0.2. However, the
problem disappears if I replace lib/openejb-core-7.0.2.jar in tomee 7.0.2
distribution by openejb-core-7.0.1.jar

Any clues what could be the problem?

The exception we get:

Caused by: java.lang.IllegalStateException: On a thread without an
initialized context nor a classloader mapping a deployed app
at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(
ThreadSingletonServiceImpl.java:287)
at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.getContext(
ThreadSingletonServiceImpl.java:263)
at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(
ThreadSingletonServiceImpl.java:298)
at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(
ThreadSingletonServiceImpl.java:60)
at
org.apache.webbeans.config.WebBeansFinder.getSingletonInstance(
WebBeansFinder.java:51)
at
org.apache.webbeans.config.WebBeansContext.getInstance(
WebBeansContext.java:185)
at
org.apache.webbeans.config.WebBeansContext.currentInstance(
WebBeansContext.java:203)
at
org.apache.openejb.assembler.classic.EntityManagerFactoryCallable$
1.findBm(EntityManagerFactoryCallable.java:105)
at
org.apache.openejb.assembler.classic.EntityManagerFactoryCallable$
1.invoke(EntityManagerFactoryCallable.java:96)
at com.sun.proxy.$Proxy121.createAnnotatedType(Unknown Source)
at
org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$
BeanMetaData.(BeanManagerListenerFactory.java:77)
at
org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$
BeanMetaData.(BeanManagerListenerFactory.java:71)
at
org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.
buildListener(BeanManagerListenerFactory.java:57)
at
org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.
resolveCallbacks(LegacyCallbackProcessor.java:167)
at
org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.
processCallbacksForEntity(LegacyCallbackProcessor.java:70)
at
org.hibernate.jpa.event.spi.JpaIntegrator.integrate(
JpaIntegrator.java:150)
at
org.hibernate.internal.SessionFactoryImpl.(
SessionFactoryImpl.java:312)
at
org.hibernate.cfg.Configuration.buildSessionFactory(
Configuration.java:1859)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(
EntityManagerFactoryBuilderImpl.java:852)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(
EntityManagerFactoryBuilderImpl.java:845)
at
org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.
withTccl(ClassLoaderServiceImpl.java:398)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(
EntityManagerFactoryBuilderImpl.java:844)
at
org.hibernate.jpa.HibernatePersistenceProvider.
createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152)
at
org.apache.openejb.assembler.classic.EntityManagerFactoryCallable.call(
EntityManagerFactoryCallable.java:122)
at
org.apache.openejb.assembler.classic.ReloadableEntityManagerFactory
.createDelegate(ReloadableEntityManagerFactory.java:134)
... 68 more

Thank you,
Best Regards,
Darjan Oblak

Re: org.apache.webbeans.component.ProducerMethodBean is not applicable for the bean instance : String

[Emmanuel Touzery]

and I fixed the issue. The debugger helped, thank you.
I didn't realize BeanHelper came from our company here. It was a mistake 
in that class and the class it passed to BeanManager.


Anyway, thank you again for the help!

Emmanuel

On 19/05/16 11:47, Emmanuel Touzery wrote:

Hello,

thank you that worked!

I just had to add "jpda" as a command line parameter, eg 
"catalina.sh jpda run".


Will try to help myself with the debugger to get it now. Will 
report on my success (or lack thereof).


Thank you again,

Emmanuel

On 19/05/16 11:19, Romain Manni-Bucau wrote:

if you use maven add in your pom with provided scope
"org.apache.openejb:tomee-catalina:${version}" then in the shell you 
use to

run tomee (i use UNIx commands but replace "sh" by "bat" and "export" by
"set" for windows):

export JPDA_ADDRESS=5005
export JPDA_SUSPEND=y
# bin\catalina.bat run for win
./bin/catalina.sh run

then in your IDE just remote debug on port 5005.




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github 
<https://github.com/rmannibucau> |

LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 11:17 GMT+02:00 Emmanuel Touzery 
<emmanuel.touz...@lecip-its.com>

:

setting up the environment so that I could debug tomee code doesn't 
seem

easy at all :-(
gave it a try and failed so far. I guess there's no tutorial related to
that that I could look at?

Regards,

Emmanuel

On 19/05/16 09:55, Romain Manni-Bucau wrote:


Maybe a lazy solution but very efficient: put a breakpoint in
BeanManagerImpl
line 703 and check what triggered the exception (should be a if at 
that

point so should be easy to identify).

I didn't say it was not a tomee/OWB bug - we got some in this area 
when
implementing CDI 1.2 for TomEE 7 so can be an old issue fixed in 
between.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 9:46 GMT+02:00 Emmanuel Touzery <
emmanuel.touz...@lecip-its.com>:

Hello,
  yes I didn't expect a TomEE bug, but I'm wondering what 
could cause
this behaviour. This is TomEE 1.7.2 but we're also doing this in 
another
1.7.2 project, so it's not about the version I think. Maybe some 
stray

dependency? The beans.xml, the dependencies look OK. Anywhere else I
should
look?

  Regards,

Emmanuel

On 18/05/16 15:21, Romain Manni-Bucau wrote:

Hi Emmanuel,
either you use an old version or something else is making it 
failing,

this
test passes:
https://gist.github.com/rmannibucau/1d026806a6bb9b89a957c6fba50e4d46


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>


2016-05-18 13:42 GMT+02:00 Emmanuel Touzery <
emmanuel.touz...@lecip-its.com>
:

Hello,


   I'm porting a Glassfish application to TomEE and I don't
understand
this error that I'm getting:

org.apache.openejb.core.transaction.EjbTransactionUtil
handleSystemException
SEVERE: EjbTransactionUtil.handleSystemException: Given bean type :
class
org.apache.webbeans.component.ProducerMethodBean is not 
applicable for

the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API


Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable], 




Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named] 


java.lang.IllegalArgumentException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not 
applicable for

the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API


Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable], 




Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named] 


   at


org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:703) 


   at


com.lecip.tms.tms_core.application.BeanHelper.getBeanByName(BeanHelper.java:40) 



I'm having this pretty trivial bean:


public class AppUserUsernameProvider {

   public static final String LOGGED_IN_USERNAME =
"loggedInAppUserUsername";
   @Inject
   CurrentAppUserC

Re: org.apache.webbeans.component.ProducerMethodBean is not applicable for the bean instance : String

[Emmanuel Touzery]

Hello,

thank you that worked!

I just had to add "jpda" as a command line parameter, eg 
"catalina.sh jpda run".


Will try to help myself with the debugger to get it now. Will 
report on my success (or lack thereof).


Thank you again,

Emmanuel

On 19/05/16 11:19, Romain Manni-Bucau wrote:

if you use maven add in your pom with provided scope
"org.apache.openejb:tomee-catalina:${version}" then in the shell you use to
run tomee (i use UNIx commands but replace "sh" by "bat" and "export" by
"set" for windows):

export JPDA_ADDRESS=5005
export JPDA_SUSPEND=y
# bin\catalina.bat run for win
./bin/catalina.sh run

then in your IDE just remote debug on port 5005.




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 11:17 GMT+02:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>
:


setting up the environment so that I could debug tomee code doesn't seem
easy at all :-(
gave it a try and failed so far. I guess there's no tutorial related to
that that I could look at?

Regards,

Emmanuel

On 19/05/16 09:55, Romain Manni-Bucau wrote:


Maybe a lazy solution but very efficient: put a breakpoint in
BeanManagerImpl
line 703 and check what triggered the exception (should be a if at that
point so should be easy to identify).

I didn't say it was not a tomee/OWB bug - we got some in this area when
implementing CDI 1.2 for TomEE 7 so can be an old issue fixed in between.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 9:46 GMT+02:00 Emmanuel Touzery <
emmanuel.touz...@lecip-its.com>:

Hello,

  yes I didn't expect a TomEE bug, but I'm wondering what could cause
this behaviour. This is TomEE 1.7.2 but we're also doing this in another
1.7.2 project, so it's not about the version I think. Maybe some stray
dependency? The beans.xml, the dependencies look OK. Anywhere else I
should
look?

  Regards,

Emmanuel

On 18/05/16 15:21, Romain Manni-Bucau wrote:

Hi Emmanuel,

either you use an old version or something else is making it failing,
this
test passes:
https://gist.github.com/rmannibucau/1d026806a6bb9b89a957c6fba50e4d46


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>


2016-05-18 13:42 GMT+02:00 Emmanuel Touzery <
emmanuel.touz...@lecip-its.com>
:

Hello,


   I'm porting a Glassfish application to TomEE and I don't
understand
this error that I'm getting:

org.apache.openejb.core.transaction.EjbTransactionUtil
handleSystemException
SEVERE: EjbTransactionUtil.handleSystemException: Given bean type :
class
org.apache.webbeans.component.ProducerMethodBean is not applicable for
the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API


Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],


Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
java.lang.IllegalArgumentException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not applicable for
the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API


Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],


Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
   at


org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:703)
   at


com.lecip.tms.tms_core.application.BeanHelper.getBeanByName(BeanHelper.java:40)

I'm having this pretty trivial bean:


public class AppUserUsernameProvider {

   public static final String LOGGED_IN_USERNAME =
"loggedInAppUserUsername";
   @Inject
   CurrentAppUserContext mAppUserContext;

   @Produces
   //this bean will be looked up by this id
   @Named(LOGGED_IN_USERNAME)
   public String getUsername() {
   return mAppUserContext.getUsername();
   }
}

And then I'm trying to use it like that:

   String username =
BeanHelper.getBeanByName(AppUserUsernameProvider.LOGGED_IN_USERNAME,
String.class);

And it fails on the getBeanByName() call with the stack I pasted. Not
sure
what's going on?

Thank you!

Emmanuel

Re: org.apache.webbeans.component.ProducerMethodBean is not applicable for the bean instance : String

[Emmanuel Touzery]

setting up the environment so that I could debug tomee code doesn't seem 
easy at all :-(
gave it a try and failed so far. I guess there's no tutorial related to 
that that I could look at?


Regards,

Emmanuel

On 19/05/16 09:55, Romain Manni-Bucau wrote:

Maybe a lazy solution but very efficient: put a breakpoint in BeanManagerImpl
line 703 and check what triggered the exception (should be a if at that
point so should be easy to identify).

I didn't say it was not a tomee/OWB bug - we got some in this area when
implementing CDI 1.2 for TomEE 7 so can be an old issue fixed in between.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 9:46 GMT+02:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>:


Hello,

 yes I didn't expect a TomEE bug, but I'm wondering what could cause
this behaviour. This is TomEE 1.7.2 but we're also doing this in another
1.7.2 project, so it's not about the version I think. Maybe some stray
dependency? The beans.xml, the dependencies look OK. Anywhere else I should
look?

 Regards,

Emmanuel

On 18/05/16 15:21, Romain Manni-Bucau wrote:


Hi Emmanuel,

either you use an old version or something else is making it failing, this
test passes:
https://gist.github.com/rmannibucau/1d026806a6bb9b89a957c6fba50e4d46


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>


2016-05-18 13:42 GMT+02:00 Emmanuel Touzery <
emmanuel.touz...@lecip-its.com>
:

Hello,

  I'm porting a Glassfish application to TomEE and I don't understand
this error that I'm getting:

org.apache.openejb.core.transaction.EjbTransactionUtil
handleSystemException
SEVERE: EjbTransactionUtil.handleSystemException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not applicable for
the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API

Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],

Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
java.lang.IllegalArgumentException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not applicable for
the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API

Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],

Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
  at

org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:703)
  at

com.lecip.tms.tms_core.application.BeanHelper.getBeanByName(BeanHelper.java:40)

I'm having this pretty trivial bean:


public class AppUserUsernameProvider {

  public static final String LOGGED_IN_USERNAME =
"loggedInAppUserUsername";
  @Inject
  CurrentAppUserContext mAppUserContext;

  @Produces
  //this bean will be looked up by this id
  @Named(LOGGED_IN_USERNAME)
  public String getUsername() {
  return mAppUserContext.getUsername();
  }
}

And then I'm trying to use it like that:

  String username =
BeanHelper.getBeanByName(AppUserUsernameProvider.LOGGED_IN_USERNAME,
String.class);

And it fails on the getBeanByName() call with the stack I pasted. Not
sure
what's going on?

Thank you!

Emmanuel

Re: org.apache.webbeans.component.ProducerMethodBean is not applicable for the bean instance : String

[Emmanuel Touzery]

Hello,

yes I didn't expect a TomEE bug, but I'm wondering what could cause 
this behaviour. This is TomEE 1.7.2 but we're also doing this in another 
1.7.2 project, so it's not about the version I think. Maybe some stray 
dependency? The beans.xml, the dependencies look OK. Anywhere else I 
should look?


Regards,

Emmanuel

On 18/05/16 15:21, Romain Manni-Bucau wrote:

Hi Emmanuel,

either you use an old version or something else is making it failing, this
test passes:
https://gist.github.com/rmannibucau/1d026806a6bb9b89a957c6fba50e4d46


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 13:42 GMT+02:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>
:


Hello,

 I'm porting a Glassfish application to TomEE and I don't understand
this error that I'm getting:

org.apache.openejb.core.transaction.EjbTransactionUtil
handleSystemException
SEVERE: EjbTransactionUtil.handleSystemException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not applicable for the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API
Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
java.lang.IllegalArgumentException: Given bean type : class
org.apache.webbeans.component.ProducerMethodBean is not applicable for the
bean instance : String, Name:loggedInAppUserUsername, WebBeans
Type:PRODUCERMETHOD, API
Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
 at
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:703)
 at
com.lecip.tms.tms_core.application.BeanHelper.getBeanByName(BeanHelper.java:40)

I'm having this pretty trivial bean:


public class AppUserUsernameProvider {

 public static final String LOGGED_IN_USERNAME =
"loggedInAppUserUsername";
 @Inject
 CurrentAppUserContext mAppUserContext;

 @Produces
 //this bean will be looked up by this id
 @Named(LOGGED_IN_USERNAME)
 public String getUsername() {
 return mAppUserContext.getUsername();
 }
}

And then I'm trying to use it like that:

 String username =
BeanHelper.getBeanByName(AppUserUsernameProvider.LOGGED_IN_USERNAME,
String.class);

And it fails on the getBeanByName() call with the stack I pasted. Not sure
what's going on?

Thank you!

Emmanuel

org.apache.webbeans.component.ProducerMethodBean is not applicable for the bean instance : String

[Emmanuel Touzery]

Hello,

I'm porting a Glassfish application to TomEE and I don't understand 
this error that I'm getting:


org.apache.openejb.core.transaction.EjbTransactionUtil handleSystemException
SEVERE: EjbTransactionUtil.handleSystemException: Given bean type : 
class org.apache.webbeans.component.ProducerMethodBean is not applicable 
for the bean instance : String, Name:loggedInAppUserUsername, WebBeans 
Type:PRODUCERMETHOD, API 
Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable], 
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
java.lang.IllegalArgumentException: Given bean type : class 
org.apache.webbeans.component.ProducerMethodBean is not applicable for 
the bean instance : String, Name:loggedInAppUserUsername, WebBeans 
Type:PRODUCERMETHOD, API 
Types:[java.lang.Comparable,java.lang.Object,java.lang.CharSequence,java.lang.String,java.io.Serializable], 
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]
at 
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:703)
at 
com.lecip.tms.tms_core.application.BeanHelper.getBeanByName(BeanHelper.java:40)


I'm having this pretty trivial bean:


public class AppUserUsernameProvider {

public static final String LOGGED_IN_USERNAME = 
"loggedInAppUserUsername";

@Inject
CurrentAppUserContext mAppUserContext;

@Produces
//this bean will be looked up by this id
@Named(LOGGED_IN_USERNAME)
public String getUsername() {
return mAppUserContext.getUsername();
}
}

And then I'm trying to use it like that:

String username = 
BeanHelper.getBeanByName(AppUserUsernameProvider.LOGGED_IN_USERNAME, 
String.class);


And it fails on the getBeanByName() call with the stack I pasted. Not 
sure what's going on?


Thank you!

Emmanuel

Re: troubleshoot error with the login mechanism

[Emmanuel Touzery]

I see. Doesn't the plugin extract the contents of the war for its own needs, as 
the real tomee does? Then i could find the extract folder and overwrite the 
html/js files there?
I'm not talking of class files here, html/js seem easier?

Emmanuel

- Original Message -
From: Romain Manni-Bucau <rmannibu...@gmail.com>
To: users@tomee.apache.org
Sent: Tue, 24 Nov 2015 20:26:23 +0100 (CET)
Subject: Re: troubleshoot error with the login mechanism

there is synchronization configuration to sync target and your project
files. tomee embedded maven plugin does exactly what you want but is not
yet released.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-11-24 19:58 GMT+01:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>
:

> Hello,
>
> thanks that worked like a charm!
>
> Just one more question maybe. The tomee maven plugin now loads the WAR
> file and starts the app properly. I wonder if I could use it to load from
> the target/ folder where I compile to, without having to package a war?
> Besides allowing for a faster startup time, I would like to use this way of
> launching the app, then edit the HTML & JS files and just reload the app
> for rapid development. Is that possible?
>
> Regards,
>
> Emmanuel
>
> PS: If that'll help someone who'll find this in the archives someday, it's:
>
> 
> org.postgresql:postgresql:9.4-1201-jdbc41
> 
>
> under the configuration tag.
>
> On 24/11/15 19:43, Romain Manni-Bucau wrote:
>
>> the authenticator uses container classloader, just remove postgre from
>> your
>> app and add it in  of the plugin
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>>
>> 2015-11-24 19:41 GMT+01:00 Emmanuel Touzery <
>> emmanuel.touz...@lecip-its.com>
>> :
>>
>> Hello,
>>>
>>> When I start the application normally with a tomee copy on my disk,
>>>>
>>>>> it
>>>>>
>>>>>> works fine. I'm now trying to configure a startup using the tomee
>>>>>> maven
>>>>>> plugin. The login screen comes up but I can't login with this error.
>>>>>>
>>>>> Since
>>>>>
>>>>>> it's the tomee maven plugin, I can pass java system properties but I
>>>>>>
>>>>> can't
>>>>>
>>>>>> edit the tomee configuration files.
>>>>>>
>>>>>> What do you mean? you can provide them in src/main/tomee/conf.
>>>>
>>>> Wow thank you! I had no idea. Ok, so now I got my error, and I'm
>>> confused...
>>>
>>> It says it cannot find the postgresql driver, but the rest of the
>>> application writes to postgresql fine (for instance I have an
>>> authication_log table in which I write that the login failed??). I
>>> specify
>>> the postgresql dependency using the dependencies xml tag in the profile.
>>> So
>>> how come the authentication part cannot find it?
>>>
>>> I paste the relevant bits of the pom.xml (some other part is in my
>>> original email) and the stacktrace I just got now thank to your help.
>>>
>>> 
>>> tomee-test
>>> 
>>> 
>>> org.postgresql
>>> postgresql <-
>>> 9.4-1201-jdbc41
>>> 
>>> 
>>> org.hibernate
>>> hibernate-core
>>> 4.2.15.Final
>>> 
>>> 
>>> org.hibernate
>>> hibernate-entitymanager
>>> 4.2.15.Final
>>> 
>>> 
>>> org.hibernate
>>> hibernate-validator
>>> 4.3.1.Final
>>> 
>>> 
>>> org.javassist
>>> javassist
>>> 3.18.1-GA
>>> 
>>> 
>>> 
>>> 
>>> 
>>> org.apache.openejb.maven
>>> tomee-maven-plugin
>>> [...]
>>>
>>>
>>> Nov 24, 2015 6:37:14 PM org.apache.catalina.realm.JDBCRealm authenticate
>>> SEVERE: Exception performing authentication
>>> java.sql.SQLException: org.postgresql.Driver
&

troubleshoot error with the login mechanism

[Emmanuel Touzery]

Hello,

I'm trying to troubleshoot an issue I have with login in the 
application. The call to HttpServletRequest.login() fails but I have 
trouble finding out exactly where is the problem.


The stack is:

javax.servlet.ServletException: Login failed
at 
org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:850)
at 
org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:830)

at org.apache.catalina.connector.Request.login(Request.java:2637)
at 
org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1064)
at 
javax.servlet.http.HttpServletRequestWrapper.login(HttpServletRequestWrapper.java:307)


When I start the application normally with a tomee copy on my disk, 
it works fine. I'm now trying to configure a startup using the tomee 
maven plugin. The login screen comes up but I can't login with this 
error. Since it's the tomee maven plugin, I can pass java system 
properties but I can't edit the tomee configuration files.
I would like to have the AuthenticatorBase print out debug-level 
log messages. I have tried:


-Dlog4j.category.OpenEJB.options=debug 
-Dlog4j.category.OpenEJB.startup=debug -Dlog4j.category.OpenEJB=debug 
-Dlog4j.rootLogger=debug -Dorg.apache.catalina.authenticator.level=ALL


In the  in the configuration, as well as in 
systemPropertyValues, but it still doesn't print me the extra info I 
would need.


I set it up as a maven profile:

   
   tomee-test
   
  
   
   
 
   
org.apache.openejb.maven
tomee-maven-plugin
 1.7.1
 
   1.7.1
plus
${project.build.directory}/target/generic_tms-14.12.2.war
-Dlog4j.category.OpenEJB.options=debug 
-Dlog4j.category.OpenEJB.startup=debug -Dlog4j.category.OpenEJB=debug 
-Dlog4j.rootLogger=debug -Dorg.apache.catalina.authenticator.level=ALL 
-Dopenejb.validation.output.level=VERBOSE

   
ALL
VERBOSE
debug
debug
debug
debug
   
 
   
 
   
   

How could I get that debug info printed out? Any other advice to 
troubleshoot why the login call fails?


Thank you!

Emmanuel

Re: troubleshoot error with the login mechanism

[Emmanuel Touzery]

Hello,


> When I start the application normally with a tomee copy on my disk, it
>works fine. I'm now trying to configure a startup using the tomee maven
>plugin. The login screen comes up but I can't login with this error. Since
>it's the tomee maven plugin, I can pass java system properties but I can't
>edit the tomee configuration files.
>

What do you mean? you can provide them in src/main/tomee/conf.


Wow thank you! I had no idea. Ok, so now I got my error, and I'm confused...

It says it cannot find the postgresql driver, but the rest of the 
application writes to postgresql fine (for instance I have an 
authication_log table in which I write that the login failed??). I 
specify the postgresql dependency using the dependencies xml tag in the 
profile. So how come the authentication part cannot find it?


 I paste the relevant bits of the pom.xml (some other part is in my 
original email) and the stacktrace I just got now thank to your help.


   
   tomee-test
   

org.postgresql
postgresql <-
9.4-1201-jdbc41


org.hibernate
hibernate-core
4.2.15.Final


org.hibernate
hibernate-entitymanager
4.2.15.Final


org.hibernate
hibernate-validator
4.3.1.Final


org.javassist
javassist
3.18.1-GA

   
   
 
   
org.apache.openejb.maven
tomee-maven-plugin
  [...]


Nov 24, 2015 6:37:14 PM org.apache.catalina.realm.JDBCRealm authenticate
SEVERE: Exception performing authentication
java.sql.SQLException: org.postgresql.Driver
at org.apache.catalina.realm.JDBCRealm.open(JDBCRealm.java:692)
at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:350)
at 
org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:146)
at 
org.apache.tomee.catalina.TomEERealm.authenticate(TomEERealm.java:43)
at 
org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:848)
at 
org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:830)

at org.apache.catalina.connector.Request.login(Request.java:2637)
at 
org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1064)
at 
javax.servlet.http.HttpServletRequestWrapper.login(HttpServletRequestWrapper.java:307)
at 
com.lecip.core.authentication.Authentication.setNextLoginStep(Authentication.java:609)
at 
com.lecip.core.authentication.Authentication.authenticate(Authentication.java:214)

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:483)
at org.apache.el.parser.AstValue.invoke(AstValue.java:278)
at 
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:273)
at 
org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:68)

at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1041)
at 
javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:289)

at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1415)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:765)
at 
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:198)
at 
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:176)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 

Re: troubleshoot error with the login mechanism

[Emmanuel Touzery]

Hello,

thanks that worked like a charm!

Just one more question maybe. The tomee maven plugin now loads the 
WAR file and starts the app properly. I wonder if I could use it to load 
from the target/ folder where I compile to, without having to package a 
war? Besides allowing for a faster startup time, I would like to use 
this way of launching the app, then edit the HTML & JS files and just 
reload the app for rapid development. Is that possible?


Regards,

Emmanuel

PS: If that'll help someone who'll find this in the archives someday, it's:

 
org.postgresql:postgresql:9.4-1201-jdbc41
 

under the configuration tag.

On 24/11/15 19:43, Romain Manni-Bucau wrote:

the authenticator uses container classloader, just remove postgre from your
app and add it in  of the plugin


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-11-24 19:41 GMT+01:00 Emmanuel Touzery <emmanuel.touz...@lecip-its.com>
:


Hello,


 When I start the application normally with a tomee copy on my disk,

it

works fine. I'm now trying to configure a startup using the tomee maven
plugin. The login screen comes up but I can't login with this error.

Since

it's the tomee maven plugin, I can pass java system properties but I

can't

edit the tomee configuration files.


What do you mean? you can provide them in src/main/tomee/conf.


Wow thank you! I had no idea. Ok, so now I got my error, and I'm
confused...

It says it cannot find the postgresql driver, but the rest of the
application writes to postgresql fine (for instance I have an
authication_log table in which I write that the login failed??). I specify
the postgresql dependency using the dependencies xml tag in the profile. So
how come the authentication part cannot find it?

  I paste the relevant bits of the pom.xml (some other part is in my
original email) and the stacktrace I just got now thank to your help.


tomee-test

 
org.postgresql
postgresql <-
9.4-1201-jdbc41
 
 
 org.hibernate
hibernate-core
 4.2.15.Final
 
 
 org.hibernate
hibernate-entitymanager
 4.2.15.Final
 
 
 org.hibernate
hibernate-validator
 4.3.1.Final
 
 
 org.javassist
 javassist
 3.18.1-GA
 


  

org.apache.openejb.maven
tomee-maven-plugin
   [...]


Nov 24, 2015 6:37:14 PM org.apache.catalina.realm.JDBCRealm authenticate
SEVERE: Exception performing authentication
java.sql.SQLException: org.postgresql.Driver
 at org.apache.catalina.realm.JDBCRealm.open(JDBCRealm.java:692)
 at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:350)
 at
org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:146)
 at
org.apache.tomee.catalina.TomEERealm.authenticate(TomEERealm.java:43)
 at
org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:848)
 at
org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:830)
 at org.apache.catalina.connector.Request.login(Request.java:2637)
 at
org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1064)
 at
javax.servlet.http.HttpServletRequestWrapper.login(HttpServletRequestWrapper.java:307)
 at
com.lecip.core.authentication.Authentication.setNextLoginStep(Authentication.java:609)
 at
com.lecip.core.authentication.Authentication.authenticate(Authentication.java:214)
 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:483)
 at org.apache.el.parser.AstValue.invoke(AstValue.java:278)
 at
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:273)
 at
org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
 at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:68)
 at javax.faces.component.UICommand.broadcast(UICommand.java:120)
 at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1041)
 at
javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:289)
 at javax.faces.compone

jax-rs @Path annotation scanning

[Emmanuel Touzery]

Hello,

I know that in glassfish it's possible to do something (with the 
web.xml IIRC) and all the services with @Path annotation are 
automatically taken into account by the container. We ported a GF 
application to tomee and the way we have it configured now is by listing 
every JAX-RS service manually in a class inheriting Application. I tried 
quickly scanning the classpath manually to find classes with the @Path 
annotation but it was quite slow and I'm pretty sure something like that 
must be supported through some option or optional setup?


So, how we go about to enable that scanning and spare ourselves 
that typing everytime we add a new JAX-RS service?


Regards,

Emmanuel

Re: jax-rs @Path annotation scanning

[Emmanuel Touzery]

Hello,

I was hoping that is the case.

OK, if I remove the application class yes I actually see in the log 
output that the services are detected, they're just bound to another URL 
than the one we expect. So I just need to fix the @ApplicationPath 
directive. So that's through the web.xml, however can you just give me 
an example of that section of the web.xml that works for tomee/apache 
cxf jax-rs? All the examples I find online have inheriting from 
Application instead of using the web.xml, for instance there:


http://tomee.apache.org/examples-trunk/rest-example-with-application/README.html

Thank you!

Emmanuel

On 22/10/14 14:42, Romain Manni-Bucau wrote:

Hi

tomee scans out of the box for it. Here some rules:
1) no application class: app is scanned
2) application class(es) exist
a) they are deployed respecting getClasses()/getSingleton()
b) if getClasses() = getSingleton() = empty set = we do 1 but
respecting potential @ApplicatinoPath
3) if you define a servlet in web.xml which has as init param jaxrs
Application fqn then we use it as @Applicatinopath

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-10-22 14:38 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 I know that in glassfish it's possible to do something (with the web.xml
IIRC) and all the services with @Path annotation are automatically taken
into account by the container. We ported a GF application to tomee and the
way we have it configured now is by listing every JAX-RS service manually in
a class inheriting Application. I tried quickly scanning the classpath
manually to find classes with the @Path annotation but it was quite slow and
I'm pretty sure something like that must be supported through some option or
optional setup?

 So, how we go about to enable that scanning and spare ourselves that
typing everytime we add a new JAX-RS service?

 Regards,

Emmanuel

Re: jax-rs @Path annotation scanning

[Emmanuel Touzery]

Thanks a lot, it works great!

Emmanuel

On 22/10/14 14:59, Romain Manni-Bucau wrote:

web-app ...

 servlet
 servlet-namejavax.ws.rs.core.Application/servlet-name
 /servlet
 servlet-mapping
 servlet-namejavax.ws.rs.core.Application/servlet-name
 url-pattern/api/*/url-pattern
 /servlet-mapping
/web-app

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-10-22 14:56 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 I was hoping that is the case.

 OK, if I remove the application class yes I actually see in the log
output that the services are detected, they're just bound to another URL
than the one we expect. So I just need to fix the @ApplicationPath
directive. So that's through the web.xml, however can you just give me an
example of that section of the web.xml that works for tomee/apache cxf
jax-rs? All the examples I find online have inheriting from Application
instead of using the web.xml, for instance there:

http://tomee.apache.org/examples-trunk/rest-example-with-application/README.html

 Thank you!

Emmanuel


On 22/10/14 14:42, Romain Manni-Bucau wrote:

Hi

tomee scans out of the box for it. Here some rules:
1) no application class: app is scanned
2) application class(es) exist
 a) they are deployed respecting getClasses()/getSingleton()
 b) if getClasses() = getSingleton() = empty set = we do 1 but
respecting potential @ApplicatinoPath
3) if you define a servlet in web.xml which has as init param jaxrs
Application fqn then we use it as @Applicatinopath

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-10-22 14:38 GMT+02:00 Emmanuel Touzery
emmanuel.touz...@lecip-its.com:

Hello,

  I know that in glassfish it's possible to do something (with the
web.xml
IIRC) and all the services with @Path annotation are automatically taken
into account by the container. We ported a GF application to tomee and
the
way we have it configured now is by listing every JAX-RS service manually
in
a class inheriting Application. I tried quickly scanning the classpath
manually to find classes with the @Path annotation but it was quite slow
and
I'm pretty sure something like that must be supported through some option
or
optional setup?

  So, how we go about to enable that scanning and spare ourselves that
typing everytime we add a new JAX-RS service?

  Regards,

Emmanuel

Re: [tomee-embedded] tomee sending javamail to port 25 no matter what I specify

[Emmanuel Touzery]

Hello,

thank you! Added this line in the properties section of the 
arquillian.xml and it works great now, thank you!


Emmanuel

On 05/09/14 10:18, Romain Manni-Bucau wrote:

Hi

you miss the resource declaration. (like if you do setXXX()
without the new):

notificationsMail = new://Resource?type=javax.mail.Session


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-09-05 9:07 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 I'm trying to configure tomee-embedded for arquillian tests, that it
would send javamail to port 3025 instead of 25, and failing at achieving it
so far. It doesn't pick up my configuration and keeps sending to port 25.

 Here's how I use it to send email:

 @Resource(name = notificationsMail)
 private Session mailSession;

 I tried this in the arquillian.xml:

 container default=true qualifier=tomee
 configuration
 property name=httpPort8080/property
 property name=stopPort-1/property
 property name=properties
 notificationsMail.mail.smtp.host=localhost
 notificationsMail.mail.smtp.port=3025
 notificationsMail.mail.smtp.socketFactory.port=3025
 notificationsMail.mail.transport.protocol=smtp
 notificationsMail.mail.smtp.user=user
 notificationsMail.mail.smtp.debug=true
 /property
 /configuration
 /container

 To no avail. I also tried giving the extra command-line parameters:
-DnotificationsMail.mail.smtp.port=3025
-DnotificationsMail.mail.smtp.socketFactory.port=3025

 And it also doesn't help.

 What am I doing wrong?

 Thank you,

Emmanuel

Re: tomee arquillian

[Emmanuel Touzery]

)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 152 more

On 21/08/14 23:21, Romain Manni-Bucau wrote:

FYI:

 dependency
   groupIdorg.jboss.arquillian.container/groupId
   artifactIdarquillian-junit-container/artifactId
   version1.1.5.Final/version
   scopetest/scope
 /dependency
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version4.11/version
   scopetest/scope
 /dependency
 dependency
   groupIdorg.apache.openejb/groupId
   artifactIdarquillian-tomee-embedded/artifactId
   version2.0.0-SNAPSHOT/version !-- or 1.7.0 --
 /dependency

@MessageDriven
public class AnMdb implements MessageListener {
 @Override
 public void onMessage(final Message message) {
 System.out.println(message);
 }
}

and

@RunWith(Arquillian.class)
public class TheTest {
 @Deployment
 public static Archive? war() {
 return ShrinkWrap.create(WebArchive.class, the-test.war)
 .addClasses(AnMdb.class);
 }

 @Resource(name = AnMdb)
 private Queue queue;

 @Resource
 private ConnectionFactory connectionFactory;

 @Test
 public void run() throws JMSException, InterruptedException {
 final Connection connection = connectionFactory.createConnection();
 final Session session = connection.createSession(false, 0);
 final MessageProducer producer = session.createProducer(queue);
 producer.send(session.createTextMessage(hello));
 producer.close();
 session.close();
 connection.close();

 sleep(1);
 }
}


works as expected (ok code is not that sexy but that was not the purpose ;))


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 22:48 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 thought you'd like to know, for now I decided to go for a quick solution
as we have many other tasks waiting and moved to temporarily simply exclude
the classes using JMS from the shrinkwrap to have at least tests working. Of
course this prevents us to test the JMS-supported functionnality for now, I
hope to get back to this soon.

 I used this in the createArchive():
.addPackages(true, Filters.exclude(regex of the classes to exclude), our
package prefix)

 Regards,


Emmanuel

On 21/08/14 15:17, Romain Manni-Bucau wrote:

1) openejb-core-hibernate instead of openejb-core for embedded case ;)

2) same version (ie tomee 1.7)? You can also just drop it and
configure what you need in arquillian.xml, what is the difference?

arquillian-tomee-*-tests are our test suites modules, don't use it.
Pointed out the pom for other dependencies. Basically what you need is

http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/arquillian-tomee-jms-tests/src/test/resources/arquillian.xml
(tomee-remote block)


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 15:11 GMT+02:00 Emmanuel Touzery
emmanuel.touz...@lecip-its.com:

Hello,

  great about 1), good to know that's an option. I also considered
running
simply openejb 4.7.0... To me it seems like tomee+ minus some things so I
expected it to work, but it failed at startup, I think due to some JPA
problem (we're also using hibernate...).

  About 2) no in fact I am exactly trying to use the already running
tomee, which is the one that we use to develop the application, which is
tomee+ and which should work fine. There is only one tomee running on my
dev
machine and that is the one I want. Can you make sense of that error, or
tell me where to get a more descriptive one?

  Thank you!

Emmanuel


On 21/08/14 15:06, Romain Manni-Bucau wrote:

Hi

1) you can use tomee-embedded + adding dependencies you need (need
to spend few time but that works) - this pom


http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/pom.xml
test jaxrs, jaxws, and jms against tomee remote and tomee embedded,
just few dependencies to add (surely openejb-core to force and maybe
some activemq)
2) your error means you have a tomee or tomcat already running which
is reused and that's the not one you expected I think


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 14:24 GMT+02:00 Emmanuel Touzery
emmanuel.touz...@lecip-its.com:

Hello,

   we have a working arquillian setup with tomee embedded. But we
now
started using tomee plus instead of the usual tomee, because we are now
using also

tomee arquillian

[Emmanuel Touzery]

Hello,

we have a working arquillian setup with tomee embedded. But we now 
started using tomee plus instead of the usual tomee, because we are now 
using also JMS through activeMQ.


Now of course the arquillian tests fail because they can't find the 
JMS bits.


Since there is no tomee plus artifact to use instead of the plain 
arquillian-tomee-embedded, I'm trying to use instead 
arquillian-tomee-remote and have it connect to a running tomee+ instance 
on localhost (it should also speed up the tests, saving the tomee 
embedded startup time).


However it fails with an error that I don't understand (can't get 
appInfo). Keep in mind that when configured with embedded tomee 
everything works fine (except for the JMS part, again).


There is really nothing else in the tomee logs. I checked in the 
tomee logs folder and I believe there is nothing else to be found.


Any idea what is the problem, what could I do to fix it or gather 
more information on the issue?


Regards,

Emmanuel

---
 T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
MaxPermSize=512m; support was removed in 8.0

Running XX
Aug 21, 2014 2:12:55 PM org.reflections.Reflections scan
INFO: Reflections took 191 ms to scan 4 urls, producing 121 keys and 943 
values
Aug 21, 2014 2:12:55 PM 
org.apache.tomee.arquillian.remote.RemoteTomEEContainer start

INFO: TomEE found running on port 8080
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO: 
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}

Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO: 
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM 
org.apache.openejb.arquillian.common.TomEEContainer deploy
SEVERE: appInfo was not found for 
/tmp/arquillian-tomee-app-working-dir/0/test.war, available are: 
[/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/ROOT, 
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/tomee, 
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/manager, 
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/host-manager, 
openejb, /home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/docs]

org.apache.openejb.OpenEJBException: can't get appInfo
at 
org.apache.openejb.arquillian.common.TomEEContainer.deploy(TomEEContainer.java:288)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)

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:483)
at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at 
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)

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:483)
at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at 
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)

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:483)
at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at 

Re: tomee arquillian

[Emmanuel Touzery]

Hello,

great about 1), good to know that's an option. I also considered 
running simply openejb 4.7.0... To me it seems like tomee+ minus some 
things so I expected it to work, but it failed at startup, I think due 
to some JPA problem (we're also using hibernate...).


About 2) no in fact I am exactly trying to use the already running 
tomee, which is the one that we use to develop the application, which is 
tomee+ and which should work fine. There is only one tomee running on my 
dev machine and that is the one I want. Can you make sense of that 
error, or tell me where to get a more descriptive one?


Thank you!

Emmanuel

On 21/08/14 15:06, Romain Manni-Bucau wrote:

Hi

1) you can use tomee-embedded + adding dependencies you need (need
to spend few time but that works) - this pom
http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/pom.xml
test jaxrs, jaxws, and jms against tomee remote and tomee embedded,
just few dependencies to add (surely openejb-core to force and maybe
some activemq)
2) your error means you have a tomee or tomcat already running which
is reused and that's the not one you expected I think


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 14:24 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 we have a working arquillian setup with tomee embedded. But we now
started using tomee plus instead of the usual tomee, because we are now
using also JMS through activeMQ.

 Now of course the arquillian tests fail because they can't find the JMS
bits.

 Since there is no tomee plus artifact to use instead of the plain
arquillian-tomee-embedded, I'm trying to use instead arquillian-tomee-remote
and have it connect to a running tomee+ instance on localhost (it should
also speed up the tests, saving the tomee embedded startup time).

 However it fails with an error that I don't understand (can't get
appInfo). Keep in mind that when configured with embedded tomee everything
works fine (except for the JMS part, again).

 There is really nothing else in the tomee logs. I checked in the tomee
logs folder and I believe there is nothing else to be found.

 Any idea what is the problem, what could I do to fix it or gather more
information on the issue?

 Regards,

Emmanuel

---
  T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m;
support was removed in 8.0
Running XX
Aug 21, 2014 2:12:55 PM org.reflections.Reflections scan
INFO: Reflections took 191 ms to scan 4 urls, producing 121 keys and 943
values
Aug 21, 2014 2:12:55 PM
org.apache.tomee.arquillian.remote.RemoteTomEEContainer start
INFO: TomEE found running on port 8080
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM org.apache.openejb.arquillian.common.TomEEContainer
deploy
SEVERE: appInfo was not found for
/tmp/arquillian-tomee-app-working-dir/0/test.war, available are:
[/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/ROOT,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/tomee,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/manager,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/host-manager,
openejb, /home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/docs]
org.apache.openejb.OpenEJBException: can't get appInfo
 at
org.apache.openejb.arquillian.common.TomEEContainer.deploy(TomEEContainer.java:288)
 at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
 at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
 at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
 at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
 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:483)
 at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
 at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
 at
org.jboss.arquillian.core.impl.EventContextImpl.proceed

Re: tomee arquillian

[Emmanuel Touzery]

ah, in that pom I see again mentioned arquillian-tomee-jms-tests, I'm 
not sure exactly what is that artifact.. some add-on for 
arquillian-tomee-embedded? Some standalone artifact? I think I'll still 
insist some more on tomee remote to a running tomee first..


Emmanuel

On 21/08/14 15:06, Romain Manni-Bucau wrote:

1) you can use tomee-embedded + adding dependencies you need (need
to spend few time but that works) - this pom
http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/pom.xml
test jaxrs, jaxws, and jms against tomee remote and tomee embedded,
just few dependencies to add (surely openejb-core to force and maybe
some activemq)

Re: tomee arquillian

[Emmanuel Touzery]

1) thanks I'll check this out

2) yes, same version. The advantage is that to run a single test, you 
save the startup time of the embedded container, if you can just reuse 
the tomee which is running all the time anyway. Plus it's closer to the 
production environment. But since you gave me more advice on the 
embedded use-case I guess I'll focus more on that...


Thank you again!

Emmanuel

On 21/08/14 15:17, Romain Manni-Bucau wrote:

1) openejb-core-hibernate instead of openejb-core for embedded case ;)

2) same version (ie tomee 1.7)? You can also just drop it and
configure what you need in arquillian.xml, what is the difference?

arquillian-tomee-*-tests are our test suites modules, don't use it.
Pointed out the pom for other dependencies. Basically what you need is
http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/arquillian-tomee-jms-tests/src/test/resources/arquillian.xml
(tomee-remote block)


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 15:11 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 great about 1), good to know that's an option. I also considered running
simply openejb 4.7.0... To me it seems like tomee+ minus some things so I
expected it to work, but it failed at startup, I think due to some JPA
problem (we're also using hibernate...).

 About 2) no in fact I am exactly trying to use the already running
tomee, which is the one that we use to develop the application, which is
tomee+ and which should work fine. There is only one tomee running on my dev
machine and that is the one I want. Can you make sense of that error, or
tell me where to get a more descriptive one?

 Thank you!

Emmanuel


On 21/08/14 15:06, Romain Manni-Bucau wrote:

Hi

1) you can use tomee-embedded + adding dependencies you need (need
to spend few time but that works) - this pom

http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/pom.xml
test jaxrs, jaxws, and jms against tomee remote and tomee embedded,
just few dependencies to add (surely openejb-core to force and maybe
some activemq)
2) your error means you have a tomee or tomcat already running which
is reused and that's the not one you expected I think


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 14:24 GMT+02:00 Emmanuel Touzery
emmanuel.touz...@lecip-its.com:

Hello,

  we have a working arquillian setup with tomee embedded. But we now
started using tomee plus instead of the usual tomee, because we are now
using also JMS through activeMQ.

  Now of course the arquillian tests fail because they can't find the
JMS
bits.

  Since there is no tomee plus artifact to use instead of the plain
arquillian-tomee-embedded, I'm trying to use instead
arquillian-tomee-remote
and have it connect to a running tomee+ instance on localhost (it should
also speed up the tests, saving the tomee embedded startup time).

  However it fails with an error that I don't understand (can't get
appInfo). Keep in mind that when configured with embedded tomee
everything
works fine (except for the JMS part, again).

  There is really nothing else in the tomee logs. I checked in the
tomee
logs folder and I believe there is nothing else to be found.

  Any idea what is the problem, what could I do to fix it or gather
more
information on the issue?

  Regards,

Emmanuel

---
   T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=512m;
support was removed in 8.0
Running XX
Aug 21, 2014 2:12:55 PM org.reflections.Reflections scan
INFO: Reflections took 191 ms to scan 4 urls, producing 121 keys and 943
values
Aug 21, 2014 2:12:55 PM
org.apache.tomee.arquillian.remote.RemoteTomEEContainer start
INFO: TomEE found running on port 8080
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM
org.apache.openejb.arquillian.common.TomEEContainer
deploy
SEVERE: appInfo was not found for
/tmp/arquillian-tomee-app-working-dir/0/test.war, available are:
[/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/ROOT,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/tomee,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/manager,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/host-manager,
openejb, /home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/docs

Re: tomee arquillian

[Emmanuel Touzery]

Hello,

thought you'd like to know, for now I decided to go for a quick 
solution as we have many other tasks waiting and moved to temporarily 
simply exclude the classes using JMS from the shrinkwrap to have at 
least tests working. Of course this prevents us to test the 
JMS-supported functionnality for now, I hope to get back to this soon.


I used this in the createArchive():
.addPackages(true, Filters.exclude(regex of the classes to exclude), 
our package prefix)


Regards,

Emmanuel

On 21/08/14 15:17, Romain Manni-Bucau wrote:

1) openejb-core-hibernate instead of openejb-core for embedded case ;)

2) same version (ie tomee 1.7)? You can also just drop it and
configure what you need in arquillian.xml, what is the difference?

arquillian-tomee-*-tests are our test suites modules, don't use it.
Pointed out the pom for other dependencies. Basically what you need is
http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/arquillian-tomee-jms-tests/src/test/resources/arquillian.xml
(tomee-remote block)


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 15:11 GMT+02:00 Emmanuel Touzery emmanuel.touz...@lecip-its.com:

Hello,

 great about 1), good to know that's an option. I also considered running
simply openejb 4.7.0... To me it seems like tomee+ minus some things so I
expected it to work, but it failed at startup, I think due to some JPA
problem (we're also using hibernate...).

 About 2) no in fact I am exactly trying to use the already running
tomee, which is the one that we use to develop the application, which is
tomee+ and which should work fine. There is only one tomee running on my dev
machine and that is the one I want. Can you make sense of that error, or
tell me where to get a more descriptive one?

 Thank you!

Emmanuel


On 21/08/14 15:06, Romain Manni-Bucau wrote:

Hi

1) you can use tomee-embedded + adding dependencies you need (need
to spend few time but that works) - this pom

http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/pom.xml
test jaxrs, jaxws, and jms against tomee remote and tomee embedded,
just few dependencies to add (surely openejb-core to force and maybe
some activemq)
2) your error means you have a tomee or tomcat already running which
is reused and that's the not one you expected I think


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-21 14:24 GMT+02:00 Emmanuel Touzery
emmanuel.touz...@lecip-its.com:

Hello,

  we have a working arquillian setup with tomee embedded. But we now
started using tomee plus instead of the usual tomee, because we are now
using also JMS through activeMQ.

  Now of course the arquillian tests fail because they can't find the
JMS
bits.

  Since there is no tomee plus artifact to use instead of the plain
arquillian-tomee-embedded, I'm trying to use instead
arquillian-tomee-remote
and have it connect to a running tomee+ instance on localhost (it should
also speed up the tests, saving the tomee embedded startup time).

  However it fails with an error that I don't understand (can't get
appInfo). Keep in mind that when configured with embedded tomee
everything
works fine (except for the JMS part, again).

  There is really nothing else in the tomee logs. I checked in the
tomee
logs folder and I believe there is nothing else to be found.

  Any idea what is the problem, what could I do to fix it or gather
more
information on the issue?

  Regards,

Emmanuel

---
   T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=512m;
support was removed in 8.0
Running XX
Aug 21, 2014 2:12:55 PM org.reflections.Reflections scan
INFO: Reflections took 191 ms to scan 4 urls, producing 121 keys and 943
values
Aug 21, 2014 2:12:55 PM
org.apache.tomee.arquillian.remote.RemoteTomEEContainer start
INFO: TomEE found running on port 8080
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM org.apache.openejb.client.EventLogger log
INFO:
RemoteInitialContextCreated{providerUri=http://localhost:8080/tomee/ejb}
Aug 21, 2014 2:12:57 PM
org.apache.openejb.arquillian.common.TomEEContainer
deploy
SEVERE: appInfo was not found for
/tmp/arquillian-tomee-app-working-dir/0/test.war, available are:
[/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/ROOT,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/tomee,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps/manager,
/home/emmanuel/programs/apache-tomee-plus-1.7.0-1/webapps

tomee+hibernate+java8 possible?

[Emmanuel Touzery]

Hello,

we are using tomee 1.6 with hibernate 4.2. Now that 1.7 is out, we 
are interested to migrate to it, and start using the new java8 features. 
We are not sure which hibernate version introduced support for java8 (it 
turns out extremely difficult to come to that information...), so we 
planned to move to the latest hibernate 4.3 version, however we found this:

http://stackoverflow.com/a/15771969/516188

There it's written /However, Hibernate 4.3+ (JPA 2.1) is not 
supported by TomEE, because it's Java EE 7./. I wonder, is that true? 
That we can't use hibernate 4.3+ with tomee 1.x? We definitely don't 
want to use JEE7 features until all is ready. We are looking for a 
supported configuration.


If that is true, does anyone know whether that prevents us from 
using tomee 1.x+hibernate+java8? Or maybe hibernate 4.2.x is enough for 
that? (yes, this last question I guess I should rather ask in a 
hibernate forum, but I can try asking here just in case someone happens 
to know)


Regards,

Emmanuel