date:20180208

Re: null QueryInvocationContext (querydsl)

2018-02-08 Thread John D. Ament

Correct, QueryInvocationContext is not valid in the scenario you have
listed.

On Thu, Feb 8, 2018 at 10:47 AM Luís Alves  wrote:

> well...I can acess the current EM with:
>
> final JPAQuery qry = new JPAQuery(
> *entityManager()*).from(c)
> .where(c.key.eq(key));
>
> so I don't need to inject the context.
> I don't need a fancy delegate.
>
>
> On Thu, Feb 8, 2018 at 3:39 PM, Luís Alves  wrote:
>
> > Hello,
> >
> > I'm trying to user QueryDSL. From the examples at
> > https://deltaspike.apache.org/documentation/data.html
> >
> > O got to something like this:
> >
> > @Repository
> > public abstract class ConfigurationRepository extends
> > AbstractEntityRepository
> > implements EntityRepository,
> > EntityManagerDelegate
> > {
> >
> > @Inject
> > private QueryInvocationContext context;
> >
> > /**
> >  * Find by key.
> >  *
> >  * @param key
> >  *the key
> >  * @return the configuration
> >  */
> > public Configuration getByKey(String key)
> > {
> > final QConfiguration c = QConfiguration.configuration;
> >
> > final JPAQuery qry = new JPAQuery(
> > context.getEntityManager()).from(c)
> > .where(c.key.eq(key));
> > return qry.fetchFirst();
> > }
> > }
> >
> > The problem is that the context is null. Am I missing something? Do we
> > need to be inside a TX? Currently I'm invoking like:
> >
> > @Transactional(value = TxType.SUPPORTS)
> > public void findConfig()
> > {
> > final Configuration c = configurationRepository.
> > getByKey("b6ace366-5678-41dd-ba44-5126cb40c7d9");
> > }
> >
> > Regards,
> > LA
> >
>

null QueryInvocationContext (querydsl)

2018-02-08 Thread Luís Alves

Hello,

I'm trying to user QueryDSL. From the examples at
https://deltaspike.apache.org/documentation/data.html

O got to something like this:

@Repository
public abstract class ConfigurationRepository extends
AbstractEntityRepository
implements EntityRepository,
EntityManagerDelegate
{

@Inject
private QueryInvocationContext context;

/**
 * Find by key.
 *
 * @param key
 *the key
 * @return the configuration
 */
public Configuration getByKey(String key)
{
final QConfiguration c = QConfiguration.configuration;

final JPAQuery qry = new
JPAQuery(context.getEntityManager()).from(c)
.where(c.key.eq(key));
return qry.fetchFirst();
}
}

The problem is that the context is null. Am I missing something? Do we need
to be inside a TX? Currently I'm invoking like:

@Transactional(value = TxType.SUPPORTS)
public void findConfig()
{
final Configuration c =
configurationRepository.getByKey("b6ace366-5678-41dd-ba44-5126cb40c7d9");
}

Regards,
LA

Re: deltaspike with javax.transaction.Transactional

2018-02-08 Thread Luís Alves

yup :) thanks John

On Thu, Feb 8, 2018 at 12:39 PM, John D. Ament 
wrote:

