Re: 7.0.3 release

[Romain Manni-Bucau]

did a few on my blog
https://blog-rmannibucau.rhcloud.com/#/search;query=meecrowave and there is
the website openwebbeans.apache.org/meecrowave

strictly speaking it is mainly inspired from recent tomee embedded changes
but simplifying it a lot and making the stack consistent/uniform (we can't
at tomee cause of all possibilities we have). It is limiting it to
cdi+jaxrs (not even jpa). Opens a lot of doors nowaday even you can feel
frustrated for JPA backends.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-02-23 22:25 GMT+01:00 hwaastad :

> Meecrowave
>
> Is that a new kid on the block?  ;-)
>
> Seriously, seems cool, any blog articles yet?
>
> /hw
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/7-0-3-release-tp4681145p4681150.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: 7.0.3 release

[hwaastad]

Meecrowave

Is that a new kid on the block?  ;-)

Seriously, seems cool, any blog articles yet?

/hw




--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/7-0-3-release-tp4681145p4681150.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: 7.0.3 release

[cocorossello]

Ok, thanks



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/7-0-3-release-tp4681145p4681149.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: CMP2 enitity get is making update query in Linux environment

[Romain Manni-Bucau]

Hmm

xerces is know has impacting and useless these days, others shouldnt be
modified compared to a plain tomee instance - we do it for you.


Le 23 févr. 2017 20:04, "seenu.atluri"  a écrit :

> Thank you Romain
>
> When we look at it closely, our catilina.bat is customized to have endorsed
> directory, but not catalina.sh.
> Here are the list of jars we have in endorsed.
>
> annotation-api.jar
> jaxb-api.jar
> xercesImpl.jar
> xercesImpl-2.9.0.jar
>
> Don't like the fact that these 4 jars could impact the application this
> way.
>
> Thanks & Regards,
> Srinivas Atluri.
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/CMP2-enitity-get-is-making-update-query-in-
> Linux-environment-tp4681136p4681147.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: CMP2 enitity get is making update query in Linux environment

[seenu.atluri]

Thank you Romain

When we look at it closely, our catilina.bat is customized to have endorsed
directory, but not catalina.sh.
Here are the list of jars we have in endorsed.

annotation-api.jar
jaxb-api.jar
xercesImpl.jar
xercesImpl-2.9.0.jar

Don't like the fact that these 4 jars could impact the application this way.

Thanks & Regards,
Srinivas Atluri.



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/CMP2-enitity-get-is-making-update-query-in-Linux-environment-tp4681136p4681147.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: 7.0.3 release

[Romain Manni-Bucau]

waiting for meecrowave release ATM (and try to avoid too much parallel
releases since time is very limited these days) but if nobody has started
tomee one once it meecrowave is over i can launch it. Don't hesitate to
ping back if you see it not moving in some days.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-02-23 16:38 GMT+01:00 cocorossello :

> Hi,
>
> I would like to request, if possible, a 7.0.3 release. I read in other
> posts
> that there is nothing really pending for a (minor) new release.
>
> There are some bug fixes (most notable the CUTask one) that we have patched
> into our server, it's a minor inconvenience for us to work on snapshots, so
> it would be really good if a release can happen soon.
>
> Best regards,
> Vicente.
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/7-0-3-release-tp4681145.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

7.0.3 release

[cocorossello]

Hi,

I would like to request, if possible, a 7.0.3 release. I read in other posts
that there is nothing really pending for a (minor) new release. 

There are some bug fixes (most notable the CUTask one) that we have patched
into our server, it's a minor inconvenience for us to work on snapshots, so
it would be really good if a release can happen soon.

Best regards,
Vicente.




--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/7-0-3-release-tp4681145.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: CMP2 enitity get is making update query in Linux environment

[Romain Manni-Bucau]

do you launch it the same way? openejb-javaagent is there in all cases?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-02-23 16:00 GMT+01:00 seenu.atluri :