> Luis,
>
> This issue is solved by using the global alternative in
> META-INF/apache-deltaspike.properties.
>
> John
>
> On Thu, Feb 8, 2018 at 7:11 AM Luís Alves  wrote:
>
> > So... from the stack:
> >
> > Caused by: java.lang.IllegalStateException: A JTA EntityManager cannot
> use
> > getTransaction()
> > at
> >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.getTransaction(
> AbstractEntityManagerImpl.java:1333)
> > at
> >
> > org.jboss.as.jpa.container.AbstractEntityManager.getTransaction(
> AbstractEntityManager.java:518)
> > at org.apache.deltaspike.jpa.impl.transaction.
> > *ResourceLocalTransactionStrategy*
> > .getTransaction(ResourceLocalTransactionStrategy.java:370)
> > at
> >
> > org.apache.deltaspike.jpa.impl.transaction.
> ResourceLocalTransactionStrategy.rollbackAllTransactions(
> ResourceLocalTransactionStrategy.java:336)
> > at
> >
> > org.apache.deltaspike.jpa.impl.transaction.
> ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrate
> gy.java:154)
> > at
> >
> > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.
> executeTransactional(TransactionalQueryRunner.java:72)
> > at
> >
> > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.
> executeQuery(TransactionalQueryRunner.java:54)
> > at
> >
> > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$
> Proxy$_$$_WeldClientProxy.executeQuery(Unknown
> > Source)
> > at
> >
> > org.apache.deltaspike.data.impl.handler.QueryHandler.
> process(QueryHandler.java:147)
> > ... 85 more
> >
> > I'm on a multi module gradle project. As I said before on the
> > \WEB-INF\beans.xml I have:
> >
> > 
> > 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_1.xsd;
> > version="1.2" bean-discovery-mode="annotated">
> >
> > 
> > org.apache.deltaspike.jpa.impl.transaction.
> > *ContainerManagedTransactionStrategy*
> > 
> >
> > 
> >
> > So...DS is not picking up this. So maybe I might need to place it at
> > META-INF/apache-deltaspike.properties, as John point out. Or I need to
> > place this alternative on the jar(s) of my sevice layer where the TX is
> > started.
> > I'm going to try some scenarios this afternoon.
> >
> >
> >
> > On Wed, Feb 7, 2018 at 5:35 PM, Luís Alves 
> wrote:
> >
> > > Thanks John. I going to test it tomorrow I hope...
> > >
> > > Currently I have it like:
> > >
> > > 
> > > 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_1.xsd;
> > > version="1.2" bean-discovery-mode="annotated">
> > >
> > > 
> > > org.apache.deltaspike.jpa.impl.transaction.
> > > ContainerManagedTransactionStrategy
> > > 
> > >
> > > 
> > >
> > > which as you pointed out might not work.
> > > I also do my TX demarcation at the service level (business logic). A
> > > Service can use multiple repos, jms, ...
> > > Repo should only concern about persisting and querying data.
> > >
> > > Regards,
> > > LA
> > >
> > > On Tue, Feb 6, 2018 at 9:44 PM, John D. Ament 
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Yes, Mark's input is definitely useful.  I can say I've been using DS
> +
> > >> Repositories + JTA Transactional for a few years now, it all continues
> > to
> > >> work fine.  I'm on Wildfly 10.1 as well.
> > >>
> > >> The only thing you need to remember is to
> > >> add globalAlternatives.org.apache.deltaspike.jpa.spi.transaction
> > >> .TransactionStrategy=org.apache.deltaspike.jpa.impl.transact
> > >> ion.ContainerManagedTransactionStrategy
> > >> to your META-INF/apache-deltaspike.properties file.  This is covered
> at
> > >> http://deltaspike.apache.org/documentation/jpa.html#JTASupport for
> > >> Weld/Wildfly instances
> > >>
> > >> Then you'll get the seamless transactions between DS repositories,
> other
> > >> JPA use cases, and JMS, etc.  Presently I deal with the JMS + SMTP  +
> > JPA
> > >> use case today and haven't seen it falter too much.
> > >>
> > >> I don't add @Transactional to my repositories, the transaction
> boundary
> > >> tends to be at a higher level (Services).
> > >>
> > >> John
> > >>
> > >> On Tue, Feb 6, 2018 at 3:41 PM Luís Alves 
> > wrote:
> > >>
> > >> > I want to use DS repositories, that's why I've asked about
> > >> Transactional.
> > >> > As I use Wildfly 10, I can use the standard Transactional instead of
> > >> the DS
> > >> > one.
> > >> > @Mark: thanks for your point of view. I wan't to stay as standard as
> > >> > possible, but if I have strange behaviors I'll switch for DS
> > annotation.
> > >> >

Re: deltaspike with javax.transaction.Transactional

2018-02-08 Thread John D. Ament

Luis,

This issue is solved by using the global alternative in
META-INF/apache-deltaspike.properties.

John

On Thu, Feb 8, 2018 at 7:11 AM Luís Alves  wrote:

> So... from the stack:
>
> Caused by: java.lang.IllegalStateException: A JTA EntityManager cannot use
> getTransaction()
> at
>
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.getTransaction(AbstractEntityManagerImpl.java:1333)
> at
>
> org.jboss.as.jpa.container.AbstractEntityManager.getTransaction(AbstractEntityManager.java:518)
> at org.apache.deltaspike.jpa.impl.transaction.
> *ResourceLocalTransactionStrategy*
> .getTransaction(ResourceLocalTransactionStrategy.java:370)
> at
>
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.rollbackAllTransactions(ResourceLocalTransactionStrategy.java:336)
> at
>
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:154)
> at
>
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeTransactional(TransactionalQueryRunner.java:72)
> at
>
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:54)
> at
>
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$Proxy$_$$_WeldClientProxy.executeQuery(Unknown
> Source)
> at
>
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:147)
> ... 85 more
>
> I'm on a multi module gradle project. As I said before on the
> \WEB-INF\beans.xml I have:
>
> 
> 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_1.xsd;
> version="1.2" bean-discovery-mode="annotated">
>
> 
> org.apache.deltaspike.jpa.impl.transaction.
> *ContainerManagedTransactionStrategy*
> 
>
> 
>
> So...DS is not picking up this. So maybe I might need to place it at
> META-INF/apache-deltaspike.properties, as John point out. Or I need to
> place this alternative on the jar(s) of my sevice layer where the TX is
> started.
> I'm going to try some scenarios this afternoon.
>
>
>
> On Wed, Feb 7, 2018 at 5:35 PM, Luís Alves  wrote:
>
> > Thanks John. I going to test it tomorrow I hope...
> >
> > Currently I have it like:
> >
> > 
> > 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_1.xsd;
> > version="1.2" bean-discovery-mode="annotated">
> >
> > 
> > org.apache.deltaspike.jpa.impl.transaction.
> > ContainerManagedTransactionStrategy
> > 
> >
> > 
> >
> > which as you pointed out might not work.
> > I also do my TX demarcation at the service level (business logic). A
> > Service can use multiple repos, jms, ...
> > Repo should only concern about persisting and querying data.
> >
> > Regards,
> > LA
> >
> > On Tue, Feb 6, 2018 at 9:44 PM, John D. Ament 
> > wrote:
> >
> >> Hi,
> >>
> >> Yes, Mark's input is definitely useful.  I can say I've been using DS +
> >> Repositories + JTA Transactional for a few years now, it all continues
> to
> >> work fine.  I'm on Wildfly 10.1 as well.
> >>
> >> The only thing you need to remember is to
> >> add globalAlternatives.org.apache.deltaspike.jpa.spi.transaction
> >> .TransactionStrategy=org.apache.deltaspike.jpa.impl.transact
> >> ion.ContainerManagedTransactionStrategy
> >> to your META-INF/apache-deltaspike.properties file.  This is covered at
> >> http://deltaspike.apache.org/documentation/jpa.html#JTASupport for
> >> Weld/Wildfly instances
> >>
> >> Then you'll get the seamless transactions between DS repositories, other
> >> JPA use cases, and JMS, etc.  Presently I deal with the JMS + SMTP  +
> JPA
> >> use case today and haven't seen it falter too much.
> >>
> >> I don't add @Transactional to my repositories, the transaction boundary
> >> tends to be at a higher level (Services).
> >>
> >> John
> >>
> >> On Tue, Feb 6, 2018 at 3:41 PM Luís Alves 
> wrote:
> >>
> >> > I want to use DS repositories, that's why I've asked about
> >> Transactional.
> >> > As I use Wildfly 10, I can use the standard Transactional instead of
> >> the DS
> >> > one.
> >> > @Mark: thanks for your point of view. I wan't to stay as standard as
> >> > possible, but if I have strange behaviors I'll switch for DS
> annotation.
> >> > Tomorrow I have to deal with some JMS configs, but I'll try to do some
> >> > testing until the end of this week. I was out for a month and my
> >> colleagues
> >> > are injecting the EntityManager into the @Repositories, because they
> had
> >> > some issues with the TX. I suspect that, this is not a good idea, as
> DS
> >> > repositories should own their own EntityManager instance.
> >> >
> >> > Regards
>

Re: deltaspike with javax.transaction.Transactional

2018-02-08 Thread Luís Alves

So... from the stack:

Caused by: java.lang.IllegalStateException: A JTA EntityManager cannot use
getTransaction()
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.getTransaction(AbstractEntityManagerImpl.java:1333)
at
org.jboss.as.jpa.container.AbstractEntityManager.getTransaction(AbstractEntityManager.java:518)
at org.apache.deltaspike.jpa.impl.transaction.
*ResourceLocalTransactionStrategy*
.getTransaction(ResourceLocalTransactionStrategy.java:370)
at
org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.rollbackAllTransactions(ResourceLocalTransactionStrategy.java:336)
at
org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:154)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeTransactional(TransactionalQueryRunner.java:72)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:54)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$Proxy$_$$_WeldClientProxy.executeQuery(Unknown
Source)
at
org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:147)
... 85 more

I'm on a multi module gradle project. As I said before on the
\WEB-INF\beans.xml I have:

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_1.xsd;
version="1.2" bean-discovery-mode="annotated">

org.apache.deltaspike.jpa.impl.transaction.
*ContainerManagedTransactionStrategy*

So...DS is not picking up this. So maybe I might need to place it at
META-INF/apache-deltaspike.properties, as John point out. Or I need to
place this alternative on the jar(s) of my sevice layer where the TX is
started.
I'm going to try some scenarios this afternoon.

On Wed, Feb 7, 2018 at 5:35 PM, Luís Alves  wrote:

> Thanks John. I going to test it tomorrow I hope...
>
> Currently I have it like:
>
> 
> 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_1.xsd;
> version="1.2" bean-discovery-mode="annotated">
>
> 
> org.apache.deltaspike.jpa.impl.transaction.
> ContainerManagedTransactionStrategy
> 
>
> 
>
> which as you pointed out might not work.
> I also do my TX demarcation at the service level (business logic). A
> Service can use multiple repos, jms, ...
> Repo should only concern about persisting and querying data.
>
> Regards,
> LA
>
> On Tue, Feb 6, 2018 at 9:44 PM, John D. Ament 
> wrote:
>
>> Hi,
>>
>> Yes, Mark's input is definitely useful.  I can say I've been using DS +
>> Repositories + JTA Transactional for a few years now, it all continues to
>> work fine.  I'm on Wildfly 10.1 as well.
>>
>> The only thing you need to remember is to
>> add globalAlternatives.org.apache.deltaspike.jpa.spi.transaction
>> .TransactionStrategy=org.apache.deltaspike.jpa.impl.transact
>> ion.ContainerManagedTransactionStrategy
>> to your META-INF/apache-deltaspike.properties file.  This is covered at
>> http://deltaspike.apache.org/documentation/jpa.html#JTASupport for
>> Weld/Wildfly instances
>>
>> Then you'll get the seamless transactions between DS repositories, other
>> JPA use cases, and JMS, etc.  Presently I deal with the JMS + SMTP  + JPA
>> use case today and haven't seen it falter too much.
>>
>> I don't add @Transactional to my repositories, the transaction boundary
>> tends to be at a higher level (Services).
>>
>> John
>>
>> On Tue, Feb 6, 2018 at 3:41 PM Luís Alves  wrote:
>>
>> > I want to use DS repositories, that's why I've asked about
>> Transactional.
>> > As I use Wildfly 10, I can use the standard Transactional instead of
>> the DS
>> > one.
>> > @Mark: thanks for your point of view. I wan't to stay as standard as
>> > possible, but if I have strange behaviors I'll switch for DS annotation.
>> > Tomorrow I have to deal with some JMS configs, but I'll try to do some
>> > testing until the end of this week. I was out for a month and my
>> colleagues
>> > are injecting the EntityManager into the @Repositories, because they had
>> > some issues with the TX. I suspect that, this is not a good idea, as DS
>> > repositories should own their own EntityManager instance.
>> >
>> > Regards
>> >
>> > On Tue, Feb 6, 2018 at 8:20 PM, Mark Struberg > >
>> > wrote:
>> >
>> > > Hi!
>> > >
>> > > Please note that @javax.transaction.Transactional and deltaspike
>> > > @Transactional work pretty different under the hood.
>> > >
>> > > With javax.transaction.Transactional you will get the weird
>> transaction
>> > > handling of EJB [1].
>> > > It's also not that portable as it seems. There are huge definition

Re: null QueryInvocationContext (querydsl)

null QueryInvocationContext (querydsl)

Re: deltaspike with javax.transaction.Transactional

Re: deltaspike with javax.transaction.Transactional

Re: deltaspike with javax.transaction.Transactional

5 matches

Site Navigation

Mail list logo

Footer information