> Yes Romain.
>
> Not only this we are seeing one more issue. In windows "fetch=EAGER" on
> one-to-many is working fine. When the same is deployed in Unix/Linux we are
> getting below exception. I googled it, there are posts discussing about
> Eager fetch is not supported when
> "openjpa.RuntimeUnenhancedClasses=supported". Looks like TomEE set it to
> supported by default, but wondering why we are not seeing this issue in
> windows.
>
> You had helped us a lot during this migration process. We tested
> application
> in Windows locally,but when it is being tested in integration environment
> on
> linux we are seeing all these issues. your help in this regard is highly
> appreciated.
>
>
> Caused by:
> org.apache.openejb.core.transaction.TransactionRolledbackException: The
> transaction has been marked rollback only because the bean encountered a
> non-application exception
> :org.apache.openjpa.persistence.PersistenceException : null
> at
> org.apache.openejb.core.transaction.EjbTransactionUtil.
> handleSystemException(EjbTransactionUtil.java:151)
> [openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.cmp.CmpContainer.findEJBObject(
> CmpContainer.java:750)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at org.apache.openejb.core.cmp.CmpContainer.invoke(
> CmpContainer.java:271)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.entity.EntityEjbHomeHandler.
> findX(EntityEjbHomeHandler.java:65)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(
> EjbHomeProxyHandler.java:199)
> ~[openejb-core-7.0.1.jar:7.0.1]
> ... 68 more
> Caused by: org.apache.openjpa.persistence.PersistenceException
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:1029)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:928)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(
> JDBCStoreManager.java:1032)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.jdbc.sql.AbstractResult.load(
> AbstractResult.java:280)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(
> SelectImpl.java:2382)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.jdbc.sql.AbstractResult.load(
> AbstractResult.java:274)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.
> getResultObject(InstanceResultObjectProvider.java:59)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:35)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.
> java:1257)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.
> java:1013)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:869)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:800)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(
> DelegatingQuery.java:541)
> ~[openjpa-2.4.1.jar:2.4.1]
> at org.apache.openjpa.persistence.QueryImpl.execute(
> QueryImpl.java:274)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:290)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> org.apache.openejb.core.cmp.jpa.JpaCmpEngine.executeSelectQuery(
> JpaCmpEngine.java:280)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.cmp.jpa.JpaCmpEngine.queryBeans(
> JpaCmpEngine.java:234)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.cmp.CmpContainer.findEJBObject(
> CmpContainer.java:702)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at org.apache.openejb.core.cmp.CmpContainer.invoke(
> CmpContainer.java:271)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.entity.EntityEjbHomeHandler.
> findX(EntityEjbHomeHandler.java:65)
> ~[openejb-core-7.0.1.jar:7.0.1]
> at
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(
> EjbHomeProxyHandler.java:199)
> ~[openejb-core-7.0.1.jar:7.0.1]
> ... 68 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setInverseRelation(
> JDBCStoreManager.java:452)
> ~[openjpa-2.4.1.jar:2.4.1]
> at
> 

Re: CMP2 enitity get is making update query in Linux environment

[seenu.atluri]

Yes Romain.

Not only this we are seeing one more issue. In windows "fetch=EAGER" on
one-to-many is working fine. When the same is deployed in Unix/Linux we are
getting below exception. I googled it, there are posts discussing about
Eager fetch is not supported when
"openjpa.RuntimeUnenhancedClasses=supported". Looks like TomEE set it to
supported by default, but wondering why we are not seeing this issue in
windows.

You had helped us a lot during this migration process. We tested application
in Windows locally,but when it is being tested in integration environment on
linux we are seeing all these issues. your help in this regard is highly
appreciated.


Caused by:
org.apache.openejb.core.transaction.TransactionRolledbackException: The
transaction has been marked rollback only because the bean encountered a
non-application exception
:org.apache.openjpa.persistence.PersistenceException : null
at
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException(EjbTransactionUtil.java:151)
[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.cmp.CmpContainer.findEJBObject(CmpContainer.java:750)
~[openejb-core-7.0.1.jar:7.0.1]
at 
org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:271)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.entity.EntityEjbHomeHandler.findX(EntityEjbHomeHandler.java:65)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:199)
~[openejb-core-7.0.1.jar:7.0.1]
... 68 more
Caused by: org.apache.openjpa.persistence.PersistenceException
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:1029)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:928)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1032)
~[openjpa-2.4.1.jar:2.4.1]
at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2382)
~[openjpa-2.4.1.jar:2.4.1]
at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:274)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:35)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1257)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1013)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:869)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:800)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:541)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:274)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:290)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openejb.core.cmp.jpa.JpaCmpEngine.executeSelectQuery(JpaCmpEngine.java:280)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.cmp.jpa.JpaCmpEngine.queryBeans(JpaCmpEngine.java:234)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.cmp.CmpContainer.findEJBObject(CmpContainer.java:702)
~[openejb-core-7.0.1.jar:7.0.1]
at 
org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:271)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.entity.EntityEjbHomeHandler.findX(EntityEjbHomeHandler.java:65)
~[openejb-core-7.0.1.jar:7.0.1]
at
org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:199)
~[openejb-core-7.0.1.jar:7.0.1]
... 68 more
Caused by: java.lang.NullPointerException
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setInverseRelation(JDBCStoreManager.java:452)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:412)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:305)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
~[openjpa-2.4.1.jar:2.4.1]
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1048)
~[openjpa-2.4.1.jar:2.4.1]
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:1006)
~[openjpa-2.4.1.jar:2.4.1]
at 

Re: TomEE 7.0.2 and WebSphere MQ

[bekirby]

Thank you for the quick response. Adding the exclusions got rid of all the
warnings and now everything is working as expected.



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-2-and-WebSphere-MQ-tp4681134p4681142.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: CMP2 enitity get is making update query in Linux environment

[Romain Manni-Bucau]

Hi,

did you ensure you have the exact same database and datasource
configuration on both OS?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-02-23 7:33 GMT+01:00 seenu.atluri :

> Hi,
>
> We have legacy application with bunch of CMP2 beans migrated to TomEE from
> Weblogic. We have a getEntity business methods in SSB which are running in
> transaction. During transaction commit, OpenJPA is making update query with
> no values changed for all child entities (one-to-many relationship)
> although
> there is no change to the entity. This making the process too slow and
> leading transaction time-out sometimes. Obviously, Session cache is
> expected
> to hold these entities and make db hit only if the child entities are
> changed, not always.
>
> We see this behavior only in Unix, not in Windows environment. Does anybody
> experience this problem?
> Would appreciate your help.
>
> Thanks & Regards,
> Srinivas Atluri.
>
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/CMP2-enitity-get-is-making-update-query-in-
> Linux-environment-tp4681136.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

CMP2 enitity get is making update query in Linux environment

[seenu.atluri]

Hi,

We have legacy application with bunch of CMP2 beans migrated to TomEE from
Weblogic. We have a getEntity business methods in SSB which are running in
transaction. During transaction commit, OpenJPA is making update query with
no values changed for all child entities (one-to-many relationship) although
there is no change to the entity. This making the process too slow and
leading transaction time-out sometimes. Obviously, Session cache is expected
to hold these entities and make db hit only if the child entities are
changed, not always.

We see this behavior only in Unix, not in Windows environment. Does anybody
experience this problem?
Would appreciate your help.

Thanks & Regards,
Srinivas Atluri.

 



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/CMP2-enitity-get-is-making-update-query-in-Linux-environment-tp4681136.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: TomEE 7.0.2 - increasing quartz tx database connections

[Romain Manni-Bucau]

2017-02-23 12:11 GMT+01:00 tschuler :

> Thanks Romain for clarification.
> Did the quartz handling switched to outside the transaction with
> introduction of the "shaded" quartz access?
>
>
No, never has been in the tx I think - if we run it in the tx then quartz
meta can be rolled back with the business code which is wrong.


>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/TomEE-7-0-2-increasing-quartz-tx-database-
> connections-tp4681007p4681139.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: TomEE 7.0.2 - increasing quartz tx database connections

[tschuler]

Thanks Romain for clarification.
Did the quartz handling switched to outside the transaction with
introduction of the "shaded" quartz access?




--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-2-increasing-quartz-tx-database-connections-tp4681007p4681139.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: TomEE 7.0.2 - increasing quartz tx database connections

[Romain Manni-Bucau]

Yes, summarized it could be said this way I think: "quartz doc is valid but
tomee usage of quartz is 'internal' and outside the EJB".

If you use yourself quartz from the EJB then you could use the CMT config
but not the case using @Schedule IIRC.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-02-23 11:58 GMT+01:00 tschuler :

> Hi Romain!
>
> We configured quartz for using JDBC-JobStoreCMT (see
> http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/
> ConfigJobStoreCMT.html).
> It is suggested to be used if "applications are using JTA transactions
> (such
> as via EJB Session Beans) to perform their work."
> To my way of thinking that's exactly what we do if we use scheduled beans.
> The configuration needs two datasources (CMT and non-CMT).
> If we change the configuration to use the non-CMT datasource also as CMT
> datasource - no more open connections are left behind.
>
> That means that even if scheduled beans are used the quartz handling
> happens
> outside the transaction - did I get it right?
>
> So JDBC-JobStoreTX (see
> http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/
> ConfigJobStoreTX.html)
> should be used instead?
>
> Best regards,
> Thomas
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/TomEE-7-0-2-increasing-quartz-tx-database-
> connections-tp4681007p4681137.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: TomEE 7.0.2 - increasing quartz tx database connections

[tschuler]

Hi Romain!

We configured quartz for using JDBC-JobStoreCMT (see
http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/ConfigJobStoreCMT.html).
It is suggested to be used if "applications are using JTA transactions (such
as via EJB Session Beans) to perform their work."
To my way of thinking that's exactly what we do if we use scheduled beans.
The configuration needs two datasources (CMT and non-CMT).
If we change the configuration to use the non-CMT datasource also as CMT
datasource - no more open connections are left behind.

That means that even if scheduled beans are used the quartz handling happens
outside the transaction - did I get it right?

So JDBC-JobStoreTX (see
http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/ConfigJobStoreTX.html)
should be used instead?

Best regards,
Thomas



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-2-increasing-quartz-tx-database-connections-tp4681007p4681137.html
Sent from the TomEE Users mailing list archive at Nabble.com.