Re: @Observes @Initialized(ApplicationScoped.class) No active contexts for RequestScoped

[John D. Ament]

You should not have a disposer method in your case, since you're using a
container managed entity manager (using @PersistenceContext for injection)

On Wed, Apr 11, 2018 at 4:24 AM Luís Alves  wrote:

> The error that I mention earlier was this one:
>
> ERROR [org.jboss.weld.Bean] (DefaultQuartzScheduler_Worker-1) WELD-19:
> Error destroying an
> instance
> *org.jboss.as.jpa.container.TransactionScopedEntityManager*@4f7d201d
> of Producer Method [EntityManager]
> with qualifiers [@Default @Any] declared as [[BackedAnnotatedMethod]
> @Produces @Default
> @RequestScoped public my.package.config.EntityManagerProducerImpl.get()]
>
>
> It's caused by the dispose method
>
> @ApplicationScoped
> public class EntityManagerProducerImpl implements EntityManagerProducer
> {
>
> @PersistenceContext(unitName = "my-unit")
> private EntityManager entityManager;
>
> @Override
> @Produces
> @Default
> @RequestScoped
> public EntityManager get()
> {
> return entityManager;
> }
>
>
>
>
>
>
>
> *public void closeEntityManager(@Disposes @Default EntityManager em)
> {if (em.isOpen()){em.close();}}*
>
> }
>
> When I remove it, it works fine. I think since I use
>
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> the EM is closed by the container, but not 100% sure.
> Should I have a dispose or not?
>
> Regards,
> LA
>
> On Mon, Apr 9, 2018 at 3:50 PM, Luís Alves  wrote:
>
> > Thanks John.
> > DS allows to programmatically activate the scope (Container Control
> > Module).
> > Not sure if it works the same way of @ActivateRequestContext.
> > Nevertheless it's seems a workaround. I must agree with Struberg, it
> > should be activated, unless there's some good reason it can't be
> activated
> > in the observer.
> >
> > LA
> >
> > On Mon, Apr 9, 2018 at 3:39 PM, John D. Ament 
> > wrote:
> >
> >> If you're on CDI 2.0 you can add it yourself if you want (via
> annotation -
> >> @ActivateRequestContext).  However, sounds like you're on WF 10.1, so
> >> you'd
> >> have to programmatically register it.
> >>
> >> On Mon, Apr 9, 2018 at 8:41 AM Luís Alves 
> wrote:
> >>
> >> > It partially worked on @PostConstruct :), my colleague is having some
> >> issue
> >> > with the TX. I'm working from home today, so I can only have a clear
> >> look
> >> > tomorrow.
> >> > @Transactional is allowed on @PostConstruct, right? Does the method
> has
> >> to
> >> > be public for @Transactional be intercepted?
> >> >
> >> > I dunno what the spec says...but would be nice to have the
> >> @RequestContext
> >> > at the @Observes @Initialized(ApplicationScoped.class).
> >> >
> >> > LA
> >> >
> >> > On Mon, Apr 9, 2018 at 1:24 PM, Martin Kouba 
> wrote:
> >> >
> >> > > Dne 9.4.2018 v 14:20 Mark Struberg napsal(a):
> >> > >
> >> > >> According to the CDI spec every call to a business method must have
> >> the
> >> > >> Request Context activated.
> >> > >>
> >> > >
> >> > > Mark, this is very wrong! Which part of the spec dou you refer?
> >> > >
> >> > >
> >> > >
> >> > > And this very observer IS a business method.
> >> > >>
> >> > >> LieGrue,
> >> > >> strub
> >> > >>
> >> > >>
> >> > >> Am 09.04.2018 um 10:58 schrieb Martin Kouba :
> >> > >>>
> >> > >>> Dne 9.4.2018 v 10:36 Luís Alves napsal(a):
> >> > >>>
> >> > >>>> I still didn't tested it...but I was hoping that @Observes
> >> > >>>> @Initialized(ApplicationScoped.class) was executed after
> >> > >>>> @PostConstruct
> >> > >>>>
> >> > >>>
> >> > >>> It is, but the request context is destroyed after the
> @PostConstruct
> >> > >>> callback completes (if it did not already exist before the
> >> > @PostConstruct
> >> > >>> callback was invoked).
> >> > >>>
> >> >

Re: @Observes @Initialized(ApplicationScoped.class) No active contexts for RequestScoped

[John D. Ament]

If you're on CDI 2.0 you can add it yourself if you want (via annotation -
@ActivateRequestContext).  However, sounds like you're on WF 10.1, so you'd
have to programmatically register it.

On Mon, Apr 9, 2018 at 8:41 AM Luís Alves  wrote:

> It partially worked on @PostConstruct :), my colleague is having some issue
> with the TX. I'm working from home today, so I can only have a clear look
> tomorrow.
> @Transactional is allowed on @PostConstruct, right? Does the method has to
> be public for @Transactional be intercepted?
>
> I dunno what the spec says...but would be nice to have the @RequestContext
> at the @Observes @Initialized(ApplicationScoped.class).
>
> LA
>
> On Mon, Apr 9, 2018 at 1:24 PM, Martin Kouba  wrote:
>
> > Dne 9.4.2018 v 14:20 Mark Struberg napsal(a):
> >
> >> According to the CDI spec every call to a business method must have the
> >> Request Context activated.
> >>
> >
> > Mark, this is very wrong! Which part of the spec dou you refer?
> >
> >
> >
> > And this very observer IS a business method.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> Am 09.04.2018 um 10:58 schrieb Martin Kouba :
> >>>
> >>> Dne 9.4.2018 v 10:36 Luís Alves napsal(a):
> >>>
>  I still didn't tested it...but I was hoping that @Observes
>  @Initialized(ApplicationScoped.class) was executed after
>  @PostConstruct
> 
> >>>
> >>> It is, but the request context is destroyed after the @PostConstruct
> >>> callback completes (if it did not already exist before the
> @PostConstruct
> >>> callback was invoked).
> >>>
> >>> 1st: @PostConstruct
>  2nd: public void init(@Observes @Initialized(ApplicationScoped.class)
>  Object init)
>  isn't this the case? Why on @PostConstruct we have scope and not at
>  @Observes @Initialized(ApplicationScoped.class)? - @Inject(ed) beans
>  are available here
>  LA
>  On Mon, Apr 9, 2018 at 8:44 AM, Martin Kouba    mko...@redhat.com>> wrote:
>  Dne 9.4.2018 v 09:33 Luís Alves napsal(a):
>  Thanks for you answers.
>  Before I left we tried with @TransactionScoped and got the
> same
>  exception.
>  With the ContextControl ctxCtrl =
>  BeanProvider.getContextualReference(ContextControl.class); it
>  worked, but it seems a huge workaround.
>  @MKouba: thanks for your proposed solution. I'll will try as
>  soon as my colleague arrive, since the code his on his
> machine.
>  Btw, we use wildfly-10.1.0.Final, if this is a bug can you
> open
>  a bug?
>  It does not seem to be a bug.
>  Regards,
>  LA
>  On Mon, Apr 9, 2018 at 7:56 AM, Martin Kouba <
> mko...@redhat.com
>     >> wrote:
>   Dne 6.4.2018 v 18:37 Luís Alves napsal(a):
>   Hello,
>   I'm getting:
>   Caused by: java.lang.RuntimeException:
>   org.jboss.weld.context.ContextNotActiveException:
>  WELD-001303:
>   No active
>   contexts for scope type
>  javax.enterprise.context.RequestScoped
>   On bootstrap:
>   @ApplicationScoped
>   public class BootConfig
>   {
> @Inject
> private Logger logger;
> @Inject
> private ConfigRepo configRepo ;
> public void init(@Observes
>   @Initialized(ApplicationScoped.class) Object
>   init){
>   *//There's no Request Scope here*
>   Hm, there is no guarantee that a request context is
> active
>  at this
>   point, i.e. during notification of this observer method.
>   However, you could put the logic in a @PostConstruct
>  callback of
>   BootConfig (request context must be active during
>  @PostConstruct
>   callback of any bean).
>   See also
>  http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_
>  context
>    context>
>    c/1.2/cdi-spec.html#request_context   c/1.2/cdi-spec.html#request_context>>
>   Config c =
> configRepo.findByKey("my.key");
>   //
> }
>   }
>   @Repository
>   public abstract class ConfigRepo extends
>   AbstractEntity

Re: deltaspike @Repository scope

[John D. Ament]

I typically use AppScoped or Dependent.  IDEs don't like when you add
AppScoped to repositories (since they're not valid beans) so they usually
end up as Dependent.  There's no runtime performance issues, just need to
make sure the underlying EM is consistent through out (I'm using a request
scoped EM on top of REST APIs in almost all cases, it works well).  Granted
my app looks like Rest Controller -> Service(s) -> Repositories where the
server layer is always app scoped.

John

On Tue, Feb 13, 2018 at 6:31 AM Luís Alves  wrote:

> There you use the @RequestScopedand you present @TransactionScoped,
> which seems exactly what I want but not sure what happens when TX is marked
> as NEVER or SUPPORTS (and none is oppened).
>
> On Tue, Feb 13, 2018 at 11:15 AM, Gerhard Petracek 
> wrote:
>
> > hi luis,
> >
> > please have a look at [1].
> >
> > regards,
> > gerhard
> >
> > [1] http://deltaspike.apache.org/documentation/jpa.html#Basicusage
> >
> >
> >
> > 2018-02-13 12:11 GMT+01:00 Luís Alves :
> >
> > > Well...I have REST services...so I think RequestScoped EM would be ok.
> > >
> > > On Tue, Feb 13, 2018 at 10:55 AM, Thomas Andraschko <
> > > andraschko.tho...@gmail.com> wrote:
> > >
> > > > If an AppScoped EntityManager is the right thing for you, yes.
> > > > In my webapplication i mostly use RequestScoped EMs.
> > > >
> > > > 2018-02-13 11:39 GMT+01:00 Luís Alves :
> > > >
> > > > > "An instance of a dependent bean is never shared between *different
> > > > clients
> > > > > *or different injection points."
> > > > > "Beans with scope @Dependent don’t need a proxy object. The client
> > > holds
> > > > a
> > > > > direct reference to its instance."
> > > > >
> > > > > so...I think I should be OK.
> > > > >
> > > > > On Tue, Feb 13, 2018 at 10:29 AM, Luís Alves <
> luisalve...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > So my Service layer is @ApplicationScoped.
> > > > > > Since Inject the @Repository into my service layer and is
> > @Dependent
> > > it
> > > > > > will be an @ApplicationScoped. I'm producing my EM like:
> > > > > >
> > > > > > @ApplicationScoped
> > > > > > public class EntityManagerProducerImpl implements
> > > EntityManagerProducer
> > > > > > {
> > > > > >
> > > > > > @PersistenceContext(unitName = "unit")
> > > > > > private EntityManager entityManager;
> > > > > >
> > > > > >
> > > > > > @Override
> > > > > > @Produces
> > > > > > @Default
> > > > > > public EntityManager get()
> > > > > > {
> > > > > > return entityManager;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > So...will it work properly? or do I have to mark my EM as
> > > > @RequestScoped?
> > > > > >
> > > > > > LA
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 13, 2018 at 10:24 AM, Thomas Andraschko <
> > > > > > andraschko.tho...@gmail.com> wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> the default scope is @Dependent but i suggest everyone to use
> > > > > >> @ApplicationScoped.
> > > > > >> The EM will be proxied if you use a NormalScope like
> > @RequestScoped,
> > > > > 
> > > > > >>
> > > > > >> Regards,
> > > > > >> Thomas
> > > > > >>
> > > > > >> 2018-02-13 10:54 GMT+01:00 Luís Alves :
> > > > > >>
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > What is the scope of @Repository? Do you use a similar
> approach
> > of
> > > > > >> Spring?
> > > > > >> > @Singleton and proxy the EM?
> > > > > >> >
> > > > > >> > Regards,
> > > > > >> > LA
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: null QueryInvocationContext (querydsl)

[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
> >
>

Re: deltaspike with javax.transaction.Transactional

[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
> >> Transaction

Re: deltaspike with javax.transaction.Transactional

[John D. Ament]

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.transaction.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 gaps
> in
> > the tx spec as well. E.g. whether you can catch Exceptions, transaction
> > boundaries etc.
> >
> > Needless to say I'm not a fan of javax.transaction.Transactional ;)
> >
> > LieGrue,
> > strub
> >
> >
> > [1] https://struberg.wordpress.com/2015/04/21/transaction-
> > and-exception-handling-in-ejbs-and-javaee7-transactional/
> >
> >
> > > Am 06.02.2018 um 20:38 schrieb Mauro Chi :
> > >
> > > If you use wildfly10 it came with jeee7 that already   came with
> > > annotation@Transactional.
> > >
> > > So if you use wildfy 10 you dont have to use  deltaspike.
> > > Mauro
> > >
> > > Il 6 feb 2018 19:31, "Luís Alves"  ha scritto:
> > >
> > >> Left the office already...It's wildfly 10 dot something. I'll give the
> > >> exact version and strategy used tomorrow.
> > >>
> > >> Regards
> > >>
> > >> Em 06/02/2018 18:11, "John D. Ament" 
> escreveu:
> > >>
> > >>> Yes, in general javax.transaction.Transactional works well.
> Depending
> > >> on
> > >>> your server, you may need to just point to the container managed
> > >>> transaction approach.  What container are you deploying to (including
> > >>> version)?
> > >>>
> > >>> On Tue, Feb 6, 2018 at 12:37 PM Luís Alves 
> > >> wrote:
> > >>>
> > >>>> Will deltaspike work with javax.transaction.Transactional?
> > >>>> Do I need to specify an interceptor?
> > >>>> Where can I find an example?
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: deltaspike with javax.transaction.Transactional

[John D. Ament]

Yes, in general javax.transaction.Transactional works well.  Depending on
your server, you may need to just point to the container managed
transaction approach.  What container are you deploying to (including
version)?

On Tue, Feb 6, 2018 at 12:37 PM Luís Alves  wrote:

> Will deltaspike work with javax.transaction.Transactional?
> Do I need to specify an interceptor?
> Where can I find an example?
>

Re: Exlude an abstract repository from being proxied

[John D. Ament]

Thomas,

@Vetoed won't work since we are generating a bean for the class at runtime
(the discovered AnnotatedType isn't a valid bean).

Ivo,

There is a solution you can use right now.  Repositories support
deactivation, which is effectively Vetoed but before Vetoed exists.  We
also provide an OOTB class deactivator you can use that is based purely on
configuration.

To do this, follow the instructions at
http://deltaspike.apache.org/documentation/data.html#DeactivatingRepositories
Then use the default class deactivator to deactivate just your utility
class
http://deltaspike.apache.org/documentation/core.html#DeactivateDeactivatable-ClassesviaConfig

Give that a shot, let us know how it goes.

John

On Fri, Jan 5, 2018 at 9:40 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> @ivo
> i wonder if it works when adding @Vetoed?
>
> 2018-01-05 14:09 GMT+01:00 Gerhard Petracek :
>
> > @john:
> > i mentioned ExcludeExtension [1] and not @Exclude
> >
> > regards,
> > gerhard
> >
> > [1]
> > https://github.com/apache/deltaspike/blob/master/
> > deltaspike/core/impl/src/main/java/org/apache/deltaspike/
> > core/impl/exclude/extension/ExcludeExtension.java
> >
> >
> >
> > 2018-01-05 14:06 GMT+01:00 John D. Ament :
> >
> > > Gerhard,
> > >
> > > I see Exclude is in the API [1], not the Impl.  I don't see this
> > > duplicating, but sure I suspect we can add both trivially.
> > >
> > > John
> > >
> > > [1]:
> > > https://github.com/apache/deltaspike/blob/master/
> > > deltaspike/core/api/src/main/java/org/apache/deltaspike/
> > > core/api/exclude/Exclude.java
> > >
> > >
> > > On Fri, Jan 5, 2018 at 8:02 AM Gerhard Petracek 
> > > wrote:
> > >
> > > > @john:
> > > > it's the opposite, because you can support @Vetoed via reflection,
> but
> > > for
> > > > @Exclude we need at least a vote.
> > > > (reason: you would need to (re-)use internals of ExcludeExtension in
> > > > RepositoryExtension which introduces a compile dependendy to
> > > > deltaspike-core-impl)
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2018-01-05 13:47 GMT+01:00 John D. Ament :
> > > >
> > > > > Adding a check for Exclude would make sense and be easy.  Adding
> > > Vetoed,
> > > > > since we're still CDI 1.0, would be hard.  I just put in
> > > > > https://issues.apache.org/jira/browse/DELTASPIKE-1311 and can plan
> > to
> > > > take
> > > > > care of that for you in 1.8.2.
> > > > >
> > > > > Thanks for the info, and thanks for the clarifications!
> > > > >
> > > > > John
> > > > >
> > > > > On Fri, Jan 5, 2018 at 7:39 AM Thomas Andraschko <
> > > > > andraschko.tho...@gmail.com> wrote:
> > > > >
> > > > > > Yep, i see. AbstractEntityRepository has a @Repository of course.
> > > > > > We could of course add a check for @Vetoed/Exclude but not sure
> if
> > it
> > > > has
> > > > > > any side effects.
> > > > > >
> > > > > > 2018-01-05 13:31 GMT+01:00 Ivo Limmen :
> > > > > >
> > > > > > > I did. Since my AbstractMultitenancyRepository extends
> > > > > > > AbstractEntityRepository it is included as a "real" repository;
> > > even
> > > > > > though
> > > > > > > it has no @Repository.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Ivo Limmen
> > > > > > >
> > > > > > > On Fri, Jan 5, 2018 at 1:24 PM, Thomas Andraschko <
> > > > > > > andraschko.tho...@gmail.com> wrote:
> > > > > > >
> > > > > > > > It actually shoudln't if there is no @Repository present.
> Could
> > > you
> > > > > > debug
> > > > > > > > RepositoryExtension#isRepository?
> > > > > > > >
> > > > > > > >
> > > > > > > > 2018-01-05 13:20 GMT+01:00 Ivo Limmen :
> > > > > > > >
> > > > > > > > > Yes it is.
> > > > > > > > >
> > > > > >

Re: Exlude an abstract repository from being proxied

[John D. Ament]

Gerhard,

I see Exclude is in the API [1], not the Impl.  I don't see this
duplicating, but sure I suspect we can add both trivially.

John

[1]:
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/exclude/Exclude.java


On Fri, Jan 5, 2018 at 8:02 AM Gerhard Petracek 
wrote:

> @john:
> it's the opposite, because you can support @Vetoed via reflection, but for
> @Exclude we need at least a vote.
> (reason: you would need to (re-)use internals of ExcludeExtension in
> RepositoryExtension which introduces a compile dependendy to
> deltaspike-core-impl)
>
> regards,
> gerhard
>
>
>
> 2018-01-05 13:47 GMT+01:00 John D. Ament :
>
> > Adding a check for Exclude would make sense and be easy.  Adding Vetoed,
> > since we're still CDI 1.0, would be hard.  I just put in
> > https://issues.apache.org/jira/browse/DELTASPIKE-1311 and can plan to
> take
> > care of that for you in 1.8.2.
> >
> > Thanks for the info, and thanks for the clarifications!
> >
> > John
> >
> > On Fri, Jan 5, 2018 at 7:39 AM Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> > > Yep, i see. AbstractEntityRepository has a @Repository of course.
> > > We could of course add a check for @Vetoed/Exclude but not sure if it
> has
> > > any side effects.
> > >
> > > 2018-01-05 13:31 GMT+01:00 Ivo Limmen :
> > >
> > > > I did. Since my AbstractMultitenancyRepository extends
> > > > AbstractEntityRepository it is included as a "real" repository; even
> > > though
> > > > it has no @Repository.
> > > >
> > > > Best regards,
> > > > Ivo Limmen
> > > >
> > > > On Fri, Jan 5, 2018 at 1:24 PM, Thomas Andraschko <
> > > > andraschko.tho...@gmail.com> wrote:
> > > >
> > > > > It actually shoudln't if there is no @Repository present. Could you
> > > debug
> > > > > RepositoryExtension#isRepository?
> > > > >
> > > > >
> > > > > 2018-01-05 13:20 GMT+01:00 Ivo Limmen :
> > > > >
> > > > > > Yes it is.
> > > > > >
> > > > > > Best regards,
> > > > > > Ivo Limmen
> > > > > >
> > > > > > On Fri, Jan 5, 2018 at 1:19 PM, John D. Ament <
> > > john.d.am...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Ivo,
> > > > > > >
> > > > > > > You should not add @Repository to this class.  Is it still
> > > discovered
> > > > > > then?
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Fri, Jan 5, 2018 at 7:12 AM Ivo Limmen 
> > wrote:
> > > > > > >
> > > > > > > > Hi John,
> > > > > > > >
> > > > > > > > I am trying to AVOID discovery of the repository as it is a
> > > > abstract
> > > > > > base
> > > > > > > > repository with common utility methods. I tried by adding
> > > > @Repository
> > > > > > but
> > > > > > > > it does not work.
> > > > > > > > I tried adding @Exclude on the repository but the
> > > > RepositoryExtension
> > > > > > > does
> > > > > > > > not filter on @Exclude annotated repositories.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Ivo Limmen
> > > > > > > >
> > > > > > > > On Fri, Jan 5, 2018 at 1:09 PM, John D. Ament <
> > > > > john.d.am...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Ivo,
> > > > > > > > >
> > > > > > > > > For any repository to be discovered, it should be annotated
> > > > > > > @Repository.
> > > > > > > > > If this is your own custom class, I would simply remove
> that
> > > > > > > annotation.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > On Fri, Jan 5, 2018 at 6:42 AM Ivo Limmen 
> > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi list,
> > > > > > > > > >
> > > > > > > > > > I am using DeltaSpike for my project and I like it very
> > much.
> > > > > But I
> > > > > > > am
> > > > > > > > > > trying to exclude an abstract repository (my own abstract
> > > base
> > > > > > > > > repository)
> > > > > > > > > > from being picked up by the RepositoryExtention.
> > > > > > > > > > I tried @Exclude but that does not work. Then I
> discovered
> > > that
> > > > > > 1.8.1
> > > > > > > > was
> > > > > > > > > > release (I used 1.8.0) but that did not help either.
> > > > > > > > > > I saw that the method RepositoryExtension.isRepository()
> > does
> > > > > not
> > > > > > > > > exclude
> > > > > > > > > > any interfaces or abstract classes; it this feature
> > missing?
> > > > > > > > > > Or am I using it wrong?
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Ivo Limmen
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Met vriendelijke groet,
> > > > > > > > > > Ivo Limmen
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Met vriendelijke groet,
> > > > > > > > Ivo Limmen
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Met vriendelijke groet,
> > > > > > Ivo Limmen
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Met vriendelijke groet,
> > > > Ivo Limmen
> > > >
> > >
> >
>

Re: Exlude an abstract repository from being proxied

[John D. Ament]

Adding a check for Exclude would make sense and be easy.  Adding Vetoed,
since we're still CDI 1.0, would be hard.  I just put in
https://issues.apache.org/jira/browse/DELTASPIKE-1311 and can plan to take
care of that for you in 1.8.2.

Thanks for the info, and thanks for the clarifications!

John

On Fri, Jan 5, 2018 at 7:39 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Yep, i see. AbstractEntityRepository has a @Repository of course.
> We could of course add a check for @Vetoed/Exclude but not sure if it has
> any side effects.
>
> 2018-01-05 13:31 GMT+01:00 Ivo Limmen :
>
> > I did. Since my AbstractMultitenancyRepository extends
> > AbstractEntityRepository it is included as a "real" repository; even
> though
> > it has no @Repository.
> >
> > Best regards,
> > Ivo Limmen
> >
> > On Fri, Jan 5, 2018 at 1:24 PM, Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> > > It actually shoudln't if there is no @Repository present. Could you
> debug
> > > RepositoryExtension#isRepository?
> > >
> > >
> > > 2018-01-05 13:20 GMT+01:00 Ivo Limmen :
> > >
> > > > Yes it is.
> > > >
> > > > Best regards,
> > > > Ivo Limmen
> > > >
> > > > On Fri, Jan 5, 2018 at 1:19 PM, John D. Ament <
> john.d.am...@gmail.com>
> > > > wrote:
> > > >
> > > > > Ivo,
> > > > >
> > > > > You should not add @Repository to this class.  Is it still
> discovered
> > > > then?
> > > > >
> > > > > John
> > > > >
> > > > > On Fri, Jan 5, 2018 at 7:12 AM Ivo Limmen  wrote:
> > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > I am trying to AVOID discovery of the repository as it is a
> > abstract
> > > > base
> > > > > > repository with common utility methods. I tried by adding
> > @Repository
> > > > but
> > > > > > it does not work.
> > > > > > I tried adding @Exclude on the repository but the
> > RepositoryExtension
> > > > > does
> > > > > > not filter on @Exclude annotated repositories.
> > > > > >
> > > > > > Best regards,
> > > > > > Ivo Limmen
> > > > > >
> > > > > > On Fri, Jan 5, 2018 at 1:09 PM, John D. Ament <
> > > john.d.am...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Ivo,
> > > > > > >
> > > > > > > For any repository to be discovered, it should be annotated
> > > > > @Repository.
> > > > > > > If this is your own custom class, I would simply remove that
> > > > > annotation.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Fri, Jan 5, 2018 at 6:42 AM Ivo Limmen 
> > wrote:
> > > > > > >
> > > > > > > > Hi list,
> > > > > > > >
> > > > > > > > I am using DeltaSpike for my project and I like it very much.
> > > But I
> > > > > am
> > > > > > > > trying to exclude an abstract repository (my own abstract
> base
> > > > > > > repository)
> > > > > > > > from being picked up by the RepositoryExtention.
> > > > > > > > I tried @Exclude but that does not work. Then I discovered
> that
> > > > 1.8.1
> > > > > > was
> > > > > > > > release (I used 1.8.0) but that did not help either.
> > > > > > > > I saw that the method RepositoryExtension.isRepository() does
> > > not
> > > > > > > exclude
> > > > > > > > any interfaces or abstract classes; it this feature missing?
> > > > > > > > Or am I using it wrong?
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Ivo Limmen
> > > > > > > >
> > > > > > > > --
> > > > > > > > Met vriendelijke groet,
> > > > > > > > Ivo Limmen
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Met vriendelijke groet,
> > > > > > Ivo Limmen
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Met vriendelijke groet,
> > > > Ivo Limmen
> > > >
> > >
> >
> >
> >
> > --
> > Met vriendelijke groet,
> > Ivo Limmen
> >
>

Re: Exlude an abstract repository from being proxied

[John D. Ament]

Ivo,

You should not add @Repository to this class.  Is it still discovered then?

John

On Fri, Jan 5, 2018 at 7:12 AM Ivo Limmen  wrote:

> Hi John,
>
> I am trying to AVOID discovery of the repository as it is a abstract base
> repository with common utility methods. I tried by adding @Repository but
> it does not work.
> I tried adding @Exclude on the repository but the RepositoryExtension does
> not filter on @Exclude annotated repositories.
>
> Best regards,
> Ivo Limmen
>
> On Fri, Jan 5, 2018 at 1:09 PM, John D. Ament 
> wrote:
>
> > Hi Ivo,
> >
> > For any repository to be discovered, it should be annotated @Repository.
> > If this is your own custom class, I would simply remove that annotation.
> >
> > John
> >
> > On Fri, Jan 5, 2018 at 6:42 AM Ivo Limmen  wrote:
> >
> > > Hi list,
> > >
> > > I am using DeltaSpike for my project and I like it very much. But I am
> > > trying to exclude an abstract repository (my own abstract base
> > repository)
> > > from being picked up by the RepositoryExtention.
> > > I tried @Exclude but that does not work. Then I discovered that 1.8.1
> was
> > > release (I used 1.8.0) but that did not help either.
> > > I saw that the method RepositoryExtension.isRepository() does not
> > exclude
> > > any interfaces or abstract classes; it this feature missing?
> > > Or am I using it wrong?
> > >
> > > Best regards,
> > > Ivo Limmen
> > >
> > > --
> > > Met vriendelijke groet,
> > > Ivo Limmen
> > >
> >
>
>
>
> --
> Met vriendelijke groet,
> Ivo Limmen
>

Re: Exlude an abstract repository from being proxied

[John D. Ament]

Hi Ivo,

For any repository to be discovered, it should be annotated @Repository.
If this is your own custom class, I would simply remove that annotation.

John

On Fri, Jan 5, 2018 at 6:42 AM Ivo Limmen  wrote:

> Hi list,
>
> I am using DeltaSpike for my project and I like it very much. But I am
> trying to exclude an abstract repository (my own abstract base repository)
> from being picked up by the RepositoryExtention.
> I tried @Exclude but that does not work. Then I discovered that 1.8.1 was
> release (I used 1.8.0) but that did not help either.
> I saw that the method RepositoryExtension.isRepository() does not exclude
> any interfaces or abstract classes; it this feature missing?
> Or am I using it wrong?
>
> Best regards,
> Ivo Limmen
>
> --
> Met vriendelijke groet,
> Ivo Limmen
>

Re: QueryInvocationContext is null.

[John D. Ament]

The abstract classes probably only support limited injection.  I wouldn't
recommend doing this, if you need access to EntityManager there are helper
classes to implement that give you it, e.g. EntityManagerAware.

John

On Tue, Dec 19, 2017 at 10:16 AM Luís Alves  wrote:

> I have the following code:
>
> @Repository
> public abstract class ConfigurationRepository extends
> AbstractEntityRepository implements
> EntityRepository, EntityManagerDelegate<
> Configuration>
> {
>
>
> *// FIXME: why this is null?!?@Injectprivate
> QueryInvocationContext context;*
>
> @Inject
> private EntityManager em;
>
> /**
>  * Find by key.
>  *
>  * @param key
>  *the key
>  * @return the configuration
>  */
> public Configuration findByKey(String key)
> {
> QConfiguration c = QConfiguration.configuration;
>
> return new
> JPAQuery(em).from(c).where(c.key.eq(key)).
> fetchFirst();
> }
>
> }
>
> The *QueryInvocationContext*is null so I had to inject the EM directly. Any
> idea why it's null or how to figure out why it's null?
>
> Regards,
> LA
>

Re: Cannot persist entities when adding AbstractEntityRepository

[John D. Ament]

Hi,

A testable project would be very helpful here.

John

On Tue, Nov 14, 2017 at 3:13 AM Vladimir Albis Arandia <
albis.vladi...@saguapac.com.bo> wrote:

> Hello
>
>
> I have a ManyToMany relationship between three entities: Invoice, Product,
> InvoiceProduct, mapped with OneToMany bidirectional.
>
>
> Entity: Invoice
>
> Attribute: OneToMany InvoiceProduct
>
>
> Entity: Product
>
> Attribute: OneToMany InvoiceProduct
>
>
> Entity: InvoiceProduct
>
> Attribute: ManyToOne Invoice
>
> Attribute: ManyToOne Product
>
> Attribute: EmbeddedId InvoiceProductId
>
>
> Also Invoice has an attribute annotated with @Version.
>
>
> Now everything works as it should when using pure EJB JPA (Hibernate) with
> H2 database. But i get the following exception:
>
>
> org.hibernate.PropertyAccessException: Could not set field value
> [SHORT_CIRCUIT_INDICATOR] value by reflection : [class
> bo.com.saguapac.eearchitect.InvoiceProductId.invoiceId] setter of
> bo.com.saguapac.eearchitect.InvoiceProductId.invoiceId
>
>
>  When i add a Repository that extends AbstractEntityRepository for Invoice
> Entity.
>
>
> Please , any advice would be appreciated.
>
>
> Note: the environment is JBoss EAP 7, Java 8 update 101, Windows 10. Also
> if you want i can give you the maven project for testing.
>
>
> bye,
>
> Vladimir Albis Arandia
> Telf. 3522323 Int. 568
> Desarrollo de Aplicaciones
> Gerencia General
>

Re: @Before in CdiTestRunner test when use_test_class_as_cdi_bean=true

[John D. Ament]

Gerhard,

RE the original question.  If a scope is applied to the test class, does it
handle it correctly?  E.g. if its request scoped and each test method
starts a new request context, is a new instance used?  Or is it treated as
a dependent bean regardless?

John

On Mon, Nov 20, 2017 at 6:52 AM Gary Hodgson 
wrote:

> Hi Gerhard,
>
> I can understand the desire not to confuse the reader, but I think there is
> more risk of confusion by not documenting this.  For example, I came across
> the problem because we use Database Rider to setup DBUnit, and
> documentation in this downstream project explicitly advises to set the
> property to true (
> https://database-rider.github.io/getting-started/#configuration_3)
>
> We now have the decision to either revert the use of Database Rider, or to
> use it and accept, and document, the consequence that Junit setup
> functionality is not available in those tests.  Having a warning in the
> Test Control Module documentation would have allowed us to make this
> decision earlier.
>
> In any case I will suggest to the Database Rider author that he put in a
> warning in his documentation as I think it is an important point to
> mention.
>
>
> Regards,
> Gary
>
> On 20 November 2017 at 12:23, Gerhard Petracek 
> wrote:
>
> > hi gary,
> >
> > that flag shouldn't be in the documentation at all (to avoid confusion).
> > we just kept the possibility to use test-classes as cdi-beans, because it
> > was the default behavior prior v1 (before we found the issue with
> @Before)
> > and some users used it extensively.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-11-20 11:14 GMT+01:00 Gary Hodgson :
> >
> > > Hi Gerhard,
> > >
> > > Thanks for confirming that.
> > >
> > > I couldn't find mention of this in the documentation (perhaps it passed
> > me
> > > by), perhaps it would be worthwhile adding a sentence to the Test
> Control
> > > Module for others in the future?
> > >
> > > All the best,
> > > Gary
> > >
> > > On 19 November 2017 at 23:24, Gerhard Petracek <
> > gerhard.petra...@gmail.com
> > > >
> > > wrote:
> > >
> > > > hi gary,
> > > >
> > > > exactly that issue was the reason for the flag and the reason why
> it's
> > > > false per default.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JavaEE powerhouse -
> > > > JavaEE Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache
> > > > MyFaces, DeltaSpike and OpenWebBeans
> > > >
> > > >
> > > >
> > > > 2017-11-19 21:07 GMT+01:00 Gary Hodgson :
> > > >
> > > > > Hi
> > > > >
> > > > > I have a question about using @Before in CdiTestRunner enabled unit
> > > > tests.
> > > > >
> > > > > The following test fails when I set the config property
> > > > > deltaspike.testcontrol.use_test_class_as_cdi_bean=true
> > > > >
> > > > >   @RunWith(CdiTestRunner.class)
> > > > >   public class ATest {
> > > > >
> > > > >   boolean a;
> > > > >
> > > > >   @Before
> > > > >   public void setup() {
> > > > >   a = true;
> > > > >   }
> > > > >
> > > > >   @Test
> > > > >   public void testA() {
> > > > >   assertTrue(a);
> > > > >   }
> > > > >   }
> > > > >
> > > > >
> > > > > Is this expected behaviour because the test class is processed as a
> > CDI
> > > > > bean? Or is it a bug?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > >
> > >
> >
>

Re: ContextNotActiveException when accessing an @ApplicationScoped bean from a new thread

[John D. Ament]

Bruno,

It seems that your example isn't complete enough.  You
have deltaspike.testcontrol.mock-support.allow_mocked_beans=true enabled,
however you're not using it (in the example).  How are you using mocked
beans in your real test?

John

On Tue, Oct 17, 2017 at 6:56 AM Bruno Boissard 
wrote:

> John -> Yes you found the sources and reproduced my issue.
> Gerhard -> It's a pity that the mock functionality implies to have a
> request context.
> Using your code proposal make cdi-test work but in the real thing the
> threads are not created explicitely by me so it will be harder to have them
> creating the request context, and only in case of tests.
>
> It would have been nice to have the mock functionality working without
> request context but I will implement your workaround and create the request
> context in the separated thread.
>
> Thanks.
>
>
> 2017-10-17 12:26 GMT+02:00 Gerhard Petracek :
>
> > hi bruno,
> >
> > you don't have a request-scoped bean, but the mock-functionality you
> > enabled (via config) is based on the request-scoped bean you mentioned.
> > it's needed to support different mocks (across tests).
> >
> > -> if MyThread is part of your test-code, just add the parts i've
> mentioned
> > in my previous answer.
> > (otherwise use MyTestThread which extends MyThread for your tests + add
> the
> > additional behavior there...)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-10-17 11:58 GMT+02:00 John D. Ament :
> >
> > > Bruno,
> > >
> > > When I run your project (assuming you meant :
> > > https://github.com/rt15/cdi-test ) This is the exception I get, which
> > > matches to what Gerhard is describing to you:
> > >
> > > javax.enterprise.context.ContextNotActiveException: WebBeans context
> > with
> > > scope type annotation @RequestScoped does not exist within current
> thread
> > > at
> > > org.apache.webbeans.container.BeanManagerImpl.getContext(
> > > BeanManagerImpl.java:331)
> > > at
> > > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHan
> > > dler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:88)
> > > at
> > > org.apache.webbeans.intercept.RequestScopedBeanInterceptorHa
> > >
> ndler.getContextualInstance(RequestScopedBeanInterceptorHandler.java:76)
> > > at
> > > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(
> > > NormalScopedBeanInterceptorHandler.java:70)
> > > at
> > > org.apache.deltaspike.testcontrol.impl.mock.SimpleMockManager$$
> > > OwbNormalScopeProxy0.getMock(org/apache/deltaspike/
> > testcontrol/impl/mock/
> > > SimpleMockManager.java)
> > > at
> > > org.apache.deltaspike.testcontrol.impl.mock.
> > MockAwareInjectionTargetWrappe
> > > r.produce(MockAwareInjectionTargetWrapper.java:59)
> > > at
> > > org.apache.webbeans.component.AbstractOwbBean.create(
> > > AbstractOwbBean.java:122)
> > > at
> org.apache.webbeans.component.ManagedBean.create(ManagedBean.java:67)
> > > at
> > > org.apache.webbeans.context.creational.BeanInstanceBag.
> > > create(BeanInstanceBag.java:76)
> > > at
> > > org.apache.webbeans.context.AbstractContext.getInstance(
> > > AbstractContext.java:159)
> > > at org.apache.webbeans.context.AbstractContext.get(
> > > AbstractContext.java:125)
> > > at
> > > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHan
> > > dler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:100)
> > > at
> > > org.apache.webbeans.intercept.ApplicationScopedBeanInterceptorHandler.
> > > getContextualInstance(ApplicationScopedBeanInterceptorHandler.java:65)
> > > at
> > > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(
> > > NormalScopedBeanInterceptorHandler.java:70)
> > > at fr.rt15.MyBean$$OwbNormalScopeProxy0.foo(fr/rt15/MyBean.java)
> > > at fr.rt15.MyThread.run(MyThread.java:13)
> > >
> > > On Tue, Oct 17, 2017 at 5:04 AM Bruno Boissard <
> boissard.br...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Gerhard,
> > > >
> > > > It would make sense to start a request context in order to be able to
> > > > access a @RequestScoped bean but my bean is @ApplicationScoped.
> Should
> > it
> > > > not be accessible without starting a request context?
> > > >
> > > 

Re: ContextNotActiveException when accessing an @ApplicationScoped bean from a new thread

[John D. Ament]

Bruno,

When I run your project (assuming you meant :
https://github.com/rt15/cdi-test ) This is the exception I get, which
matches to what Gerhard is describing to you:

javax.enterprise.context.ContextNotActiveException: WebBeans context with
scope type annotation @RequestScoped does not exist within current thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:331)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:88)
at
org.apache.webbeans.intercept.RequestScopedBeanInterceptorHandler.getContextualInstance(RequestScopedBeanInterceptorHandler.java:76)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:70)
at
org.apache.deltaspike.testcontrol.impl.mock.SimpleMockManager$$OwbNormalScopeProxy0.getMock(org/apache/deltaspike/testcontrol/impl/mock/SimpleMockManager.java)
at
org.apache.deltaspike.testcontrol.impl.mock.MockAwareInjectionTargetWrapper.produce(MockAwareInjectionTargetWrapper.java:59)
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:122)
at org.apache.webbeans.component.ManagedBean.create(ManagedBean.java:67)
at
org.apache.webbeans.context.creational.BeanInstanceBag.create(BeanInstanceBag.java:76)
at
org.apache.webbeans.context.AbstractContext.getInstance(AbstractContext.java:159)
at org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:100)
at
org.apache.webbeans.intercept.ApplicationScopedBeanInterceptorHandler.getContextualInstance(ApplicationScopedBeanInterceptorHandler.java:65)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:70)
at fr.rt15.MyBean$$OwbNormalScopeProxy0.foo(fr/rt15/MyBean.java)
at fr.rt15.MyThread.run(MyThread.java:13)

On Tue, Oct 17, 2017 at 5:04 AM Bruno Boissard 
wrote:

> Hi Gerhard,
>
> It would make sense to start a request context in order to be able to
> access a @RequestScoped bean but my bean is @ApplicationScoped. Should it
> not be accessible without starting a request context?
>
> But while searching for my bean, in deltaspike
> MockAwareInjectionTargetWrapper, a DynamicMockManager is searched:
>
> DynamicMockManager mockManager =
> BeanProvider.getContextualReference(this.beanManager,
> DynamicMockManager.class, false);
>
> It returns a SimpleMockManager that is @RequestScoped so it cannot be used
> without a created request context.
>
> Maybe MockAwareInjectionTargetWrapper should use
> SimpleApplicationMockManager (Which is @ApplicationScoped) when we ask for
> an @ApplicationScoped bean?
>
> Regards.
>
> 2017-10-17 10:20 GMT+02:00 Gerhard Petracek :
>
> > hi bruno,
> >
> > if you start your own threads, you have to control some scopes like the
> > request-scope on your own (>within< those new threads).
> > (that isn't specific to deltaspike)
> >
> > see a similar part [1] in our documentation.
> >
> > regards,
> > gerhard
> >
> > [1]
> > http://deltaspike.apache.org/documentation/container-control.html#
> > AttachaRequestContexttoaNewThreadinEE
> >
> >
> >
> > 2017-10-17 9:55 GMT+02:00 Bruno Boissard :
> >
> > > Hello,
> > >
> > > I am using deltaspike 1.8.0 and owb version 1.6.3.
> > >
> > > My test which has to be executed with CdiTestRunner, is starting a new
> > > thread.
> > > This thread retrieves an instance of MyBean from CDI and try to use it.
> > > MyBean is @ApplicationScoped.
> > >
> > > It works fine unless I add in apache-deltaspike.properties:
> > > deltaspike.testcontrol.mock-support.allow_mocked_beans=true
> > > (It is necessary for some other tests. As well as stop_container=false
> is
> > > also necessary).
> > >
> > > With allow_mocked_beans=true I have following exception:
> > > javax.enterprise.context.ContextNotActiveException: WebBeans context
> > with
> > > scope type annotation @RequestScoped does not exist within current
> thread
> > >
> > > It appears that while searching for MyBean, it is searching for
> > > SimpleMockManager bean.
> > > SimpleMockManager is @RequestScoped, so deltaspike does not find it
> > > (Logical, there is no request context as we are in a new thread).
> > >
> > > A very ugly workaround is to use MyBean in MyTest: once it is created,
> it
> > > become accessible in the other thread...
> > > Is there a better solution?
> > >
> > > A maven project corresponding to this available in github, please
> search
> > > for rt15/cdi-test.
> > >
> > >
> > > Otherwise here is the source code:
> > > ===
> > > @RunWith(CdiTestRunner.class)
> > > public class MyTest {
> > >
> > > @Inject
> > > private MyBean myBean;
> > >
> > > @Test
> > > public void test() throws Exception {
> > >
> > > // Ugly workaround: uncomment next line.
> > >   

Re: Configuration process failure

[John D. Ament]

Sylvain,

How is your project packaged?  In the EAR, are the deltaspike libraries
present there?  Is there a copy in the WAR file?

John

On Wed, Sep 27, 2017 at 4:16 PM BONNEMAISON Sylvain <
sylvain.bonnemai...@soprasteria.com> wrote:

> Hi,
>
> A EAR application is composed with an EJB module + WAR module. Both are
> depending on Deltaspike (1.8.0) libraries. While deploy the application
> under JBoss EAP 7.0, the output shows the following exception:
>
> Caused by: java.util.ServiceConfigurationError:
> org.apache.deltaspike.core.spi.config.ConfigSourceProvider: Provider
> org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider not a
> subtype
>at java.util.ServiceLoader.fail(ServiceLoader.java:239)
>at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
>at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
>at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>at
> org.apache.deltaspike.core.util.ServiceUtils.loadServiceImplementations(ServiceUtils.java:66)
>
> The problem happen with CDI View extension ony from the WAR module. The
> initialization is correct from the EJB module.
>
> What's giong wrong with the WAR. Is it a configuration problem ?
> Thanks,
>
> Sylvain
>
>

Re: countBy... method

[John D. Ament]

Actually, you could implement it on your own as an extension, as a query
delegate http://deltaspike.apache.org/documentation/data.html#Extensions .
But this should be trivial for us to add in to core.

John

On Tue, Jul 18, 2017 at 7:41 AM Ondrej Mihályi 
wrote:

> This feature isn't implemented yet.
> It was added as a feature request very recently:
> https://issues.apache.org/jira/browse/DELTASPIKE-1280
> So hopefully it will be supported soon, it would be a nice and useful
> addition.
>
> After you sign into the Apache JIRA, you can vote for this issue to give it
> more priority.
>
> Ondro
>
> 2017-07-18 12:25 GMT+02:00 Instantiation Exception <
> instantiationexcept...@gmail.com>:
>
> > Hi
> >
> > I have following method in repository:
> >
> > List findBySentOrderById(boolean sent)
> >
> > I need analogous count method. I tried:
> >
> > long countBySentOrderById(boolean sent)
> >
> > but using this method throws
> >
> > org.apache.deltaspike.data.api.QueryInvocationException: Failed calling
> > Repository...
> >
> > How can I create count method? I know I can write JPQL by hand and place
> it
> > in @Query, but that feels awkward.
> >
> > Best regards,
> > Konrad
> >
>

Re: problem in pom.xml for distributions-bom artifact version 1.8.1-SNAPSHOT

[John D. Ament]

HI Andrew,

This was found in the release and
https://issues.apache.org/jira/browse/DELTASPIKE-1257 created to work
through the problem.

John

On Wed, Jun 21, 2017 at 8:42 AM Andrew Marinchuk 
wrote:

> Hi!
>
> After switching to deltaspike verison 1.8.1-SNAPSHOT, we've obtained a
> warning message in eclipse to the version in openwebbeans dependencies.
> Some investigations shows that pom.xml for groupId
> org.apache.deltaspike.distribution and artifactId distributions-bom
> declares version 1.2.7 for openwebbeans. Looks like typing error, should be
> 1.7.2. Previous deltaspike version (1.7.2) works with openwebbeans 1.7.2
> and deltaspike 1.8.1-SNAPSHOT seems too.
>
> Here is part of our pom.xml:
>
> 
> 
> 1.8.1-SNAPSHOT
> 1.7.2
> 
> 
> 
> 
>
> org.apache.deltaspike.distribution
> distributions-bom
> ${deltaspike.version}
> pom
> import
> 
> 
> 
> 
> 
> org.apache.geronimo.specs
> geronimo-atinject_1.0_spec
> compile
> 
> 
> org.apache.geronimo.specs
> geronimo-jcdi_1.1_spec
> 1.0
> compile
> 
> 
> org.apache.geronimo.specs
>
> geronimo-interceptor_1.2_spec
> 1.0
> compile
> 
> 
> org.apache.geronimo.specs
>
> geronimo-annotation_1.2_spec
> 1.0
> compile
> 
> 
> org.apache.openwebbeans
> openwebbeans-spi
> ${owb.version}  
> compile
> 
> 
> org.apache.openwebbeans
> openwebbeans-impl
> ${owb.version}  
> runtime
> 
> 
> org.apache.deltaspike.core
> deltaspike-core-api
> compile
> 
> 
> org.apache.deltaspike.core
> deltaspike-core-impl
> runtime
> 
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
> 
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-owb
> runtime
> 
> 
>
> org.apache.deltaspike.test
> test-utils
> 
> 
> 
> 
> com.google.code.findbugs
> jsr305
> 2.0.1
> compile
> 
> 
>
>
> Best regards,
> Andrew Marinchuk
>
>

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Konrad,

So Mark's correct, CMT is basically no-op, because it relies on an outer
transaction to have been created.  If you're marking your entry points as
@Transactional then you're good to go. If you're using DeltaSpike's
@Transactional then you'll need to use BMTStrategy.

John

On Wed, May 10, 2017 at 4:02 PM Instantiation Exception <
instantiationexcept...@gmail.com> wrote:

> javax.transaction.Transactional
>
> On Wed, May 10, 2017 at 9:56 PM, Mark Struberg 
> wrote:
>
> > Which @Transactional do you use? javax.transaction.Transactional or
> > org.apache.deltaspike.jpa.api.transaction.Transactional ?
> >
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 10.05.2017 um 19:51 schrieb Instantiation Exception <
> > instantiationexcept...@gmail.com>:
> > >
> > > John,
> > >
> > > So in this situation can I completly remove beans.xml?
> > >
> > > So why does it work? ContainerManagedTransactionStrategy has trivial
> > > implementation:
> > > https://github.com/apache/deltaspike/blob/master/
> > deltaspike/modules/jpa/impl/src/main/java/org/apache/deltaspike/jpa/impl/
> > transaction/ContainerManagedTransactionStrategy.java
> > >
> > > As Mark said
> > > "It is essentially a no-op TransactionStrategy. It delegates through
> > > without doing something."
> > > "This is useful if you GUARANTEED have a ContainerManagedTransation in
> an
> > > outer level.
> > > E.g. if you have some existing code using DeltaSpike @Transactional,
> and
> > > you know that you ALWAYS have e.g. a @Stateless @WebService calling
> your
> > > code."
> > >
> > > Best regards,
> > > Konrad
> > >
> > >
> > > On Wed, May 10, 2017 at 7:39 PM, John D. Ament 
> > > wrote:
> > >
> > >> Konrad,
> > >>
> > >> By using a global alternative, you're effectively making what is in
> > >> beans.xml ignored.
> > >>
> > >> John
> > >>
> > >> On Wed, May 10, 2017 at 1:32 PM Instantiation Exception <
> > >> instantiationexcept...@gmail.com> wrote:
> > >>
> > >>> John,
> > >>>
> > >>> There is one think which I don't understand:
> > >>> apache-deltaspike.properties contains different TransactionStrategy
> > >>> than beans.xml
> > >>>
> > >>> * apache-deltaspike.properties contains
> > >>>
> > >>> org.apache.deltaspike.jpa.impl.transaction.
> > >> ContainerManagedTransactionStrategy
> > >>> * beans.xml contains
> > >>>
> > >>> org.apache.deltaspike.jpa.impl.transaction.
> > >> BeanManagedUserTransactionStrategy
> > >>>
> > >>> Isn't it a conflict?
> > >>>
> > >>> Best regards,
> > >>> Konrad
> > >>>
> > >>> On Wed, May 10, 2017 at 7:22 PM, John D. Ament <
> johndam...@apache.org>
> > >>> wrote:
> > >>>
> > >>>> Konrad,
> > >>>>
> > >>>> Yes, what you're doing should work and actually matches what I do
> > >>> presently
> > >>>> in a production environment.  If you're using the JTA @Transactional
> > >> what
> > >>>> you're doing is what will work for you.
> > >>>>
> > >>>> John
> > >>>>
> > >>>> On Wed, May 10, 2017 at 1:20 PM Instantiation Exception <
> > >>>> instantiationexcept...@gmail.com> wrote:
> > >>>>
> > >>>>> Mark, John
> > >>>>>
> > >>>>> I am not sure if I properly understand so I created demo app with
> my
> > >>>>> current configuration:
> > >>>>> https://github.com/instantiationexception/wildfly-deltaspike-data
> > >>>>>
> > >>>>> Generally there are 4 files specific to DeltaSpike Data:
> > >>>>>
> > >>>>> * EntityManagerProducer.java
> > >>>>> * apache-deltaspike.properties
> > >>>>> * beans.xml
> > >>>>>
> > >>>>> My goals are:
> > >>>>>
> > >>>>> * Use JTA EntityManager provided by WildFly
> > >>>&

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Konrad,

By using a global alternative, you're effectively making what is in
beans.xml ignored.

John

On Wed, May 10, 2017 at 1:32 PM Instantiation Exception <
instantiationexcept...@gmail.com> wrote:

> John,
>
> There is one think which I don't understand:
> apache-deltaspike.properties contains different TransactionStrategy
> than beans.xml
>
> * apache-deltaspike.properties contains
>
> org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> * beans.xml contains
>
> org.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy
>
> Isn't it a conflict?
>
> Best regards,
> Konrad
>
> On Wed, May 10, 2017 at 7:22 PM, John D. Ament 
> wrote:
>
> > Konrad,
> >
> > Yes, what you're doing should work and actually matches what I do
> presently
> > in a production environment.  If you're using the JTA @Transactional what
> > you're doing is what will work for you.
> >
> > John
> >
> > On Wed, May 10, 2017 at 1:20 PM Instantiation Exception <
> > instantiationexcept...@gmail.com> wrote:
> >
> > > Mark, John
> > >
> > > I am not sure if I properly understand so I created demo app with my
> > > current configuration:
> > > https://github.com/instantiationexception/wildfly-deltaspike-data
> > >
> > > Generally there are 4 files specific to DeltaSpike Data:
> > >
> > > * EntityManagerProducer.java
> > > * apache-deltaspike.properties
> > > * beans.xml
> > >
> > > My goals are:
> > >
> > > * Use JTA EntityManager provided by WildFly
> > > * Use @Transactional from javax.transaction
> > > * Mix CDI and EJB
> > >
> > > Generally this demo app works. But I am not sure if more complicated
> app
> > > will work.
> > > Is this configuration correct? Are there any unneeded/invalid elements?
> > >
> > > Best regards,
> > > Konrad
> > >
> > > On Wed, May 10, 2017 at 11:22 AM, Mark Struberg
> >  > > >
> > > wrote:
> > >
> > > > Hi Konrad, John!
> > > >
> > > > Hmm not sure about ContainerManagedTransactionStrategy.
> > > >
> > > > Look at the code, this is probably not named properly. It is
> > essentially
> > > a
> > > > no-op TransactionStrategy. It delegates through without doing
> > something.
> > > >
> > > > This is useful if you GUARANTEED have a ContainerManagedTransation in
> > an
> > > > outer level.
> > > > E.g. if you have some existing code using DeltaSpike @Transactional,
> > and
> > > > you know that you ALWAYS have e.g. a @Stateless @WebService calling
> > your
> > > > code.
> > > > We cannot rename this now because otherwise the Alternatives enabled
> in
> > > > various beans.xml files would go bonkers...
> > > >
> > > > So if you are about to use e.g. an @ApplicationScoped @Transactional
> > bean
> > > > without any EJBs involved at all, then you should rather use the
> > > > BeanManagedUserTransactionStrategy.
> > > > This one leverages the UserTransaction functionality provided by the
> > > > server. If a JTA Transaction is already active then it would simply
> do
> > > > nothing. So in this case it really behaves the same like
> > > > ContainerManagedTransactionStrategy.
> > > >
> > > > But if there is NO active Transaction, then it will use the
> > > > UserTransaction API to open a transaction and to commit/rollback on
> > this
> > > > very layer when leaving the intercepted method. Subsequently invoked
> > > > @Transactional CDI beans - and even EJBs! - will just take this open
> > > > transaction and work with it.
> > > > So this works perfectly fine in cases where you only use CDI but also
> > > when
> > > > you wildly mix EJBs and CDI beans.
> > > > I use this in production for quite a few projects.
> > > >
> > > > Note that the EntityManagerProducer you need to provide must use a
> > > > container provided EntityManagerFactory, otherwise your EntityManager
> > > won't
> > > > integrate with JTA.
> > > > A sample can be found here:
> > > > https://github.com/struberg/lightweightEE/blob/jtacdi11/
> > > > backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/
> > > >

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Konrad,

Yes, what you're doing should work and actually matches what I do presently
in a production environment.  If you're using the JTA @Transactional what
you're doing is what will work for you.

John

On Wed, May 10, 2017 at 1:20 PM Instantiation Exception <
instantiationexcept...@gmail.com> wrote:

> Mark, John
>
> I am not sure if I properly understand so I created demo app with my
> current configuration:
> https://github.com/instantiationexception/wildfly-deltaspike-data
>
> Generally there are 4 files specific to DeltaSpike Data:
>
> * EntityManagerProducer.java
> * apache-deltaspike.properties
> * beans.xml
>
> My goals are:
>
> * Use JTA EntityManager provided by WildFly
> * Use @Transactional from javax.transaction
> * Mix CDI and EJB
>
> Generally this demo app works. But I am not sure if more complicated app
> will work.
> Is this configuration correct? Are there any unneeded/invalid elements?
>
> Best regards,
> Konrad
>
> On Wed, May 10, 2017 at 11:22 AM, Mark Struberg  >
> wrote:
>
> > Hi Konrad, John!
> >
> > Hmm not sure about ContainerManagedTransactionStrategy.
> >
> > Look at the code, this is probably not named properly. It is essentially
> a
> > no-op TransactionStrategy. It delegates through without doing something.
> >
> > This is useful if you GUARANTEED have a ContainerManagedTransation in an
> > outer level.
> > E.g. if you have some existing code using DeltaSpike @Transactional, and
> > you know that you ALWAYS have e.g. a @Stateless @WebService calling your
> > code.
> > We cannot rename this now because otherwise the Alternatives enabled in
> > various beans.xml files would go bonkers...
> >
> > So if you are about to use e.g. an @ApplicationScoped @Transactional bean
> > without any EJBs involved at all, then you should rather use the
> > BeanManagedUserTransactionStrategy.
> > This one leverages the UserTransaction functionality provided by the
> > server. If a JTA Transaction is already active then it would simply do
> > nothing. So in this case it really behaves the same like
> > ContainerManagedTransactionStrategy.
> >
> > But if there is NO active Transaction, then it will use the
> > UserTransaction API to open a transaction and to commit/rollback on this
> > very layer when leaving the intercepted method. Subsequently invoked
> > @Transactional CDI beans - and even EJBs! - will just take this open
> > transaction and work with it.
> > So this works perfectly fine in cases where you only use CDI but also
> when
> > you wildly mix EJBs and CDI beans.
> > I use this in production for quite a few projects.
> >
> > Note that the EntityManagerProducer you need to provide must use a
> > container provided EntityManagerFactory, otherwise your EntityManager
> won't
> > integrate with JTA.
> > A sample can be found here:
> > https://github.com/struberg/lightweightEE/blob/jtacdi11/
> > backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/
> > EntityManagerProducer.java#L40
> >
> >
> > hth.
> >
> > LieGrue,
> > strub
> >
> > > Am 09.05.2017 um 01:50 schrieb John D. Ament :
> > >
> > > Konrad,
> > >
> > > When you specify globalAlternatives, you don't need to specify anything
> > in
> > > beans.xml
> > >
> > > RE which strategy to use, it'll be the one that matches your
> transaction
> > > mode.  If you're using plain JTA just use
> > > ContainerManagedTransactionStrategy.
> > >
> > > John
> > >
> > > On Mon, May 8, 2017 at 3:56 PM Instantiation Exception <
> > > instantiationexcept...@gmail.com> wrote:
> > >
> > >> John,
> > >>
> > >> I want to clarify one thing. When I use
> > >> META-INF/apache-deltaspike.properties with
> > >> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.
> > >> TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.
> > >> ContainerManagedTransactionStrategy
> > >>
> > >> should I use alternative in beans.xml? And which one?
> > >> org.apache.deltaspike.jpa.impl.transaction.
> > ContainerManagedTransactionStr
> > >> ategy
> > >> or
> > >> org.apache.deltaspike.jpa.impl.transaction.
> > BeanManagedUserTransactionStrategy
> > >>
> > >> Best regards,
> > >> Konrad
> > >>
> > >> On Fri, Mar 3, 2017 at 2:57 PM, John D. Ament 
> > 

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Konrad,

When you specify globalAlternatives, you don't need to specify anything in
beans.xml

RE which strategy to use, it'll be the one that matches your transaction
mode.  If you're using plain JTA just use
ContainerManagedTransactionStrategy.

John

On Mon, May 8, 2017 at 3:56 PM Instantiation Exception <
instantiationexcept...@gmail.com> wrote:

> John,
>
> I want to clarify one thing. When I use
> META-INF/apache-deltaspike.properties with
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.
> TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.
> ContainerManagedTransactionStrategy
>
> should I use alternative in beans.xml? And which one?
> org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStr
> ategy
> or
> org.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy
>
> Best regards,
> Konrad
>
> On Fri, Mar 3, 2017 at 2:57 PM, John D. Ament 
> wrote:
>
> > Ondrej,
> >
> > I agree as well.  It definitely should be more turn key in this respect.
> >
> > John
> >
> > On Fri, Mar 3, 2017 at 8:53 AM Ondrej Mihályi 
> > wrote:
> >
> > > Hi John,
> > >
> > > It sounds to me that DeltaSpike could be improved to make a
> sophisticated
> > > guess to infer the default value of this configuration from the
> container
> > > it is running in. At least for WildFly and maybe some other containers
> > > where people report problems.
> > >
> > > Just an idea :)
> > >
> > > Ondrej
> > >
> > > 2017-03-03 12:05 GMT+01:00 John D. Ament :
> > >
> > > > Hi Konrad,
> > > >
> > > > What that's referring to is that you need to create a
> > > > META-INF/apache-deltaspike.properties and add the following line:
> > > >
> > > > globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.
> > > > TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.
> > > > ContainerManagedTransactionStrategy
> > > >
> > > > I do something similar to  you, and it works perfect.  I'm using
> maven
> > to
> > > > build a WAR file, so it just goes in
> > > > src/main/resources/META-INF/apache-deltaspike.properties
> > > >
> > > > John
> > > >
> > > > On Fri, Mar 3, 2017 at 3:38 AM Instantiation Exception <
> > > > instantiationexcept...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > In my company projects we use WildFly. In the past I tried few
> times
> > to
> > > > use
> > > > > DeltaSpike Data, but it didn't work. I configured everything
> > according
> > > to
> > > > > documentation. In pure CDI scenario it worked. But when I created
> > > > > @Dependent @Repository and injected it to @Stateless EJB I got some
> > > > > transaction errors when tried to call EJB methods. In
> documentation I
> > > see
> > > > > warning:
> > > > >
> > > > > Some containers do not support BeanManagedUserTransactionStrategy!
> > As
> > > > JTA
> > > > > > has still some portability issues even in Java EE 7, it might be
> > > > required
> > > > > > that you implement your own TransactionStrategy. We will think
> > about
> > > > > > providing an acceptable solution for this.
> > > > >
> > > > >
> > > > > Is it about WildFly? Is WildFly supported?
> > > > >
> > > > > Best regards,
> > > > > Konrad
> > > > >
> > > >
> > >
> >
>

Re: Howto use DeltaSpike Configuration Module for userprofiles

[John D. Ament]

Hi,

I'm not sure that config is necessarily the same as a preferences API.
Specifically, you want to store use specific attribute values, if I'm
understanding you right, correct?

John

On Fri, Mar 24, 2017 at 2:02 PM Mark Struberg 
wrote:

> Hi folks!
>
> I've implemented a comma separated List handling already, just didn't
> commit it yet.
> Will try to push it over the weekend and put it up for review.
>
> LieGrue,
> strub
>
>
> > Am 23.03.2017 um 09:04 schrieb pawel.mac...@b-m.pl:
> >
> > This could be a great feature. After a small research there are only
> > native Java Preferences ( hate that ) or self made. But it is very common
> > and fits in DS suite in my opinion.
> >
> > Paweł
> >
> >
> >
> >
> > Od: Thomas Lustig 
> > Do: users@deltaspike.apache.org
> > Data:   2017-03-19 10:14
> > Temat:  Howto use DeltaSpike Configuration Module for userprofiles
> >
> >
> >
> > Dear Community,
> >
> > I am really fond of using Deltaspike configuration module to configure my
> > JEE application.
> > I would like to store also data that is specific to application users in
> a
> > kind of profile.
> >
> > config_key  profile_key   config_value
> >
> --
> > johnfavorite_menues my_books,my_posts
> > eliza   favorite_menues my_posts,my_music
> >
> >
> > Are there some best practises how to implement such an additional
> > dimension
> > (profile_key) using deltaspike?
> >
> > Thanking you very much in advance for helping me
> >
> > kind regards
> >
> > Tom
> >
>
>

Re: Using QueryResult as return type without predicate

[John D. Ament]

Matti,

Glad that worked.  I'll point out that's HQL, so hibernate specific (I
wasn't sure if you were using hibernate or not).

I think a method like what you're describing makes sense.  The problem is
that the find prefix is a bit overloaded for this use case.  Do you think a
"queryAll" method would work?

John

On Thu, Mar 16, 2017 at 8:50 AM Matti Tahvonen  wrote:

> Thanks John, that’s indeed a better workaround. It can still be simplified
> to :
>
>@Query("from Person")
>QueryResult findAllPersons();
>
> But I still think it would be cool if empty “QueryResult findAllBy()”
> would work out of the box. With Spring Data you can do pretty much the
> same. I created following Jira issue for it:
> https://issues.apache.org/jira/browse/DELTASPIKE-1239
>
> __
> Matti Tahvonen – +358 44 3029728 <+358%2044%203029728> – Vaadin Ltd -
> vaadin.com
>
>
> > On 15 Mar 2017, at 14:06 , John D. Ament  wrote:
> >
> > Hi,
> >
> > So here's the example from the page..
> >
> > @Repository
> > public interface PersonRepository extends EntityRepository
> > {
> >
> >@Query("select p from Person p where p.age between ?1 and ?2")
> >QueryResult findAllByAge(int minAge, int maxAge);
> >
> > }
> >
> > We're not using a predicate per-se, but its using an inlined query.
> > Unfortunately, any method defined in EntityRepository uses a default
> > handler that's not overridable (I found it hard to add Optional/Stream
> > support).  I would do something like the documentation
> >
> > @Repository
> > public interface PersonRepository extends EntityRepository
> > {
> >
> >@Query("select p from Person p")
> >QueryResult findAllPersons();
> >
> > }
> >
> > Unless you're using the persistence operations as well, it may just be
> > easier to not have the base interface.
> >
> > John
> >
> > On Wed, Mar 15, 2017 at 7:12 AM Matti Tahvonen  <mailto:ma...@vaadin.com>> wrote:
> >
> >> Hi,
> >>
> >> My colleague is preparing an example for Vaadin 8 that uses DeltaSpike
> >> Data (as per my suggestion). We had a hard time finding a solution where
> >> you could return QueryResult form a JPA Repository, without having any
> >> predicates. We want to use QueryResult as it is easy to do sorting and
> >> paging using it, but just want to get all results from the database. In
> >> other words we’d need an alternative to findAll that returns
> QueryResult.
> >>
> >> The workaround was to add a dummy predicate, but that’s not too pretty:
> >>
> >>
> https://github.com/alejandro-du/lazy-loading-cdi-demo/blob/master/src/main/java/com/example/PersonService.java#L23
> >>
> >> QueryResult  findBy() or QueryResult findAllBy() don’t seem to work. Any
> >> ideas how this should be tackled?
> >>
> >> __
> >> Matti Tahvonen – +358 44 3029728 <+358%2044%203029728>
> <+358%2044%203029728> – Vaadin Ltd -
> >> vaadin.com <http://vaadin.com/>
>

Re: Using QueryResult as return type without predicate

[John D. Ament]

Hi,

So here's the example from the page..

@Repository
public interface PersonRepository extends EntityRepository
{

@Query("select p from Person p where p.age between ?1 and ?2")
QueryResult findAllByAge(int minAge, int maxAge);

}

We're not using a predicate per-se, but its using an inlined query.
Unfortunately, any method defined in EntityRepository uses a default
handler that's not overridable (I found it hard to add Optional/Stream
support).  I would do something like the documentation

@Repository
public interface PersonRepository extends EntityRepository
{

@Query("select p from Person p")
QueryResult findAllPersons();

}

Unless you're using the persistence operations as well, it may just be
easier to not have the base interface.

John

On Wed, Mar 15, 2017 at 7:12 AM Matti Tahvonen  wrote:

> Hi,
>
> My colleague is preparing an example for Vaadin 8 that uses DeltaSpike
> Data (as per my suggestion). We had a hard time finding a solution where
> you could return QueryResult form a JPA Repository, without having any
> predicates. We want to use QueryResult as it is easy to do sorting and
> paging using it, but just want to get all results from the database. In
> other words we’d need an alternative to findAll that returns QueryResult.
>
> The workaround was to add a dummy predicate, but that’s not too pretty:
>
> https://github.com/alejandro-du/lazy-loading-cdi-demo/blob/master/src/main/java/com/example/PersonService.java#L23
>
> QueryResult  findBy() or QueryResult findAllBy() don’t seem to work. Any
> ideas how this should be tackled?
>
> __
> Matti Tahvonen – +358 44 3029728 <+358%2044%203029728> – Vaadin Ltd -
> vaadin.com
>
>
>
>
>

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Ondrej,

I agree as well.  It definitely should be more turn key in this respect.

John

On Fri, Mar 3, 2017 at 8:53 AM Ondrej Mihályi 
wrote:

> Hi John,
>
> It sounds to me that DeltaSpike could be improved to make a sophisticated
> guess to infer the default value of this configuration from the container
> it is running in. At least for WildFly and maybe some other containers
> where people report problems.
>
> Just an idea :)
>
> Ondrej
>
> 2017-03-03 12:05 GMT+01:00 John D. Ament :
>
> > Hi Konrad,
> >
> > What that's referring to is that you need to create a
> > META-INF/apache-deltaspike.properties and add the following line:
> >
> > globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.
> > TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.
> > ContainerManagedTransactionStrategy
> >
> > I do something similar to  you, and it works perfect.  I'm using maven to
> > build a WAR file, so it just goes in
> > src/main/resources/META-INF/apache-deltaspike.properties
> >
> > John
> >
> > On Fri, Mar 3, 2017 at 3:38 AM Instantiation Exception <
> > instantiationexcept...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > In my company projects we use WildFly. In the past I tried few times to
> > use
> > > DeltaSpike Data, but it didn't work. I configured everything according
> to
> > > documentation. In pure CDI scenario it worked. But when I created
> > > @Dependent @Repository and injected it to @Stateless EJB I got some
> > > transaction errors when tried to call EJB methods. In documentation I
> see
> > > warning:
> > >
> > > Some containers do not support BeanManagedUserTransactionStrategy! As
> > JTA
> > > > has still some portability issues even in Java EE 7, it might be
> > required
> > > > that you implement your own TransactionStrategy. We will think about
> > > > providing an acceptable solution for this.
> > >
> > >
> > > Is it about WildFly? Is WildFly supported?
> > >
> > > Best regards,
> > > Konrad
> > >
> >
>

Re: DeltaSpike Data - What application servers are supported?

[John D. Ament]

Hi Konrad,

What that's referring to is that you need to create a
META-INF/apache-deltaspike.properties and add the following line:

globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy

I do something similar to  you, and it works perfect.  I'm using maven to
build a WAR file, so it just goes in
src/main/resources/META-INF/apache-deltaspike.properties

John

On Fri, Mar 3, 2017 at 3:38 AM Instantiation Exception <
instantiationexcept...@gmail.com> wrote:

> Hi,
>
> In my company projects we use WildFly. In the past I tried few times to use
> DeltaSpike Data, but it didn't work. I configured everything according to
> documentation. In pure CDI scenario it worked. But when I created
> @Dependent @Repository and injected it to @Stateless EJB I got some
> transaction errors when tried to call EJB methods. In documentation I see
> warning:
>
> Some containers do not support BeanManagedUserTransactionStrategy! As JTA
> > has still some portability issues even in Java EE 7, it might be required
> > that you implement your own TransactionStrategy. We will think about
> > providing an acceptable solution for this.
>
>
> Is it about WildFly? Is WildFly supported?
>
> Best regards,
> Konrad
>

Re: Example unit testing a servlet that uses injection

[John D. Ament]

Stephen,

I suspect the failure is because of the use of mockito.  We provide some
mocking support OOTB, would that help?

http://deltaspike.apache.org/documentation/test-control.html#MockFrameworks

John

On Tue, Feb 28, 2017 at 7:38 AM Stephen More  wrote:

> The current - non working test code can be found here:
> https://github.com/mores/maven-examples/tree/master/prime-deltaspike
>
> Servlet works as expected when deployed - output is survey says: 3.96 (
>
> https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/main/java/org/test/MyServlet.java
> )
>
> But when trying to run the test, windowContext appears to be null. (
>
> https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/test/java/org/test/MyServletTest.java
> )
>
> Any and all help is always appreciated.
>
> On Mon, Feb 27, 2017 at 9:55 PM, Stephen More 
> wrote:
>
> > I have been using
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner
> > to test JSF backing beans and everything seems to be working well.
> >
> >
> > At this point I am struggling how to test a plain old servlet that uses
> > injection, are there any examples anywhere ?
> >
> > Here is what I currently have:
> >
> > @RunWith( CdiTestRunner.class )
> > @TestControl( projectStage = org.apache.deltaspike.core.
> > api.projectstage.ProjectStage.UnitTest.class )
> > public class MyServletTest
> > {
> > private static org.slf4j.Logger log =
> org.slf4j.LoggerFactory.getLogger(
> > MyServletTest.class );
> >
> > @Inject
> > private org.apache.deltaspike.core.spi.scope.window.WindowContext
> > windowContext;
> >
> > @Inject
> > private org.apache.deltaspike.cdise.api.ContextControl
> > contextControl;
> >
> > @InjectMocks
> > private MyServlet myServlet;
> >
> > @After
> > public void teardown()
> > {
> > contextControl.stopContext(
> javax.enterprise.context.ConversationScoped.class
> > );
> > }
> >
> > @Before
> > public void init()
> > {
> > org.mockito.MockitoAnnotations.initMocks( this );
> >
> > contextControl.startContext(
> javax.enterprise.context.ConversationScoped.class
> > );
> > windowContext.activateWindow( "testWindow" );
> > }
> >
> > @Test
> > public void testFinancialEstimateReport() throws Exception
> > {
> > javax.servlet.http.HttpServletRequest request =
> > org.mockito.Mockito.mock( javax.servlet.http.HttpServletRequest.class );
> > javax.servlet.http.HttpServletResponse response =
> > org.mockito.Mockito.mock( javax.servlet.http.HttpServletResponse.class );
> >
> > org.mockito.Mockito.when( request.getServletPath()
> > ).thenReturn( "/this/path" );
> > org.mockito.Mockito.when( request.getParameter( "ID" )
> > ).thenReturn( "1234" );
> > org.mockito.Mockito.when( request.getParameter( "format"
> )
> > ).thenReturn( "PDF" );
> >
> > myServlet.doGet( request, response );
> > }
> > }
> >
> > But the @Inject is not happening inside of MyServlet...what is needed to
> > make this work ?
> >
> > -Thanks
> >
> >
> >
>

Re: Transactional events

[John D. Ament]

Hi,

So the behavior is dependent on a JTA implemetatnion.  Did you provide a
JTA implementation and perform integration?

John

On Sat, Dec 31, 2016 at 9:32 PM Dave Oxley  wrote:

> I'm using Weld 2.4.1.Final.
>
>
> On 1 January 2017 at 13:29, John D. Ament  wrote:
>
> > What version of weld are you using?
> >
> > On Dec 31, 2016 21:02, "Dave Oxley"  wrote:
> >
> > > Hi,
> > >
> > > I'm writing a simple app with Deltaspike JPA, Hibernate and Weld
> > targeting
> > > Tomcat 8 which is working well. I need to setup an Event that is
> > > @Observes(during = TransactionPhase.AFTER_SUCCESS) but the event is
> > being
> > > received when it's fired rather than when the transaction commits. Is
> > there
> > > a way to set this up without going with a full J2EE container?
> > >
> > > Cheers,
> > > Dave.
> > >
> >
>

Re: Transactional events

[John D. Ament]

What version of weld are you using?

On Dec 31, 2016 21:02, "Dave Oxley"  wrote:

> Hi,
>
> I'm writing a simple app with Deltaspike JPA, Hibernate and Weld targeting
> Tomcat 8 which is working well. I need to setup an Event that is
> @Observes(during = TransactionPhase.AFTER_SUCCESS) but the event is being
> received when it's fired rather than when the transaction commits. Is there
> a way to set this up without going with a full J2EE container?
>
> Cheers,
> Dave.
>

Re: DeltaSpike Data - Custom PrePersistAuditListener and PreUpdateAuditListener

[John D. Ament]

Gah shoot, sorry about that.  It won't work because its a package private
class, and the classloader will block it.

I'll get something in to fix this, unfortunately it won't work until my
change is in.  Please do make sure to raise an issue in JIRA so I don't
lose track.  Thanks for checking it out.

John

On Tue, Dec 20, 2016 at 4:07 PM Nico Schlebusch  wrote:

> Hi John,
>
> Thanks for the suggestion on vetoing the TimestampsProvider, but there is
> a new problem with my approach or lack of understanding of Portable
> Extensions.
>
> I first created the portable extension inside my own package structure,
> but then the compiler fails to resolve TimestampsProvider because it is a
> package protected class. I then moved my extension into the same package
> (org.apache.deltaspike.data.impl.audit) as TimestampsProvider but then got
> this exception on deployment
>
> Caused by: java.lang.IllegalAccessError: tried to access class
> org.apache.deltaspike.data.impl.audit.PrincipalProvider from class
> org.apache.deltaspike.data.impl.audit.VetoDeltaSpikeAuditProvidersExtension
> at
> org.apache.deltaspike.data.impl.audit.VetoDeltaSpikeAuditProvidersExtension.rejectPrincipalProvider(VetoDeltaSpikeAuditProvidersExtension.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
>
> I read somewhere that happens when the classes aren't loaded with the same
> classloader.
>
> Any other ideas on how to veto the TimestampsProvider?
>
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com
>
>
> On 20/12/2016 17:23, John D. Ament wrote:
>
> Ok, that makes sense.  I wanted to verify your behavior, which means
> alternative makes no sense here.
>
> So with that said, what I'm thinking is that you can forcibly veto the
> class in a portable extension to disable its execution.  It would be as
> simple as
>
> public void rejectDefaultClass(@Observes
> ProcessAnnotatedType pat) {
> pat.veto();
> }
>
>
> John
>
> On Tue, Dec 20, 2016 at 9:54 AM Nico Schlebusch 
> wrote:
>
> John,
>
> That loop executes the number of times there are implementations of the
> PrePersistAuditListener. When I have my own implementation deployed it
> executes 3 times. The PrincipalProvider, my custom implementation
> (UTCDateTimeAuditProvider) and then TimestampsProvider are executed in
> that order.
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com <mailto:nicos...@gmail.com>
>
>
> On 20/12/2016 16:33, John D. Ament wrote:
> > Nico,
> >
> > There's a for loop here
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java#L38
> >
> > How many times does this for loop execute?
> >
> > John
> >
> > On Tue, Dec 20, 2016 at 9:23 AM Nico Schlebusch 
> wrote:
> >
> >> Hi John,
> >>
> >> Thanks for the answer.
> >>
> >> The AuditEntityListener is called once from my debugging sessions.
> >>
> >> I'll definitely raise a feature request, it might just not be in the
> next
> >> 2 weeks. Would the feature request be to take @Alternative beans into
> >> considerations when looking up the beans that implements the 2
> interfaces,
> >> PrePersistAuditListener & PreUpdateAuditListener? Meaning that lines
> 40-41
> >> and 53-54 from the link below, need to filter out the @Default beans
> when
> >> an @Alternative is available? Or should I phrase it differently?
> >>
> >> Kind regards,
> >> Nico Schlebusch
> >> nicos...@gmail.com
> >>
> >>
> >> On 20/12/2016 15:56, John D. Ament wrote:
> >>
> >> Nico,
> >>
> >> Seems the logic in DeltaSpike is to loop through the beans.  Can you
> check
> >> if you're seeing this loop is called multiple times?
> >>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java
> >>
> >> Anyways, would be good to have this support direct in deltaspike.  Mind
> >> raising a feature request?
> >> https://issues.apache.org/jira/browse/DELTASPIKE
> >>
> >> John
> >>
>
>
>

Re: DeltaSpike Data - Custom PrePersistAuditListener and PreUpdateAuditListener

[John D. Ament]

Ok, that makes sense.  I wanted to verify your behavior, which means
alternative makes no sense here.

So with that said, what I'm thinking is that you can forcibly veto the
class in a portable extension to disable its execution.  It would be as
simple as

public void rejectDefaultClass(@Observes
ProcessAnnotatedType pat) {
pat.veto();
}


John

On Tue, Dec 20, 2016 at 9:54 AM Nico Schlebusch  wrote:

> John,
>
> That loop executes the number of times there are implementations of the
> PrePersistAuditListener. When I have my own implementation deployed it
> executes 3 times. The PrincipalProvider, my custom implementation
> (UTCDateTimeAuditProvider) and then TimestampsProvider are executed in
> that order.
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com <mailto:nicos...@gmail.com>
>
>
> On 20/12/2016 16:33, John D. Ament wrote:
> > Nico,
> >
> > There's a for loop here
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java#L38
> >
> > How many times does this for loop execute?
> >
> > John
> >
> > On Tue, Dec 20, 2016 at 9:23 AM Nico Schlebusch 
> wrote:
> >
> >> Hi John,
> >>
> >> Thanks for the answer.
> >>
> >> The AuditEntityListener is called once from my debugging sessions.
> >>
> >> I'll definitely raise a feature request, it might just not be in the
> next
> >> 2 weeks. Would the feature request be to take @Alternative beans into
> >> considerations when looking up the beans that implements the 2
> interfaces,
> >> PrePersistAuditListener & PreUpdateAuditListener? Meaning that lines
> 40-41
> >> and 53-54 from the link below, need to filter out the @Default beans
> when
> >> an @Alternative is available? Or should I phrase it differently?
> >>
> >> Kind regards,
> >> Nico Schlebusch
> >> nicos...@gmail.com
> >>
> >>
> >> On 20/12/2016 15:56, John D. Ament wrote:
> >>
> >> Nico,
> >>
> >> Seems the logic in DeltaSpike is to loop through the beans.  Can you
> check
> >> if you're seeing this loop is called multiple times?
> >>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java
> >>
> >> Anyways, would be good to have this support direct in deltaspike.  Mind
> >> raising a feature request?
> >> https://issues.apache.org/jira/browse/DELTASPIKE
> >>
> >> John
> >>
> >> On Tue, Dec 13, 2016 at 2:58 AM Nico Schlebusch 
> >> wrote:
> >>
> >> Good day,
> >>
> >> I have made some progress in answering my question, but I'm facing a new
> >> problem. Please see the updated Q on SO -
> >>
> >>
> http://stackoverflow.com/questions/41057116/deltaspike-data-cdi-jpa-custom-prepersistauditlistener-and-preupdateauditlis
> >>
> >> Thank you
> >>
> >> Kind regards,
> >> Nico Schlebusch
> >> nicos...@gmail.com <mailto:nicos...@gmail.com>
> >>
> >>
> >> On 07/12/2016 12:22, Nico Schlebusch wrote:
> >>> Good day,
> >>>
> >>> I'm using the @EntityListeners(AuditEntityListener.class) and
> >>> @CreatedOn, @ModifiedOn and @ModifiedBy annotations on an Entity bean
> >>> with the difference that I have a custom implementation of
> >>> java.time.ChronoLocalDateTime which converts any LocalDateTime +
> >>> ZoneOffset OR a ZonedDateTime to be the UTC date & time.
> >>>
> >>>  public class UTCDateTime implements
> >>>  ChronoLocalDateTime, Serializable {
> >>>
> >>>private static final long serialVersionUID =
> 6492792765662073566L;
> >>>private static final ZoneOffset UTC = ZoneOffset.UTC;
> >>>private final LocalDateTime datetime;
> >>>
> >>>// a lot of other details left out
> >>>  }
> >>>
> >>> The entity bean parts
> >>>
> >>>  @MappedSuperclass
> >>>  public class InsertableAuditableBean extends BaseBean implements
> >>>  InsertableAuditable {
> >>>
> >>>@NotNull
> >>>@Size(min = 1, max = 50)
> >>>@Column(name = "zz_inserted_by", length = 50, nullable = fal

Re: DeltaSpike Data - Custom PrePersistAuditListener and PreUpdateAuditListener

[John D. Ament]

Nico,

There's a for loop here
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java#L38

How many times does this for loop execute?

John

On Tue, Dec 20, 2016 at 9:23 AM Nico Schlebusch  wrote:

> Hi John,
>
> Thanks for the answer.
>
> The AuditEntityListener is called once from my debugging sessions.
>
> I'll definitely raise a feature request, it might just not be in the next
> 2 weeks. Would the feature request be to take @Alternative beans into
> considerations when looking up the beans that implements the 2 interfaces,
> PrePersistAuditListener & PreUpdateAuditListener? Meaning that lines 40-41
> and 53-54 from the link below, need to filter out the @Default beans when
> an @Alternative is available? Or should I phrase it differently?
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com
>
>
> On 20/12/2016 15:56, John D. Ament wrote:
>
> Nico,
>
> Seems the logic in DeltaSpike is to loop through the beans.  Can you check
> if you're seeing this loop is called multiple times?
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java
>
> Anyways, would be good to have this support direct in deltaspike.  Mind
> raising a feature request?
> https://issues.apache.org/jira/browse/DELTASPIKE
>
> John
>
> On Tue, Dec 13, 2016 at 2:58 AM Nico Schlebusch 
> wrote:
>
> Good day,
>
> I have made some progress in answering my question, but I'm facing a new
> problem. Please see the updated Q on SO -
>
> http://stackoverflow.com/questions/41057116/deltaspike-data-cdi-jpa-custom-prepersistauditlistener-and-preupdateauditlis
>
> Thank you
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com <mailto:nicos...@gmail.com>
>
>
> On 07/12/2016 12:22, Nico Schlebusch wrote:
> > Good day,
> >
> > I'm using the @EntityListeners(AuditEntityListener.class) and
> > @CreatedOn, @ModifiedOn and @ModifiedBy annotations on an Entity bean
> > with the difference that I have a custom implementation of
> > java.time.ChronoLocalDateTime which converts any LocalDateTime +
> > ZoneOffset OR a ZonedDateTime to be the UTC date & time.
> >
> > public class UTCDateTime implements
> > ChronoLocalDateTime, Serializable {
> >
> >   private static final long serialVersionUID = 6492792765662073566L;
> >   private static final ZoneOffset UTC = ZoneOffset.UTC;
> >   private final LocalDateTime datetime;
> >
> >   // a lot of other details left out
> > }
> >
> > The entity bean parts
> >
> > @MappedSuperclass
> > public class InsertableAuditableBean extends BaseBean implements
> > InsertableAuditable {
> >
> >   @NotNull
> >   @Size(min = 1, max = 50)
> >   @Column(name = "zz_inserted_by", length = 50, nullable = false)
> >   private String insertedBy;
> >
> > @CreatedOn
> >   @NotNull
> >   @Temporal(value = TemporalType.TIMESTAMP)
> >   @Column(name = "zz_inserted_on", nullable = false)
> >   private UTCDateTime insertedOn;
> >
> >   // getters & setters
> > }
> >
> > @MappedSuperclass
> > public class UpdateableAuditableBean extends
> > InsertableAuditableBean implements UpdateableAuditable {
> >
> > @ModifiedBy
> >   @Size(min = 1, max = 50)
> >   @Column(name = "zz_updated_by", length = 50, nullable = true)
> >   private String updatedBy;
> >
> > @ModifiedOn
> >   @Temporal(value = TemporalType.TIMESTAMP)
> >   @Column(name = "zz_updated_on", nullable = true)
> >   private UTCDateTime updatedOn;
> >
> >   // getters & setters
> > }
> >
> > @Entity
> > @EntityListeners(AuditEntityListener.class)
> > @Table(schema = "data", name = "manufacturer", uniqueConstraints = {
> > @UniqueConstraint(columnNames = { "man_name", "man_country" })
> > })
> > @AttributeOverrides({
> > @AttributeOverride(name = "primaryKey", column = @Column(name
> > = "man_serial")),
> > @AttributeOverride(name = "insertedBy", column = @Column(name
> > = "man_inserted_by")),
> > @AttributeOverride(name = "insertedOn", column = @Column(name
> > = &quo

Re: DeltaSpike Data - Custom PrePersistAuditListener and PreUpdateAuditListener

[John D. Ament]

Nico,

Seems the logic in DeltaSpike is to loop through the beans.  Can you check
if you're seeing this loop is called multiple times?
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java

Anyways, would be good to have this support direct in deltaspike.  Mind
raising a feature request? https://issues.apache.org/jira/browse/DELTASPIKE

John

On Tue, Dec 13, 2016 at 2:58 AM Nico Schlebusch  wrote:

> Good day,
>
> I have made some progress in answering my question, but I'm facing a new
> problem. Please see the updated Q on SO -
>
> http://stackoverflow.com/questions/41057116/deltaspike-data-cdi-jpa-custom-prepersistauditlistener-and-preupdateauditlis
>
> Thank you
>
> Kind regards,
> Nico Schlebusch
> nicos...@gmail.com 
>
>
> On 07/12/2016 12:22, Nico Schlebusch wrote:
> > Good day,
> >
> > I'm using the @EntityListeners(AuditEntityListener.class) and
> > @CreatedOn, @ModifiedOn and @ModifiedBy annotations on an Entity bean
> > with the difference that I have a custom implementation of
> > java.time.ChronoLocalDateTime which converts any LocalDateTime +
> > ZoneOffset OR a ZonedDateTime to be the UTC date & time.
> >
> > public class UTCDateTime implements
> > ChronoLocalDateTime, Serializable {
> >
> >   private static final long serialVersionUID = 6492792765662073566L;
> >   private static final ZoneOffset UTC = ZoneOffset.UTC;
> >   private final LocalDateTime datetime;
> >
> >   // a lot of other details left out
> > }
> >
> > The entity bean parts
> >
> > @MappedSuperclass
> > public class InsertableAuditableBean extends BaseBean implements
> > InsertableAuditable {
> >
> >   @NotNull
> >   @Size(min = 1, max = 50)
> >   @Column(name = "zz_inserted_by", length = 50, nullable = false)
> >   private String insertedBy;
> >
> > @CreatedOn
> >   @NotNull
> >   @Temporal(value = TemporalType.TIMESTAMP)
> >   @Column(name = "zz_inserted_on", nullable = false)
> >   private UTCDateTime insertedOn;
> >
> >   // getters & setters
> > }
> >
> > @MappedSuperclass
> > public class UpdateableAuditableBean extends
> > InsertableAuditableBean implements UpdateableAuditable {
> >
> > @ModifiedBy
> >   @Size(min = 1, max = 50)
> >   @Column(name = "zz_updated_by", length = 50, nullable = true)
> >   private String updatedBy;
> >
> > @ModifiedOn
> >   @Temporal(value = TemporalType.TIMESTAMP)
> >   @Column(name = "zz_updated_on", nullable = true)
> >   private UTCDateTime updatedOn;
> >
> >   // getters & setters
> > }
> >
> > @Entity
> > @EntityListeners(AuditEntityListener.class)
> > @Table(schema = "data", name = "manufacturer", uniqueConstraints = {
> > @UniqueConstraint(columnNames = { "man_name", "man_country" })
> > })
> > @AttributeOverrides({
> > @AttributeOverride(name = "primaryKey", column = @Column(name
> > = "man_serial")),
> > @AttributeOverride(name = "insertedBy", column = @Column(name
> > = "man_inserted_by")),
> > @AttributeOverride(name = "insertedOn", column = @Column(name
> > = "man_inserted_on")),
> > @AttributeOverride(name = "updatedBy", column = @Column(name =
> > "man_updated_by")),
> > @AttributeOverride(name = "updatedOn", column = @Column(name =
> > "man_updated_on"))
> > })
> > @SequenceGenerator(name = "default_seq", schema = "data",
> > sequenceName = "manufacturer_man_serial_seq",
> > allocationSize = 1)
> > public class Manufacturer extends MirroredUpdateableAuditableBean
> > implements IManufacturer {
> >   // nothing special here
> > }
> >
> > There is also a custom AttributeConverter for the UTCDateTime class
> > because the epoch value is saved in the database.
> >
> > @Converter(autoApply = true)
> > public class UTCDateTimePersistenceConverter implements
> > AttributeConverter {
> >
> >   @Override
> >   public Long convertToDatabaseColumn(final UTCDateTime entityValue)
> {
> > Long res = null;
> > if (entityValue != null) {
> >   res = entityValue.toMillis();
> > }
> > return res;
> >   }
> >
> >   @Override
> >   public UTCDateTime convertToEntityAttribute(final Long
> > databaseValue) {
> > UTCDateTime res = null;
> > if (databaseValue != null) {
> >   res = new UTCDateTime(Instant.ofEpochMilli(databaseValue));
> > }
> > return res;
> >   }
> > }
> >
> > Now when I persist the entity I get the following exception (the last
> > bit with the real cause):
> >
> > Caused by:
> > org.apache.deltaspike.data.api.QueryInvocationException: Failed
> > calling Repository:
> >
>  
> [Repository=systems.apace.data.manufacturer.model.dao.ManufacturerDAO,entity=systems.apace.

[DISCUSS] 1.7.2 release

[John D. Ament]

Hey guys

I was looking at the pending release, 1.7.2.  It looks like we're in good
shape, there's one open ticket around adding a new example - maybe it'll
slip or maybe I'll get to it (DELTASPIKE-1205).  Either way, I'm thinking
to call for a vote mid next week on 1.7.2.

Here's the potential release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820&version=12337868

Thoughts?

John

Re: Projectstage -> JNDI - Third Try

[John D. Ament]

Hi Thomas,

I'm not too familiar with this type of usage.  However, ProjectStage is a
concrete type in DeltaSpike, not a string.  That might be part of it.  You
may also need to provide a producer method.

John

On Tue, Oct 4, 2016 at 6:59 AM Thomas Kernstock <
t.kernst...@e-technologies.at> wrote:

> Sorry guys,
>
> I don't want to bug you but its seems that all images and attachments are
> removed from my mails.
>
> I would like to configure the Deltaspike ProjectStage via JNDI as Custom
> resource on Payara 4.1 but it doesn't get picked up. I tried two different
> configurations:
>
> 1)  factory-class="org.glassfish.resources.custom.factory.PrimitivesAndStringFactory"
> res-type="java.lang.String" jndi-name="deltaspike/ProjectStage">
>   
> 
>
> 2) In combination with an entry in Web.xml - similar to the configuration
> for the jsf/ProjectStage:
>
>  factory-class="org.glassfish.resources.custom.factory.PrimitivesAndStringFactory"
> res-type="java.lang.String" jndi-name="org.apache.deltaspike.ProjectStage">
>   
> 
>
>
> 
> deltaspike/ProjectStage
> java.lang.String
> org.apache.deltaspike.ProjectStage
> 
>
>
> To make sure my environment and my tests work, I also tried to set the
> stage with a JVM Parameter. This works.
>
> Also setting the JSF ProjectStage works fine in Payara
>
> factory-class="com.sun.faces.application.ProjectStageJndiFactory"
> res-type="java.lang.String" jndi-name="javax.faces.PROJECT_STAGE">
>   
> 
>
> in combination with Web.xml
>
> 
> jsf/ProjectStage
> java.lang.String
> javax.faces.PROJECT_STAGE
> 
>
>
>
> So the question is what is wrong with my Deltaspike configuration. Any
> ideas?
>
> best regards
> Thomas
>
>

Re: EAR using Deltaspike

[John D. Ament]

Ok, I see you're packaging JARs.  Is DeltaSpike packaged in your lib folder?

And I have to ask - do you need to use EAR packaging?  Your whole
deployment structure is going to be orders of magnitude less complex by
packaging a WAR file, with your dependent JARs in it.

John

On Sat, Sep 17, 2016 at 7:38 AM  wrote:

> Hi everyone,
>
> I just starting to try using deltaspike.
> To begin I create a EAR Project using the tutorial (
> https://vaadin.com/wiki/-/wiki/Main/Implementing+Enterprise+Web+applications+with+Vaadin),
> and deploying on a Wildfly 10.1 .
> This is made of three components:
> • Common – where I keep my entities
> • Backend – used for the EJB and where I try to use the Deltaspike
> • UI – using Vaadin (I think that this is irrelevant for my problem)
>
> On the “Backend”, I add this to my pom.xml:
> …
> 
>
> org.apache.deltaspike.distribution
> distributions-bom
> 1.7.1
> pom
> import
> 
> 
> …
> 
> org.apache.deltaspike.core
> deltaspike-core-api
> compile
> 
> 
> org.apache.deltaspike.core
> deltaspike-core-impl
> runtime
> 
> 
> org.apache.deltaspike.modules
> deltaspike-data-module-api
> compile
> 
> 
> org.apache.deltaspike.modules
>
> deltaspike-data-module-impl
> runtime
> 
>
> And exposed the entity manager:
> public class CdiConfig {
> @Produces
> @Dependent
> @PersistenceContext(unitName = "proto2")
> public EntityManager entityManager;
> }
>
> Next, I created a simple entity:
> @Entity
> @Table(name = "customers")
> public class Customer {
> private String contactPerson;
> private String email;
> << Setters and Getters add>>
> …
>
> And an generic repository to host common methods:
> public interface GenericRepository extends EntityRepository {
> public T findById(Long id);
> }
>
> Last, I created a specific eepository for the customer entity:
> @RequestScoped
> @Repository(forEntity = Customer.class)
> public interface CustomerRepository extends GenericRepository {
> public QueryResult findByNameLikeIgnoreCase(String
> filter);
> }
>
> The problem is that when I deploy the .ear file, I get this errors:
> 12:15:30,686 WARN  [org.jboss.modules] (MSC service thread 1-3) Failed to
> define class org.rna.vaadin.proto2.ejb.dao.GenericRepository in Module
> "deployment.proto2.ear.backend.jar:main" from Service Module Loader:
> java.lang.NoClassDefFoundError: Failed to link
> org/rna/vaadin/proto2/ejb/dao/GenericRepository (Module
> "deployment.proto2.ear.backend.jar:main" from Service Module Loader):
> org/apache/deltaspike/data/api/EntityRepository
> at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> …
> And,
> 12:15:30,686 WARN  [org.jboss.modules] (MSC service thread 1-3) Failed to
> define class org.rna.vaadin.proto2.ejb.dao.CustomerRepository in Module
> "deployment.proto2.ear.backend.jar:main" from Service Module Loader:
> java.lang.NoClassDefFoundError: Failed to link
> org/rna/vaadin/proto2/ejb/dao/CustomerRepository (Module
> "deployment.proto2.ear.backend.jar:main" from Service Module Loader):
> Failed to link org/rna/vaadin/proto2/ejb/dao/GenericRepository (Module
> "deployment.proto2.ear.backend.jar:main" from Service Module Loader):
> org/apache/deltaspike/data/api/EntityRepository
> at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
> at
> org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> …
>
> For simplicity, I didn’t write here the remaining JPA or project settings.
>
> What am I doing wrong? Or did I missed something?
>
> Thank you in advance
>
> Ricardo
>

Re: deltaspike 1.7.1 with tomee 1.7.1 plus not work

[John D. Ament]

Are you able to share a sample project?

On Sep 11, 2016 16:17, "mauro2java2...@gmail.com" 
wrote:

>
> please a tips:
> i jave tried with a maven project.
> I have added the core api and impl , jsf module api and impl for jee6, and
> the module security api and impl.
> i have noted that when i packege i get also the jars for  module proxy api
> and impl witout insert into pom.xml.
>
> So i ask the module proxy is mandatory for get jsf modules to work?
>
> my precedent test is without maven and it not deploy. Into theis test i
> not have put the jars for module proxy.
>
> Now with a maven project i get also the jars for module proxy and it
> deploy on tomee.1.7.1
>
> On 2016-09-11 16:54 (+0200), Mark Struberg 
> wrote:
> > So the application doesn't even deploy?
> >
> > I guess that is the reason why the container fails to shutdown properly.
> Because the app was not even really started. We need the log from the boot.
> Please look for any warning or errors during the boot.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> > > On Sunday, 11 September 2016, 15:55, "mauro2java2...@gmail.com" <
> mauro2java2...@gmail.com> wrote:
> > > >
> > > I have put into web-inf/lib
> > >
> > > Into my web project library i put the following jars of deltaspike.
> > >
> > > deltaspike-core-api-1.7.1.jar
> > > deltaspike-core-impl-1.7.1.jar
> > >
> > > deltaspike-security-module-api-1.7.1.jar
> > > deltaspike-security-module-impl-1.7.1.jar
> > >
> > > deltaspike-jsf-module-api-1.7.1.jar
> > > deltaspike-jsf-module-impl-ee6-1.7.1.jar because i use jee with jee6.
> > >
> > >
> > > Not put the
> > > deltaspike-jsf-module-impl-1.7.1.jar because tomee1.7.1 plus is jee6
> > >
> > > The war  is buils without ereor. But when i deploy not success.
> > > Yes i have tried to undeploy.
> > > And the log is from tomee log
> > >
> > >
> > >
> > > On 2016-09-11 13:19 (+0200), Mark Struberg 
> > > wrote:
> > >>  Hmm, I would need to dig deeper. Probably it has to do that
> OpenWebBeans
> > > get stopped before MyFaces?
> > >>  Does the app work at all? I mean this stack trace is clearly from
> shutting
> > > down the app.
> > >>  Does your app start and is usable and the problem only arises at
> shutdown?
> > >>  Or doesn't it work at all?
> > >>
> > >>  txs and LieGrue,
> > >>  strub
> > >>
> > >>
> > >>
> > >>
> > >>  > On Sunday, 11 September 2016, 13:10, Mark Struberg
> > >  wrote:
> > >>  > > Do you have the deltaspike-core impl and api jars in your
> > > deployable?Is this a
> > >>  > WAR file or an EAR?We will have to look into MyFaces when this
> exactly
> > > gets
> > >>  > fired.
> > >>  >
> > >>  >
> > >>  > LieGrue,strub
> > >>  >
> > >>  >
> > >>  >
> > >>  > On Saturday, 10 September 2016, 22:11,
> > > "mauro2java2...@gmail.com"
> > >>  >  wrote:
> > >>  >
> > >>  >
> > >>  >
> > >>  >
> > >>  > Hi all.
> > >>  > I have tried to write a web app with deltaspike 1.7.1 . but when i
> > > deploy into
> > >>  > tomee1.7.1 plus i get error
> > >>  >
> > >>  >
> > >>  > it not deploy .
> > >>  >
> > >>  > i have already put my beans.xml file
> > >>  >
> > >>  > 
> > >>  > 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/beans_1_0.xsd";>
> > >>  > 
> > >>  >
> > >>  > from the tomee logs :
> > >>  >
> > >>  >
> > >>  >
> > >>  > set 09, 2016 12:15:26 PM org.apache.catalina.core.StandardContext
> > > listenerStop
> > >>  > SEVERE: Exception sending context destroyed event to listener
> instance
> > > of class
> > >>  > org.apache.myfaces.webapp.StartupServletContextListener
> > >>  > java.lang.IllegalStateException: No
> > >>  > org.apache.deltaspike.core.api.provider.BeanManagerProvider in
> place!
> > > Please
> > >>  > ensure that you configured the CDI implementation of your choice
> > > properly. If
> > >>  > your setup is correct, please clear all caches and compiled
> artifacts.
> > >>  > at
> > >>  >
> > > org.apache.deltaspike.core.api.provider.BeanManagerProvider.
> getInstance(BeanManagerProvider.java:164)
> > >>  > at
> > >>  >
> > > org.apache.deltaspike.jsf.impl.listener.system.
> JsfSystemEventBroadcaster.processEvent(JsfSystemEventBroadcaster.java:55)
> > >>  > at
> > > javax.faces.event.SystemEvent.processListener(SystemEvent.java:43)
> > >>  > at
> > >>  >
> > > org.apache.myfaces.application.ApplicationImpl._traverseListenerList(
> ApplicationImpl.java:2493)
> > >>  > at
> > >>  >
> > > org.apache.myfaces.application.ApplicationImpl.
> access$000(ApplicationImpl.java:120)
> > >>  > at
> > >>  >
> > > org.apache.myfaces.application.ApplicationImpl$
> SystemListenerEntry.publish(ApplicationImpl.java:2684)
> > >>  > at
> > >>  >
> > > org.apache.myfaces.application.ApplicationImpl.
> publishEvent(ApplicationImpl.java:601)
> > >>  > at
> > >>  >
> > > javax.faces.application.Applicatio

Re: Deltaspike and JEE7

[John D. Ament]

Hi,

There are open questions from that thread.  are you sure its the same exact
setup as you? They're using websphere, you're on EAP.

I run DS 1.7.1 on Wildfly 10 which is similar to EAP 7 without any issues.

John

On Wed, Aug 24, 2016 at 11:15 AM CHALLUT Nicolas <
nicolas.chal...@soprabanking.com> wrote:

> Hello,
>
>
>
> I faced the same errors that have been described here
> 
> .
>
>
>
> I am using JBoss EAP 7.0 and I tested with deltaspike 1.4.1 & 1.70.
>
>
>
> Feel free to ask me more J
>
>
>
>
> *Nicolas CHALLUT*
>
> Software RDM France
>
> *[image: Sopra Banking Software]*
>
> Sopra Banking Software
> 3 rue du Pré Faucon
> PAE - Les Glaisins - CS 30238
> 74942 Annecy-le-Vieux Cedex - France
> Phone: +33 (0)4 50 33 30 30
> nicolas.chal...@soprabanking.com - www.soprabanking.com
>
> Le contenu de cet e-mail est susceptible d'être confidentiel, soumis au
> secret professionnel ou protégé par la loi. L'utilisation, la copie et la
> divulgation non autorisées d'une partie ou de l'intégralité de ce message
> sont susceptibles d'être illégales. Si vous avez reçu ce message par
> erreur, supprimez-le après avoir averti l'expéditeur. Les pièces jointes du
> présent e-mail ont fait l'objet d'un contrôle antivirus. Néanmoins, nous
> déclinons toute responsabilité concernant les dommages causés par
> d'éventuels virus.
> Pensez à l'environnement avant d'imprimer.
>
>
>

Re: Too many Warnings using deltaspike 1.7.1

[John D. Ament]

Rodrigo,

Those warnings won't go away unless you bring in my changes.  But I think
I'm going to clean it up a bit more.

John

On Mon, Aug 15, 2016 at 7:08 PM rodrigotessarollone...@gmail.com <
rodrigotessarollone...@gmail.com> wrote:

>
>
> On 2016-08-15 18:00 (-0300), "John D. Ament" 
> wrote:
> > Rodrigo,
> >
> > Could you paste your warnings?
> >
> > John
> >
> > On Mon, Aug 15, 2016 at 2:53 PM rodrigotessarollone...@gmail.com <
> > rodrigotessarollone...@gmail.com> wrote:
> >
> > >
> > >
> > > On 2016-08-14 20:26 (-0300), "John D. Ament" 
> > > wrote:
> > > > The warnings seem to be caused by a change I put in heading to 1.7.0
> to
> > > > break down the large interface of EntityRepository into more
> components
> > > > (mostly to make it easier to leverages parts of it when using a Java
> 8
> > > > based repository).  For some reason, even though EntityRepository
> brings
> > > > the other two in, Weld didn't like it and wanted me to directly
> inherit
> > > > those interfaces.  I've pinged the weld guys to see why.
> > > >
> > > > There's a fix in master, and I think you can work around it in your
> > > > repository by directly implementing the new interfaces
> > > > (EntityCountRepository, EntityPersistenceRepository).
> > > >
> > > > John
> > > >
> > > > On Sun, Aug 14, 2016 at 5:38 PM John D. Ament  >
> > > wrote:
> > > >
> > > > > Just created:
> https://issues.apache.org/jira/browse/DELTASPIKE-1192
> > > > >
> > > > > I just noticed this as well, and was going to ask my scrum team why
> > > > > increased the logs :-)
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > > On Sun, Aug 14, 2016 at 3:23 AM  wrote:
> > > > >
> > > > >> Same here. It started from 1.7.0. Before was ok.
> > > > >>
> > > > >> Paweł
> > > > >>
> > > > >>
> > > > >>
> > > > >> Od: Rodrigo Tessarollo 
> > > > >> Do: users@deltaspike.apache.org
> > > > >> Data:   2016-08-14 08:40
> > > > >> Temat:  Too many Warnings using deltaspike 1.7.1
> > > > >>
> > > > >>
> > > > >>
> > > > >> Hi, I'm facing of a annoyning issue when using deltaspike on
> wildfly
> > > 10.
> > > > >>
> > > > >> The console outputs too many warning messages like this:
> > > > >>
> > > > >> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread
> 1-5)
> > > > >> WELD-001117: Member refresh
> > > > >>
> > > > >>
> > >
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1030b45
> > > > >> )
> > > > >> does not belong to the actual class hierarchy of the annotatedType
> > > > >> org.apache.deltaspike.data.api.AbstractEntityRepository
> > > > >>
> > > > >>
> > >
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> > > > >> )
> > > > >> at
> > > > >>
> > > > >>
> > >
> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
> > > > >>   StackTrace:
> > > > >> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread
> 1-5)
> > > > >> WELD-001117: Member saveAndFlush
> > > > >>
> > > > >>
> > >
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1d249da
> > > > >> )
> > > > >> does not belong to the actual class hierarchy of the annotatedType
> > > > >> org.apache.deltaspike.data.api.AbstractEntityRepository
> > > > >>
> > > > >>
> > >
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> > > > >> )
> > > > >>
> > > > >> N other wanings ...
> > > > >>
> > > > >>
> > > > >> The warnigs above is about the EntityPersistenceRepository, but
> the
> > > same
> > > > >&

Re: No jars in distribution-full-1.7.1.zip?

[John D. Ament]

Created https://issues.apache.org/jira/browse/DELTASPIKE-1194
I suspect the pom file changes to remove the extra dependencies changed the
behavior.

John

On Tue, Aug 16, 2016 at 9:38 AM John D. Ament  wrote:

> Looks like ASF nexus and Maven Central are giving inconsistent results.
>
> John
>
> On Tue, Aug 16, 2016 at 9:34 AM Gerhard Petracek 
> wrote:
>
>> the last release i did (in april) looks fine (see [1]).
>> 1.7.0 and 1.7.1 look broken in that regard, however, it's possible to
>> download the jars separately (see [2], [3] and [4]).
>>
>> regards,
>> gerhard
>>
>> [1]
>>
>> http://central.maven.org/maven2/org/apache/deltaspike/distribution/distribution-full/1.6.1/distribution-full-1.6.1.zip
>> [2] http://central.maven.org/maven2/org/apache/deltaspike/core/
>> [3] http://central.maven.org/maven2/org/apache/deltaspike/modules/
>> [4] http://central.maven.org/maven2/org/apache/deltaspike/cdictrl/
>>
>>
>>
>> 2016-08-16 15:29 GMT+02:00 John D. Ament :
>>
>> > Definitely supposed to be there.  Looks like an issue w/ 1.7.0 and
>> 1.6.1 as
>> > well (probably earlier).  Give me some time to take a look, but for now
>> > could you download the JARs via maven?
>> >
>> > John
>> >
>> > On Tue, Aug 16, 2016 at 9:09 AM Chris Baumgartner <
>> > chris.baumgart...@fujifilm.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > I'm trying to download the full distribution of Deltaspike 1.7.1.
>> > >
>> > > When I unzip the file, there are no jar files in it.
>> > >
>> > > The directory structure is:
>> > >
>> > > cdictrl
>> > > - module.xml
>> > > core
>> > > - module.xml
>> > > modules
>> > > - module.xml
>> > > LICENSE
>> > > NOTICE
>> > > README.md
>> > >
>> > > That's all that is in the zip. I thought it was supposed to contain
>> jar
>> > > files. Am I missing something?
>> > >
>> > > Thanks.
>> > >
>> > > --
>> > > Chris Baumgartner
>> > > Java Software Developer
>> > > FUJIFILM Medical Systems U.S.A., Inc.
>> > > TeraMedica Division
>> > > 10400 Innovation Drive, Suite 200
>> > > Milwaukee, WI 53226
>> > > Office: (414) 908-7724
>> > > www.teramedica.com
>> > >
>> > > *Helping provide healthcare experiences that enhance the quality of
>> > life. *
>> > >
>> > > --
>> > > NOTICE: This message, including any attachments, is only for the use
>> of
>> > the
>> > > intended recipient(s) and may contain confidential and privileged
>> > > information, or information otherwise protected from disclosure by
>> law.
>> > If
>> > > the reader of this message is not the intended recipient, you are
>> hereby
>> > > notified that any use, disclosure, copying, dissemination or
>> distribution
>> > > of this message or any of its attachments is strictly prohibited.  If
>> you
>> > > received this message in error, please contact the sender immediately
>> by
>> > > reply email and destroy this message, including all attachments, and
>> any
>> > > copies thereof.
>> > >
>> >
>>
>

Re: No jars in distribution-full-1.7.1.zip?

[John D. Ament]

Looks like ASF nexus and Maven Central are giving inconsistent results.

John

On Tue, Aug 16, 2016 at 9:34 AM Gerhard Petracek 
wrote:

> the last release i did (in april) looks fine (see [1]).
> 1.7.0 and 1.7.1 look broken in that regard, however, it's possible to
> download the jars separately (see [2], [3] and [4]).
>
> regards,
> gerhard
>
> [1]
>
> http://central.maven.org/maven2/org/apache/deltaspike/distribution/distribution-full/1.6.1/distribution-full-1.6.1.zip
> [2] http://central.maven.org/maven2/org/apache/deltaspike/core/
> [3] http://central.maven.org/maven2/org/apache/deltaspike/modules/
> [4] http://central.maven.org/maven2/org/apache/deltaspike/cdictrl/
>
>
>
> 2016-08-16 15:29 GMT+02:00 John D. Ament :
>
> > Definitely supposed to be there.  Looks like an issue w/ 1.7.0 and 1.6.1
> as
> > well (probably earlier).  Give me some time to take a look, but for now
> > could you download the JARs via maven?
> >
> > John
> >
> > On Tue, Aug 16, 2016 at 9:09 AM Chris Baumgartner <
> > chris.baumgart...@fujifilm.com> wrote:
> >
> > > Hello,
> > >
> > > I'm trying to download the full distribution of Deltaspike 1.7.1.
> > >
> > > When I unzip the file, there are no jar files in it.
> > >
> > > The directory structure is:
> > >
> > > cdictrl
> > > - module.xml
> > > core
> > > - module.xml
> > > modules
> > > - module.xml
> > > LICENSE
> > > NOTICE
> > > README.md
> > >
> > > That's all that is in the zip. I thought it was supposed to contain jar
> > > files. Am I missing something?
> > >
> > > Thanks.
> > >
> > > --
> > > Chris Baumgartner
> > > Java Software Developer
> > > FUJIFILM Medical Systems U.S.A., Inc.
> > > TeraMedica Division
> > > 10400 Innovation Drive, Suite 200
> > > Milwaukee, WI 53226
> > > Office: (414) 908-7724
> > > www.teramedica.com
> > >
> > > *Helping provide healthcare experiences that enhance the quality of
> > life. *
> > >
> > > --
> > > NOTICE: This message, including any attachments, is only for the use of
> > the
> > > intended recipient(s) and may contain confidential and privileged
> > > information, or information otherwise protected from disclosure by law.
> > If
> > > the reader of this message is not the intended recipient, you are
> hereby
> > > notified that any use, disclosure, copying, dissemination or
> distribution
> > > of this message or any of its attachments is strictly prohibited.  If
> you
> > > received this message in error, please contact the sender immediately
> by
> > > reply email and destroy this message, including all attachments, and
> any
> > > copies thereof.
> > >
> >
>

Re: No jars in distribution-full-1.7.1.zip?

[John D. Ament]

Definitely supposed to be there.  Looks like an issue w/ 1.7.0 and 1.6.1 as
well (probably earlier).  Give me some time to take a look, but for now
could you download the JARs via maven?

John

On Tue, Aug 16, 2016 at 9:09 AM Chris Baumgartner <
chris.baumgart...@fujifilm.com> wrote:

> Hello,
>
> I'm trying to download the full distribution of Deltaspike 1.7.1.
>
> When I unzip the file, there are no jar files in it.
>
> The directory structure is:
>
> cdictrl
> - module.xml
> core
> - module.xml
> modules
> - module.xml
> LICENSE
> NOTICE
> README.md
>
> That's all that is in the zip. I thought it was supposed to contain jar
> files. Am I missing something?
>
> Thanks.
>
> --
> Chris Baumgartner
> Java Software Developer
> FUJIFILM Medical Systems U.S.A., Inc.
> TeraMedica Division
> 10400 Innovation Drive, Suite 200
> Milwaukee, WI 53226
> Office: (414) 908-7724
> www.teramedica.com
>
> *Helping provide healthcare experiences that enhance the quality of life. *
>
> --
> NOTICE: This message, including any attachments, is only for the use of the
> intended recipient(s) and may contain confidential and privileged
> information, or information otherwise protected from disclosure by law.  If
> the reader of this message is not the intended recipient, you are hereby
> notified that any use, disclosure, copying, dissemination or distribution
> of this message or any of its attachments is strictly prohibited.  If you
> received this message in error, please contact the sender immediately by
> reply email and destroy this message, including all attachments, and any
> copies thereof.
>

Re: Too many Warnings using deltaspike 1.7.1

[John D. Ament]

Rodrigo,

Could you paste your warnings?

John

On Mon, Aug 15, 2016 at 2:53 PM rodrigotessarollone...@gmail.com <
rodrigotessarollone...@gmail.com> wrote:

>
>
> On 2016-08-14 20:26 (-0300), "John D. Ament" 
> wrote:
> > The warnings seem to be caused by a change I put in heading to 1.7.0 to
> > break down the large interface of EntityRepository into more components
> > (mostly to make it easier to leverages parts of it when using a Java 8
> > based repository).  For some reason, even though EntityRepository brings
> > the other two in, Weld didn't like it and wanted me to directly inherit
> > those interfaces.  I've pinged the weld guys to see why.
> >
> > There's a fix in master, and I think you can work around it in your
> > repository by directly implementing the new interfaces
> > (EntityCountRepository, EntityPersistenceRepository).
> >
> > John
> >
> > On Sun, Aug 14, 2016 at 5:38 PM John D. Ament 
> wrote:
> >
> > > Just created: https://issues.apache.org/jira/browse/DELTASPIKE-1192
> > >
> > > I just noticed this as well, and was going to ask my scrum team why
> > > increased the logs :-)
> > >
> > > John
> > >
> > >
> > > On Sun, Aug 14, 2016 at 3:23 AM  wrote:
> > >
> > >> Same here. It started from 1.7.0. Before was ok.
> > >>
> > >> Paweł
> > >>
> > >>
> > >>
> > >> Od: Rodrigo Tessarollo 
> > >> Do: users@deltaspike.apache.org
> > >> Data:   2016-08-14 08:40
> > >> Temat:  Too many Warnings using deltaspike 1.7.1
> > >>
> > >>
> > >>
> > >> Hi, I'm facing of a annoyning issue when using deltaspike on wildfly
> 10.
> > >>
> > >> The console outputs too many warning messages like this:
> > >>
> > >> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
> > >> WELD-001117: Member refresh
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1030b45
> > >> )
> > >> does not belong to the actual class hierarchy of the annotatedType
> > >> org.apache.deltaspike.data.api.AbstractEntityRepository
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> > >> )
> > >> at
> > >>
> > >>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
> > >>   StackTrace:
> > >> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
> > >> WELD-001117: Member saveAndFlush
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1d249da
> > >> )
> > >> does not belong to the actual class hierarchy of the annotatedType
> > >> org.apache.deltaspike.data.api.AbstractEntityRepository
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> > >> )
> > >>
> > >> N other wanings ...
> > >>
> > >>
> > >> The warnigs above is about the EntityPersistenceRepository, but the
> same
> > >> occurs on my own repositories too, look:
> > >>
> > >>
> > >> 03:14:48,475 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
> > >> WELD-001117: Member attachAndRemove
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1859a46
> > >> )
> > >> does not belong to the actual class hierarchy of the annotatedType
> > >> myapp.atendimento.repository.UFRepository
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
> > >> )
> > >> at
> > >>
> > >>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.attachAndRemove(EntityPersistenceRepository.java:0)
> > >>   StackTrace:
> > >> 03:14:48,476 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
> > >> WELD-001117: Member refresh
> > >>
> > >>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1f7dc7f
> > >> )
> > >> does not belong to the actual class hierarchy of the annotatedType
> > >> myapp.atendimento.repository.UFRepository
> > >>
> (org.apache.deltaspike.core.util.metadat

Re: Too many Warnings using deltaspike 1.7.1

[John D. Ament]

The Weld guys are calling it a bug on their side.  Unfortunately they're
fixing it for 2.4 and above, so I'll update the docs with some clearer
information about the work around.

https://issues.jboss.org/browse/WELD-2221

John

On Sun, Aug 14, 2016 at 7:26 PM John D. Ament  wrote:

> The warnings seem to be caused by a change I put in heading to 1.7.0 to
> break down the large interface of EntityRepository into more components
> (mostly to make it easier to leverages parts of it when using a Java 8
> based repository).  For some reason, even though EntityRepository brings
> the other two in, Weld didn't like it and wanted me to directly inherit
> those interfaces.  I've pinged the weld guys to see why.
>
> There's a fix in master, and I think you can work around it in your
> repository by directly implementing the new interfaces
> (EntityCountRepository, EntityPersistenceRepository).
>
> John
>
>
> On Sun, Aug 14, 2016 at 5:38 PM John D. Ament 
> wrote:
>
>> Just created: https://issues.apache.org/jira/browse/DELTASPIKE-1192
>>
>> I just noticed this as well, and was going to ask my scrum team why
>> increased the logs :-)
>>
>> John
>>
>>
>> On Sun, Aug 14, 2016 at 3:23 AM  wrote:
>>
>>> Same here. It started from 1.7.0. Before was ok.
>>>
>>> Paweł
>>>
>>>
>>>
>>> Od: Rodrigo Tessarollo 
>>> Do: users@deltaspike.apache.org
>>> Data:   2016-08-14 08:40
>>> Temat:  Too many Warnings using deltaspike 1.7.1
>>>
>>>
>>>
>>> Hi, I'm facing of a annoyning issue when using deltaspike on wildfly 10.
>>>
>>> The console outputs too many warning messages like this:
>>>
>>> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
>>> WELD-001117: Member refresh
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1030b45
>>> )
>>> does not belong to the actual class hierarchy of the annotatedType
>>> org.apache.deltaspike.data.api.AbstractEntityRepository
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
>>> )
>>> at
>>>
>>> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>>>   StackTrace:
>>> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
>>> WELD-001117: Member saveAndFlush
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1d249da
>>> )
>>> does not belong to the actual class hierarchy of the annotatedType
>>> org.apache.deltaspike.data.api.AbstractEntityRepository
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
>>> )
>>>
>>> N other wanings ...
>>>
>>>
>>> The warnigs above is about the EntityPersistenceRepository, but the same
>>> occurs on my own repositories too, look:
>>>
>>>
>>> 03:14:48,475 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>>> WELD-001117: Member attachAndRemove
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1859a46
>>> )
>>> does not belong to the actual class hierarchy of the annotatedType
>>> myapp.atendimento.repository.UFRepository
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
>>> )
>>> at
>>>
>>> org.apache.deltaspike.data.api.EntityPersistenceRepository.attachAndRemove(EntityPersistenceRepository.java:0)
>>>   StackTrace:
>>> 03:14:48,476 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>>> WELD-001117: Member refresh
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1f7dc7f
>>> )
>>> does not belong to the actual class hierarchy of the annotatedType
>>> myapp.atendimento.repository.UFRepository
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
>>> )
>>> at
>>>
>>> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>>>   StackTrace:
>>> 03:14:48,477 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>>> WELD-001117: Member remove
>>>
>>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1ce88c3
>>> )
>>> does not belong to the actual class hierarchy of the annotatedTyp

Re: Too many Warnings using deltaspike 1.7.1

[John D. Ament]

The warnings seem to be caused by a change I put in heading to 1.7.0 to
break down the large interface of EntityRepository into more components
(mostly to make it easier to leverages parts of it when using a Java 8
based repository).  For some reason, even though EntityRepository brings
the other two in, Weld didn't like it and wanted me to directly inherit
those interfaces.  I've pinged the weld guys to see why.

There's a fix in master, and I think you can work around it in your
repository by directly implementing the new interfaces
(EntityCountRepository, EntityPersistenceRepository).

John

On Sun, Aug 14, 2016 at 5:38 PM John D. Ament  wrote:

> Just created: https://issues.apache.org/jira/browse/DELTASPIKE-1192
>
> I just noticed this as well, and was going to ask my scrum team why
> increased the logs :-)
>
> John
>
>
> On Sun, Aug 14, 2016 at 3:23 AM  wrote:
>
>> Same here. It started from 1.7.0. Before was ok.
>>
>> Paweł
>>
>>
>>
>> Od: Rodrigo Tessarollo 
>> Do: users@deltaspike.apache.org
>> Data:   2016-08-14 08:40
>> Temat:  Too many Warnings using deltaspike 1.7.1
>>
>>
>>
>> Hi, I'm facing of a annoyning issue when using deltaspike on wildfly 10.
>>
>> The console outputs too many warning messages like this:
>>
>> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
>> WELD-001117: Member refresh
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1030b45
>> )
>> does not belong to the actual class hierarchy of the annotatedType
>> org.apache.deltaspike.data.api.AbstractEntityRepository
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
>> )
>> at
>>
>> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>>   StackTrace:
>> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
>> WELD-001117: Member saveAndFlush
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1d249da
>> )
>> does not belong to the actual class hierarchy of the annotatedType
>> org.apache.deltaspike.data.api.AbstractEntityRepository
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
>> )
>>
>> N other wanings ...
>>
>>
>> The warnigs above is about the EntityPersistenceRepository, but the same
>> occurs on my own repositories too, look:
>>
>>
>> 03:14:48,475 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>> WELD-001117: Member attachAndRemove
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1859a46
>> )
>> does not belong to the actual class hierarchy of the annotatedType
>> myapp.atendimento.repository.UFRepository
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
>> )
>> at
>>
>> org.apache.deltaspike.data.api.EntityPersistenceRepository.attachAndRemove(EntityPersistenceRepository.java:0)
>>   StackTrace:
>> 03:14:48,476 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>> WELD-001117: Member refresh
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1f7dc7f
>> )
>> does not belong to the actual class hierarchy of the annotatedType
>> myapp.atendimento.repository.UFRepository
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
>> )
>> at
>>
>> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>>   StackTrace:
>> 03:14:48,477 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
>> WELD-001117: Member remove
>>
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1ce88c3
>> )
>> does not belong to the actual class hierarchy of the annotatedType
>> myapp.atendimento.repository.UFRepository
>> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
>> )
>> at
>>
>> org.apache.deltaspike.data.api.EntityPersistenceRepository.remove(EntityPersistenceRepository.java:0)
>>
>>
>> My repositories looks like:
>>
>> @Repository
>> public abstract class UFRepository
>> extends AbstractEntityRepository {
>> }
>>
>>
>> if I change way of repository declaring (using interfaces instead abstract
>> classes) the warning disapear, but in some situations I need to build a
>> query using the method body, in this cases, only abstract classes can do
>> this.
>>
>> @Repository
>> public interface UFRepository
>> extends EntityRepository {
>> }
>>
>> ^ This works great, but no method bodies to write sql.
>>
>> Can someone help me? Thanks and sorry for the poor english. ;D
>>
>>

Re: Too many Warnings using deltaspike 1.7.1

[John D. Ament]

Just created: https://issues.apache.org/jira/browse/DELTASPIKE-1192

I just noticed this as well, and was going to ask my scrum team why
increased the logs :-)

John

On Sun, Aug 14, 2016 at 3:23 AM  wrote:

> Same here. It started from 1.7.0. Before was ok.
>
> Paweł
>
>
>
> Od: Rodrigo Tessarollo 
> Do: users@deltaspike.apache.org
> Data:   2016-08-14 08:40
> Temat:  Too many Warnings using deltaspike 1.7.1
>
>
>
> Hi, I'm facing of a annoyning issue when using deltaspike on wildfly 10.
>
> The console outputs too many warning messages like this:
>
> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
> WELD-001117: Member refresh
>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1030b45
> )
> does not belong to the actual class hierarchy of the annotatedType
> org.apache.deltaspike.data.api.AbstractEntityRepository
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> )
> at
>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>   StackTrace:
> 03:07:12,809 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-5)
> WELD-001117: Member saveAndFlush
>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1d249da
> )
> does not belong to the actual class hierarchy of the annotatedType
> org.apache.deltaspike.data.api.AbstractEntityRepository
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@1b91ea9
> )
>
> N other wanings ...
>
>
> The warnigs above is about the EntityPersistenceRepository, but the same
> occurs on my own repositories too, look:
>
>
> 03:14:48,475 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
> WELD-001117: Member attachAndRemove
>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1859a46
> )
> does not belong to the actual class hierarchy of the annotatedType
> myapp.atendimento.repository.UFRepository
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
> )
> at
>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.attachAndRemove(EntityPersistenceRepository.java:0)
>   StackTrace:
> 03:14:48,476 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
> WELD-001117: Member refresh
>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1f7dc7f
> )
> does not belong to the actual class hierarchy of the annotatedType
> myapp.atendimento.repository.UFRepository
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
> )
> at
>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.refresh(EntityPersistenceRepository.java:0)
>   StackTrace:
> 03:14:48,477 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-2)
> WELD-001117: Member remove
>
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedMethodImpl@1ce88c3
> )
> does not belong to the actual class hierarchy of the annotatedType
> myapp.atendimento.repository.UFRepository
> (org.apache.deltaspike.core.util.metadata.builder.AnnotatedTypeImpl@aa0c91
> )
> at
>
> org.apache.deltaspike.data.api.EntityPersistenceRepository.remove(EntityPersistenceRepository.java:0)
>
>
> My repositories looks like:
>
> @Repository
> public abstract class UFRepository
> extends AbstractEntityRepository {
> }
>
>
> if I change way of repository declaring (using interfaces instead abstract
> classes) the warning disapear, but in some situations I need to build a
> query using the method body, in this cases, only abstract classes can do
> this.
>
> @Repository
> public interface UFRepository
> extends EntityRepository {
> }
>
> ^ This works great, but no method bodies to write sql.
>
> Can someone help me? Thanks and sorry for the poor english. ;D
>
>

Re: Re: access DeltaSpike Data repository as EJB

[John D. Ament]

Agreed.  If you need transactions, you should be able to use our
@Transactional interceptor.  If you're trying to use a distributed
architecture using remote EJBs, I would recommend putting facades in front,
but maybe ideally expose a REST API instead?

John

On Wed, Aug 3, 2016 at 8:27 AM Rafael Pestano  wrote:

> Hi Paweł,
>
> just a 'dumb' question: does it needs to be an EJB? this information you
> need can't be exposed as a REST service? I'm saying that because I've been
> there and migrate lots of ears to wars and ejb modules to rest
> service...maybe it apples for your case too.
>
> 2016-08-03 9:21 GMT-03:00 :
>
> > Hi John,
> >
> > It works as you said. I don't know how since it is in separate EJB module
> > but it works :)
> >
> > Just in case if the JPA / DeltaSpike module is in separate Server/JVM
> then
> > how to access the repositories as EJB ?
> >
> > best regards
> > Paweł
> >
> >
> >
> > Od: "John D. Ament" 
> > Do: users@deltaspike.apache.org
> > Data:   2016-08-03 13:01
> > Temat:  Re: access DeltaSpike Data repository as EJB
> >
> >
> >
> > Hi Pawel,
> >
> > Creating them as EJBs shouldn't be required.  They're still CDI beans.
> In
> > the JAR that you expose, make sure the various deltaspike extensions are
> > activated in your javax.enterprise.inject.spi.Extension file.  Make sure
> > you have a valid beans.xml to discover all beans.
> >
> > At a minimum you need the repository extension and bean provider.  You
> > should then be able to inject them.  Please do post back if this gives
> you
> > some trouble, happy to help.
> >
> > John
> >
> > On Wed, Aug 3, 2016 at 6:50 AM  wrote:
> >
> > > Need to move my JPA and DeltaSpike repositories to EJB EAR module to
> > allow
> > > access from two different WARs in the same EAR
> > >
> > > What is recommnded approach to access DeltaSpike repository as EJB ?
> > >
> > > For adhoc I created PersonService class annotated with @Stateless
> > >
> > > @Stateless
> > > public class PersonService {
> > >
> > > @Inject PersonRepository personRepository;
> > >
> > > public PersonRepository getRepository(){
> > > return personRepository;
> > > }
> > > }
> > >
> > > Do you have some other ideas ?
> > >
> > > Paweł
> >
> >
>
>
> --
> Att,
>
> Rafael M. Pestano
>
> Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
> http://rpestano.wordpress.com/
> @realpestano
>

Re: access DeltaSpike Data repository as EJB

[John D. Ament]

Hi Pawel,

Creating them as EJBs shouldn't be required.  They're still CDI beans.  In
the JAR that you expose, make sure the various deltaspike extensions are
activated in your javax.enterprise.inject.spi.Extension file.  Make sure
you have a valid beans.xml to discover all beans.

At a minimum you need the repository extension and bean provider.  You
should then be able to inject them.  Please do post back if this gives you
some trouble, happy to help.

John

On Wed, Aug 3, 2016 at 6:50 AM  wrote:

> Need to move my JPA and DeltaSpike repositories to EJB EAR module to allow
> access from two different WARs in the same EAR
>
> What is recommnded approach to access DeltaSpike repository as EJB ?
>
> For adhoc I created PersonService class annotated with @Stateless
>
> @Stateless
> public class PersonService {
>
> @Inject PersonRepository personRepository;
>
> public PersonRepository getRepository(){
> return personRepository;
> }
> }
>
> Do you have some other ideas ?
>
> Paweł

Re: Advice on accessing @RequestScoped bean in service thread

[John D. Ament]

This sounds like something useful and reusable, would it help if we
provided websockets support OOTB?

On Jul 21, 2016 14:11, "Ludovic Pénet"  wrote:

> Ok, found it
>
> On https://deltaspike.apache.org/documentation/container-control.html
>
> Read "Attach a RequestContext to a New Thread in EE".
>
> I think I will write an interceptor to make it even easier to use.
>
> Thanks !
>
> Le 21 juillet 2016 19:35:44 GMT+02:00, "l.pe...@senat.fr" <
> l.pe...@senat.fr> a écrit :
> >On 21/07/2016 19:20, John D. Ament wrote:
> >> Ludovic,
> >>
> >> Are you using context control to start a request context on the
> >websockets
> >> thread?
> >No.
> >
> >But if that's your recommendation, I can do that.
> >
> >Where do I find it in the doc ?
> >
> >Thank you !
> >
> >Ludovic
> >
> >|
> >| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> >|
>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: Advice on accessing @RequestScoped bean in service thread

[John D. Ament]

Ludovic,

Are you using context control to start a request context on the websockets
thread?

On Jul 21, 2016 13:16, "l.pe...@senat.fr"  wrote:

> Hi.
>
> I am looking for an advice on how to acces a request scoped bean in a
> service thread. My current need is in a web socket service thread, but it
> could be any background thread.
>
> The bean I need to access is a data access bean, which will itself request
> injection of an entity manager to perform various operations. It does in
> fact nothing related to the HTTP session, but I want to be sure that every
> requests gets a clean bean.
>
> How do you recommend to do that ? If I boldly try to une
> BeanProvider.getContextualInstance(), it does not work as there is, of
> course, no request scope. Should I start a pseudo request scope ? Is there
> an annotation for that ?
>
> Thanks in advance,
>
> Ludovic
>
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>

[HELP WANTED] Documentation Enhancements for Apache DeltaSpike.

[John D. Ament]

All,

As everyone knows, documentation is key to making any project successful.
We have some gaps currently in our documentation that make using some of
the features of DeltaSpike a bit hard.  Therefore, I'm calling on the
broader community to help us address these documentation challenges by
improving our docs.

I've created a JIRA filter with our open documentation issues, which you
can find here: https://issues.apache.org/jira/issues/?filter=12338045

This list will grow.  It would be great to get some folks looking at it,
especially our end users, to give us feedback on what needs to improve or
even where they see fit patches for our docs.

In case you're not sure, you can make changes to our asciidoc files, from
our main git repo.  The website is at
https://github.com/apache/deltaspike/tree/master/site and our docs are at
https://github.com/apache/deltaspike/tree/master/documentation .  Please
feel free to submit patches, or raise PRs with a proposed fix.  Just make
sure to include a JIRA ticket in your commit.

Thanks,

John

[ANNOUNCE] Release of Apache DeltaSpike 1.7.1

[John D. Ament]

The Apache DeltaSpike team is pleased to announce the 27th release of
DeltaSpike.

Apache DeltaSpike is  a suite of portable CDI (Contexts & Dependency
Injection) extensions intended to make application development easier when
working with CDI and Java EE.  Some of its key features include:

- A core runtime that supports component configuration, type safe messaging
and internationalization, and exception handling.
- A suite of utilities to make programmatic bean lookup easier.
- A plugin for Java SE to bootstrap both JBoss Weld and Apache OpenWebBeans
outside of a container.
- JSF integration, including backporting of JSF 2.2 features for Java EE 6.
- JPA integration and transaction support.
- A Data module, to create an easy to use repository pattern on top of JPA.
- Quartz integration

Testing support is also provided, to allow you to do low level unit testing
of your CDI enabled projects.

More can be found on our website - https://deltaspike.apache.org

Documentation:
https://deltaspike.apache.org/documentation/

Download:
https://deltaspike.apache.org/download.html

Release Notes:
http://s.apache.org/DeltaSpike_1.7.1

Enjoy!

John

Result (was Re: [VOTE] Release of Apache DeltaSpike 1.7.1)

[John D. Ament]

All,

Thank you for reviewing the release and voting

3 binding +1 votes (pmc):
Romain Manni-Bucau, Jason Porter and John Ament

0 non-binding +1 votes:

0 -1 votes

As a result, the vote passes.  I'll continue the release steps.

John

On Sun, Jul 17, 2016 at 12:29 PM John D. Ament 
wrote:

> Hi,
>
> I was running the needed tasks to get the 1.7.1 release of Apache
> DeltaSpike out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and will get pushed to the ASF repository once
> the vote passed.
>
> Please take a look at the 1.7.1 release artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see
> [4]).
>
> Users:
> The release notes can be found at [5].  In addition, you are strongly
> encouraged to test your apps against the proposed release.
>
> PS: Special thanks for some of the external contributors on this
> release: Valentin Maechler, Tibor Digana, Xavier Dury, and Ivan Junckes
> Filho - remember, we can't do this without a community of contributors!
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
> and why..
> 
>
> Thanks,
> John
>
> [1]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/
> [2]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/org/apache/deltaspike/deltaspike/1.7.1/deltaspike-1.7.1-source-release.zip
> [3] https://github.com/johnament/deltaspike/tree/ds-1.7.1
> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [5] http://s.apache.org/DeltaSpike_1.7.1
>

Re: CriteriaSupport Injection

[John D. Ament]

I was actually just about to respond with "not sure it makes sense".

The reason being, we rely on an entity manager resolver in data to
determine which EM the repository is associated with. You would have no way
to differentiate criteria supports per EM as a result.

Plus its always better to put your DB logic in your DB tier.

John

On Tue, Jul 19, 2016 at 7:10 AM Rafael Pestano  wrote:

> Answering myself, Its possible (by extending CriteriaSupportHandler) but
> not worth, better stick with  inheritance with current api(which is great).
>
> Em seg, 18 de jul de 2016 11:28, Rafael Pestano 
> escreveu:
>
> > Hi guys,
> >
> > For sake of simplicity, I'd like to use the following construct:
> >
> > @Inject
> > CriteriaSupport entityCriteria;
> >
> >
> > Is it possible? does it make sense for you?
> >
> > We already do that (generic query execution) with EntityManager itself
> but
> > there is no criteria support.
> >
> > thanks in advance.
> >
> >
> >
> > --
> > Att,
> >
> > Rafael M. Pestano
> >
> > Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
> > http://rpestano.wordpress.com/
> > @realpestano
> >
>

Re: [VOTE] Release of Apache DeltaSpike 1.7.1

[John D. Ament]

Before I forget here's my +1

On Jul 18, 2016 12:13 PM, "Jason Porter"  wrote:

> +1
>
> On Mon, Jul 18, 2016 at 8:52 AM, Romain Manni-Bucau  >
> wrote:
>
> > +1
> >
> > Le 17 juil. 2016 18:29, "John D. Ament"  a écrit
> :
> >
> > > Hi,
> > >
> > > I was running the needed tasks to get the 1.7.1 release of Apache
> > > DeltaSpike out.
> > > The artifacts are deployed to Nexus [1] (and [2]).
> > >
> > > The tag is available at [3] and will get pushed to the ASF repository
> > once
> > > the vote passed.
> > >
> > > Please take a look at the 1.7.1 release artifacts and vote!
> > >
> > > Please note:
> > > This vote is "majority approval" with a minimum of three +1 votes (see
> > > [4]).
> > >
> > > Users:
> > > The release notes can be found at [5].  In addition, you are strongly
> > > encouraged to test your apps against the proposed release.
> > >
> > > PS: Special thanks for some of the external contributors on this
> > > release: Valentin Maechler, Tibor Digana, Xavier Dury, and Ivan Junckes
> > > Filho - remember, we can't do this without a community of contributors!
> > >
> > > 
> > > [ ] +1 for community members who have reviewed the bits
> > > [ ] +0
> > > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > and
> > > why..
> > > 
> > >
> > > Thanks,
> > > John
> > >
> > > [1]
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/
> > > [2]
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/org/apache/deltaspike/deltaspike/1.7.1/deltaspike-1.7.1-source-release.zip
> > > [3] https://github.com/johnament/deltaspike/tree/ds-1.7.1
> > > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > > [5] http://s.apache.org/DeltaSpike_1.7.1
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

[VOTE] Release of Apache DeltaSpike 1.7.1

[John D. Ament]

Hi,

I was running the needed tasks to get the 1.7.1 release of Apache
DeltaSpike out.
The artifacts are deployed to Nexus [1] (and [2]).

The tag is available at [3] and will get pushed to the ASF repository once
the vote passed.

Please take a look at the 1.7.1 release artifacts and vote!

Please note:
This vote is "majority approval" with a minimum of three +1 votes (see [4]).

Users:
The release notes can be found at [5].  In addition, you are strongly
encouraged to test your apps against the proposed release.

PS: Special thanks for some of the external contributors on this
release: Valentin Maechler, Tibor Digana, Xavier Dury, and Ivan Junckes
Filho - remember, we can't do this without a community of contributors!


[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released, and
why..


Thanks,
John

[1]
https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/
[2]
https://repository.apache.org/content/repositories/orgapachedeltaspike-1039/org/apache/deltaspike/deltaspike/1.7.1/deltaspike-1.7.1-source-release.zip
[3] https://github.com/johnament/deltaspike/tree/ds-1.7.1
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes
[5] http://s.apache.org/DeltaSpike_1.7.1

[DISCUSS] New Announcement Text

[John D. Ament]

All,

during our last release, it was noted that our announcement template was
kind of bland, didn't give people much info about DeltaSpike.  You can see
the current version here:
https://github.com/apache/deltaspike/blame/master/site/src/main/asciidoc/steps_for_a_release.adoc#L211
(apologies
for linking to the blame, github is converting it to preview mode... :-( )

Anyways, I wanted to propose using this text in the template instead, to
give a broader feel for our feature set:

Apache DeltaSpike is  a suite of portable CDI extensions intended to make
application development easier when working with CDI and Java EE.  Some of
its key features include:

- A core runtime that supports component configuration, type safe messaging
and internatlization, and exception handling.
- A suite of utilities to make programmatic bean lookup easier.
- A plugin for Java SE to bootstrap both JBoss Weld and Apache OpenWebBeans
outside of a container.
- JSF integration, including backporting of JSF 2.2 features for Java EE 6.
- JPA integration and transaction support.
- A Data module, to create an easy to use repository pattern on top of JPA.
- Quartz integration

Testing support is also provided, to allow you to do low level unit testing
of your CDI enabled projects.

More can be found on our website - https://deltaspike.apache.org

WDYT?

John

1.7.1 Release

[John D. Ament]

All,

So we had some last minute issues pop up but I think its still important we
aim to get a 1.7.1 out with the bug fixes included.

Proposed release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820&version=12335497

As a result, I'd like to plan to cut the release Sunday evening, starting
the vote either then or Monday morning.

John

Re: NPE in AbstractManualInvocationHandler

[John D. Ament]

Great news, thanks!

John

On Thu, Jul 14, 2016 at 3:32 AM Xavier Dury  wrote:

> Hi John,
>
> I tested the fix and I didn't get the problem anymore.
>
> Thanks,
>
> Xavier
>
> 
> > From: johndam...@apache.org
> > Date: Wed, 13 Jul 2016 23:52:19 +
> > Subject: Re: NPE in AbstractManualInvocationHandler
> > To: users@deltaspike.apache.org
> >
> > Xavier,
> >
> > I just pushed up a fix. Can you check out, rebuild and see if it fixes
> the
> > issue for you? The error was pretty quick to reproduce with your test.
> >
> > John
> >
> > On Wed, Jul 13, 2016 at 11:25 AM John D. Ament 
> > wrote:
> >
> >> Thanks, I put in https://issues.apache.org/jira/browse/DELTASPIKE-1183
> >>
> >> I'll port your test over to create a reproducible test as a part of
> this.
> >> Thanks for not using data in the test, since yes the issue is in partial
> >> bean/proxy.
> >>
> >> John
> >>
> >>
> >> On Wed, Jul 13, 2016 at 11:20 AM Xavier Dury 
> wrote:
> >>
> >>> Here is a reproducible test (I am using ApplicationComposer from
> TomEE),
> >>> I replaced the repository by some other partial bean to simplify.
> >>>
> >>> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> >>> import static java.util.concurrent.TimeUnit.SECONDS;
> >>>
> >>> import java.lang.annotation.Retention;
> >>> import java.lang.reflect.InvocationHandler;
> >>> import java.lang.reflect.Method;
> >>> import java.util.ArrayList;
> >>> import java.util.List;
> >>> import java.util.concurrent.ExecutorService;
> >>> import java.util.concurrent.Future;
> >>> import java.util.concurrent.RejectedExecutionHandler;
> >>> import java.util.concurrent.SynchronousQueue;
> >>> import java.util.concurrent.ThreadPoolExecutor;
> >>>
> >>> import javax.annotation.Resource;
> >>> import javax.enterprise.concurrent.ManagedThreadFactory;
> >>> import javax.inject.Inject;
> >>>
> >>> import org.apache.deltaspike.core.api.provider.BeanManagerProvider;
> >>> import org.apache.deltaspike.partialbean.api.PartialBeanBinding;
> >>> import
> org.apache.deltaspike.partialbean.impl.PartialBeanBindingExtension;
> >>> import
> >>>
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler;
> >>> import org.apache.deltaspike.proxy.impl.invocation.InterceptorLookup;
> >>> import org.apache.openejb.junit.ApplicationComposerRule;
> >>> import org.apache.openejb.testing.CdiExtensions;
> >>> import org.apache.openejb.testing.Module;
> >>> import org.junit.Rule;
> >>> import org.junit.Test;
> >>> import org.junit.rules.TestRule;
> >>>
> >>> public @CdiExtensions({BeanManagerProvider.class,
> >>> PartialBeanBindingExtension.class}) class ConcurrencyBugTest {
> >>>
> >>> public final @Rule TestRule composer = new
> >>> ApplicationComposerRule(this);
> >>>
> >>> public @PartialBeanBinding @Retention(RUNTIME) @interface
> >>> MyPartialBeanBinding {
> >>> }
> >>>
> >>> public @MyPartialBeanBinding interface PartialBean {
> >>>
> >>> String getValue();
> >>> }
> >>>
> >>> public static @MyPartialBeanBinding class MyPartialBeanHandler
> >>> implements InvocationHandler {
> >>>
> >>> public Object invoke(Object proxy, Method method, Object[] args)
> >>> throws Throwable {
> >>> return method.getName();
> >>> }
> >>> }
> >>>
> >>> private class BlockPolicy implements RejectedExecutionHandler {
> >>>
> >>> public @Override void rejectedExecution(Runnable runnable,
> >>> ThreadPoolExecutor executor) {
> >>> try {
> >>> executor.getQueue().put(runnable);
> >>> } catch (InterruptedException interruptedException) {
> >>> Thread.currentThread().interrupt();
> >>> }
> >>> }
> >>> }
> >>>
> >>> public @Module Class[] classes() {
> >>> return new Class[] { DelegateManualInvocationHandler.class,
> >>> InterceptorLookup.class, PartialBean.class, MyPartialBeanHandler.class,
> >>> MyPartialBeanHandler.class };
> >>> }
> &

Re: NPE in AbstractManualInvocationHandler

[John D. Ament]

Xavier,

I just pushed up a fix.  Can you check out, rebuild and see if it fixes the
issue for you?  The error was pretty quick to reproduce with your test.

John

On Wed, Jul 13, 2016 at 11:25 AM John D. Ament 
wrote:

> Thanks, I put in https://issues.apache.org/jira/browse/DELTASPIKE-1183
>
> I'll port your test over to create a reproducible test as a part of this.
> Thanks for not using data in the test, since yes the issue is in partial
> bean/proxy.
>
> John
>
>
> On Wed, Jul 13, 2016 at 11:20 AM Xavier Dury  wrote:
>
>> Here is a reproducible test (I am using ApplicationComposer from TomEE),
>> I replaced the repository by some other partial bean to simplify.
>>
>> import static java.lang.annotation.RetentionPolicy.RUNTIME;
>> import static java.util.concurrent.TimeUnit.SECONDS;
>>
>> import java.lang.annotation.Retention;
>> import java.lang.reflect.InvocationHandler;
>> import java.lang.reflect.Method;
>> import java.util.ArrayList;
>> import java.util.List;
>> import java.util.concurrent.ExecutorService;
>> import java.util.concurrent.Future;
>> import java.util.concurrent.RejectedExecutionHandler;
>> import java.util.concurrent.SynchronousQueue;
>> import java.util.concurrent.ThreadPoolExecutor;
>>
>> import javax.annotation.Resource;
>> import javax.enterprise.concurrent.ManagedThreadFactory;
>> import javax.inject.Inject;
>>
>> import org.apache.deltaspike.core.api.provider.BeanManagerProvider;
>> import org.apache.deltaspike.partialbean.api.PartialBeanBinding;
>> import org.apache.deltaspike.partialbean.impl.PartialBeanBindingExtension;
>> import
>> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler;
>> import org.apache.deltaspike.proxy.impl.invocation.InterceptorLookup;
>> import org.apache.openejb.junit.ApplicationComposerRule;
>> import org.apache.openejb.testing.CdiExtensions;
>> import org.apache.openejb.testing.Module;
>> import org.junit.Rule;
>> import org.junit.Test;
>> import org.junit.rules.TestRule;
>>
>> public @CdiExtensions({BeanManagerProvider.class,
>> PartialBeanBindingExtension.class}) class ConcurrencyBugTest {
>>
>> public final @Rule TestRule composer = new
>> ApplicationComposerRule(this);
>>
>> public @PartialBeanBinding @Retention(RUNTIME) @interface
>> MyPartialBeanBinding {
>> }
>>
>> public @MyPartialBeanBinding interface PartialBean {
>>
>> String getValue();
>> }
>>
>> public static @MyPartialBeanBinding class MyPartialBeanHandler
>> implements InvocationHandler {
>>
>> public Object invoke(Object proxy, Method method, Object[] args)
>> throws Throwable {
>> return method.getName();
>> }
>> }
>>
>> private class BlockPolicy implements RejectedExecutionHandler {
>>
>> public @Override void rejectedExecution(Runnable runnable,
>> ThreadPoolExecutor executor) {
>> try {
>> executor.getQueue().put(runnable);
>> } catch (InterruptedException interruptedException) {
>> Thread.currentThread().interrupt();
>> }
>> }
>> }
>>
>> public @Module Class[] classes() {
>> return new Class[] { DelegateManualInvocationHandler.class,
>> InterceptorLookup.class, PartialBean.class, MyPartialBeanHandler.class,
>> MyPartialBeanHandler.class };
>> }
>>
>> private @Resource ManagedThreadFactory threadFactory;
>> private @Inject PartialBean bean;
>>
>> public @Test void test() throws Exception {
>> ExecutorService executor = new ThreadPoolExecutor(5, 10, 60,
>> SECONDS, new SynchronousQueue<>(), this.threadFactory, new BlockPolicy());
>> List> results = new ArrayList<>(100);
>> for (int i = 0; i < 100; i++) {
>> results.add(executor.submit(this.bean::getValue));
>> }
>> executor.shutdown();
>> executor.awaitTermination(60, SECONDS);
>> for (int i = 0; i < 100; i++) {
>> results.get(i).get();
>> }
>> }
>> }
>>
>>
>> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>> at java.util.concurrent.FutureTask.report(Unknown Source)
>> at java.util.concurrent.FutureTask.get(Unknown Source)
>> at
>> be.fgov.sfpd.attestation.ConcurrencyBugTest.test(ConcurrencyBugTest.java:79)
>>

Re: NPE in AbstractManualInvocationHandler

[John D. Ament]

Thanks, I put in https://issues.apache.org/jira/browse/DELTASPIKE-1183

I'll port your test over to create a reproducible test as a part of this.
Thanks for not using data in the test, since yes the issue is in partial
bean/proxy.

John

On Wed, Jul 13, 2016 at 11:20 AM Xavier Dury  wrote:

> Here is a reproducible test (I am using ApplicationComposer from TomEE), I
> replaced the repository by some other partial bean to simplify.
>
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> import static java.util.concurrent.TimeUnit.SECONDS;
>
> import java.lang.annotation.Retention;
> import java.lang.reflect.InvocationHandler;
> import java.lang.reflect.Method;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Future;
> import java.util.concurrent.RejectedExecutionHandler;
> import java.util.concurrent.SynchronousQueue;
> import java.util.concurrent.ThreadPoolExecutor;
>
> import javax.annotation.Resource;
> import javax.enterprise.concurrent.ManagedThreadFactory;
> import javax.inject.Inject;
>
> import org.apache.deltaspike.core.api.provider.BeanManagerProvider;
> import org.apache.deltaspike.partialbean.api.PartialBeanBinding;
> import org.apache.deltaspike.partialbean.impl.PartialBeanBindingExtension;
> import
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler;
> import org.apache.deltaspike.proxy.impl.invocation.InterceptorLookup;
> import org.apache.openejb.junit.ApplicationComposerRule;
> import org.apache.openejb.testing.CdiExtensions;
> import org.apache.openejb.testing.Module;
> import org.junit.Rule;
> import org.junit.Test;
> import org.junit.rules.TestRule;
>
> public @CdiExtensions({BeanManagerProvider.class,
> PartialBeanBindingExtension.class}) class ConcurrencyBugTest {
>
> public final @Rule TestRule composer = new
> ApplicationComposerRule(this);
>
> public @PartialBeanBinding @Retention(RUNTIME) @interface
> MyPartialBeanBinding {
> }
>
> public @MyPartialBeanBinding interface PartialBean {
>
> String getValue();
> }
>
> public static @MyPartialBeanBinding class MyPartialBeanHandler
> implements InvocationHandler {
>
> public Object invoke(Object proxy, Method method, Object[] args)
> throws Throwable {
> return method.getName();
> }
> }
>
> private class BlockPolicy implements RejectedExecutionHandler {
>
> public @Override void rejectedExecution(Runnable runnable,
> ThreadPoolExecutor executor) {
> try {
> executor.getQueue().put(runnable);
> } catch (InterruptedException interruptedException) {
> Thread.currentThread().interrupt();
> }
> }
> }
>
> public @Module Class[] classes() {
> return new Class[] { DelegateManualInvocationHandler.class,
> InterceptorLookup.class, PartialBean.class, MyPartialBeanHandler.class,
> MyPartialBeanHandler.class };
> }
>
> private @Resource ManagedThreadFactory threadFactory;
> private @Inject PartialBean bean;
>
> public @Test void test() throws Exception {
> ExecutorService executor = new ThreadPoolExecutor(5, 10, 60,
> SECONDS, new SynchronousQueue<>(), this.threadFactory, new BlockPolicy());
> List> results = new ArrayList<>(100);
> for (int i = 0; i < 100; i++) {
> results.add(executor.submit(this.bean::getValue));
> }
> executor.shutdown();
> executor.awaitTermination(60, SECONDS);
> for (int i = 0; i < 100; i++) {
> results.get(i).get();
> }
> }
> }
>
>
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(Unknown Source)
> at java.util.concurrent.FutureTask.get(Unknown Source)
> at
> be.fgov.sfpd.attestation.ConcurrencyBugTest.test(ConcurrencyBugTest.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.openejb.junit.DeployApplication$1.call(DeployApplication.java:44)
> at
> org.apache.openejb.junit.DeployApplication$1.call(DeployApplication.java:40)
> at
> org.apache.openejb.testing.ApplicationComposers.evaluate(ApplicationComposers.java:1067)
> at
> org.apache.openejb.junit.DeployApplication.evaluate(DeployApplication.java:40)
> at org.junit.rules.RunRules

Re: NPE in AbstractManualInvocationHandler

[John D. Ament]

Do you have a reproducible sequence or is it only under load? I think I
know the issue.  Also did you build 1.7.1 yourself or pointing to our
snapshots?

John

On Wed, Jul 13, 2016 at 10:41 AM Xavier Dury  wrote:

> Sorry,
>
> I spoke too soon, I still have the problem:
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:38)
> at
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/proxy/impl/invocation/DelegateManualInvocationHandler.java)
> at
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:40)
>
> Xavier
>
> 
> > From: kal...@hotmail.com
> > To: users@deltaspike.apache.org
> > Subject: RE: NPE in AbstractManualInvocationHandler
> > Date: Wed, 13 Jul 2016 16:36:18 +0200
> >
> > Hi,
> >
> > Indeed, 1.7.1-SNAPSHOT fixed my problem.
> >
> > Thanks,
> >
> > Xavier
> > 
> >> From: johndam...@apache.org
> >> Date: Wed, 13 Jul 2016 14:23:43 +
> >> Subject: Re: NPE in AbstractManualInvocationHandler
> >> To: users@deltaspike.apache.org
> >>
> >> Hi Xavier,
> >>
> >> Could you try with 1.7.1-snapshot? There was some weird static logic
> doing
> >> initialization which has been changed in the up coming 1.7.1
> >>
> >> John
> >>
> >> On Wed, Jul 13, 2016 at 9:49 AM Xavier Dury  wrote:
> >>
> >>> Hi,
> >>>
> >>> Since I upgraded to DeltaSpike 1.7.0 / TomEE 7.0.1, I get NPEs when
> >>> calling some repositories in a multi-threaded batch.
> >>>
> >>> Caused by: java.lang.NullPointerException
> >>> at
> >>>
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:40)
> >>> at
> >>>
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:39)
> >>>
> >>> That line contains the following code:
> >>>
> >>> List> interceptors = interceptorLookup.lookup(proxy,
> >>> method);
> >>>
> >>> So it seems that interceptorLookup was not initialized correctly.
> >>>
> >>> I see there is a double-check locking on a volatile Boolean for
> >>> initialization in that class... Wouldn't it be better if the locking
> >>> occurred on the interceptorLookup or if the interceptorLookup would
> also be
> >>> declared as volatile?
> >>>
> >>> Regards,
> >>>
> >>> Xavier
> >>>
> >
>

Re: NPE in AbstractManualInvocationHandler

[John D. Ament]

Hi Xavier,

Could you try with 1.7.1-snapshot?  There was some weird static logic doing
initialization which has been changed in the up coming 1.7.1

John

On Wed, Jul 13, 2016 at 9:49 AM Xavier Dury  wrote:

> Hi,
>
> Since I upgraded to DeltaSpike 1.7.0 / TomEE 7.0.1, I get NPEs when
> calling some repositories in a multi-threaded batch.
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:40)
> at
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:39)
>
> That line contains the following code:
>
> List> interceptors = interceptorLookup.lookup(proxy,
> method);
>
> So it seems that interceptorLookup was not initialized correctly.
>
> I see there is a double-check locking on a volatile Boolean for
> initialization in that class... Wouldn't it be better if the locking
> occurred on the interceptorLookup or if the interceptorLookup would also be
> declared as volatile?
>
> Regards,
>
> Xavier
>

Re: DeltaSpike x Payara App Server

[John D. Ament]

Can you provide us with your logs?  The regular JAR should worm fine since
it's ee7.
On Jul 5, 2016 11:34, "Edilmar LISTAS"  wrote:

> My actual environment is:
>
> - Glassfish 3.1.2.2
> - CDI Weld 1.1.8
> - DeltaSpike 1.6.0
> - JSF Mojarra javax.faces.jar 2.1.29
> - RichFaces 4.5.15
> - JPA 2
> - Hibernate 4.2.7
> - JasperReports 6.1.0
> - JDBC drivers Jaybird/Firebird and PostgreSQL
>
> Now, I have tried to change to:
>
> -* Payara 4.1.1 (Glassfish 4.1.1 clone)
> -* CDI Weld 2.3.2
> - DeltaSpike 1.6.0
> -* JSF Mojarra javax.faces.jar 2.2.13
> - RichFaces 4.5.15
> - JPA 2
> - Hibernate 4.2.7
> - JasperReports 6.1.0
> - JDBC drivers Jaybird/Firebird and PostgreSQL
>
> My webapp is JEE6, but Payara team said me it is fully compatible with
> JEE6/JEE7.
>
> I tried first with deltaspike-jsf-module-impl-ee6-1.6.0.jar (DS JEE6 jar
> file), but when I try to run, the first login page (with login/pass
> required="true" fields) doesn't work properly. I type the values for
> login/pass and JSF page arises an error message that fields login/pass are
> required, JSF native error, nothing is sent to server.
>
> After to change to deltaspike-jsf-module-impl-1.6.0.jar, the webapp
> arises many exceptions and doesn't run.
>
> Then, I think the right jar is the actual
> deltaspike-jsf-module-impl-ee6-1.6.0.jar. I don't know if the problem is
> with DS or other
> JSF specific configuration.
>
>
>

Re: Is it truly impossible to lookup @ViewScoped etc with BeanProvider?

[John D. Ament]

Karl,

Do you mean you're trying to maintain the state of the view scoped bean in
the async request?

John

On Tue, Jun 21, 2016 at 8:10 AM Karl Kildén  wrote:

> So it is impossible then :-)
>
> The problem is that several slow things needs to be done from a JSF Bean. I
> can't async it because the service the bean calls is @ViewAccessScoped and
> stateful.
>
> I have a Bean that I want to start the thread from the Bean it is not a
> problem but when I create a new thread this thread is also disconnected
> from my Bean and it fails to look it up...
>
> Will take me ages to fix this project properly so desperate times calls for
> strange hacks :-)
>
> On 21 June 2016 at 12:39, Thomas Andraschko 
> wrote:
>
> > BeanProvider should work fine with any scope.
> > Of course you can't receive a viewscoped bean from another
> thread/request.
> >
> > 2016-06-21 11:52 GMT+02:00 Karl Kildén :
> >
> > > I have a RequestScoped Bean that needs to split the workload basically
> > and
> > > the thread needs to lookup using the Bean that starts the thread so to
> > > speak...
> > >
> > > On 21 June 2016 at 11:24, Karl Kildén  wrote:
> > >
> > > > Hello!
> > > >
> > > > If a project made a mistake in the architecture and needs to lookup
> JSF
> > > > scoped instances from the BeanProvider, is this possible in any way
> > > > (however hacky?).
> > > >
> > > > The problem is that since the request thread is needed to lookup the
> > > > instance it does not work from a thread.
> > > >
> > > > cheers
> > > >
> > >
> >
>

Re: Spurious NullPointerException in DelegateQueryBuilder

[John D. Ament]

Very good news :-)

Enjoy!

John

On Tue, Jun 21, 2016 at 4:30 AM Kettil, Mattias 
wrote:

> Hi John,
>
> It seems like the issue has disappeared after upgrading to 1.7.0. Nice
> timing with the new release. :)
>
> Thank you for your quick response.
>
> Best regards,
> Mattias
>
> -----Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: den 17 juni 2016 14:20
> To: users@deltaspike.apache.org
> Subject: Re: Spurious NullPointerException in DelegateQueryBuilder
>
> Hi Mattias,
>
> I was wondering if you could try with latest 1.7.0-SNAPSHOT and see if the
> issue reproduces?  I see many changes going on in this class, and the line
> referenced isn't in this spot anymore.  The NPE likely means that
> beanManager is null, which doesn't make much sense to me.
>
> I would also try to see if this reproduces on TomEE 7.
>
> John
>
> On Fri, Jun 17, 2016 at 8:02 AM Kettil, Mattias 
> wrote:
>
> > Hello,
> >
> > We have an application that uses Deltaspike 1.6.1 on TomEE 1.7.1 with
> > EclipseLink 2.6.2. Java version is 1.8.0_74.
> >
> > During a batch operation (BatchEE 0.3-incubating) using 32 threads we
> > sometimes get the following exception:
> >
> > java.lang.NullPointerException
> >  at
> >
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.selectDelegate(DelegateQueryBuilder.java:79)
> >  at
> >
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:52)
> >  at
> >
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:59)
> >  at
> >
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$1.proceed(TransactionalQueryRunner.java:77)
> >  at
> >
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:133)
> >  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$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
> >  at
> >
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:147)
> >  at
> >
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:129)
> >  at
> >
> org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
> >  at
> >
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.proceedOriginal(DelegateManualInvocationHandler.java:46)
> >  at
> >
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:63)
> >  at
> >
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:39)
> >  at
> > se.company.OurRepository$$DSPartialBeanProxy.save(Unknown Source)...
> >
> > Our repository class is defined like this:
> > @Repository
> > @ApplicationScoped
> > public interface OurRepository extends EntityRepository > Long> { ...
> > }
> >
> > And is called from a @Stateless bean.
> >
> > The entity itself is not null, since when we tried that in a unit test
> > we got a different exception.
> > The stacktrace suggests that the bean manager instance is null, but we
> > have no idea how that can be. Are we missing something here? Do you
> > have any idea how this exception can arise?
> >
> > Best regards,
> > Mattias Kettil
> >
>

Re: @Futureable and void-returning methods

[John D. Ament]

Xavier,

Thanks for the report.  That's really a miss IMHO maybe Romain knows more?

I created https://issues.apache.org/jira/browse/DELTASPIKE-1176 to track
it, hopefully someone can pick up soon.  Any chances for a contribution
from you?

John

On Tue, Jun 21, 2016 at 5:19 AM Xavier Dury  wrote:

> Hi,
>
> I was trying to rewrite my @Asynchronous (EJB) methods with @Futureable
> (Deltaspike) but noticed that @Futureable does not work with methods
> returning void.
>
> Was it somehow overlooked or deliberately omitted? I could understand that
> @Futureable means that a Future must be returned as its name would
> suggest.
>
> In my case, I am trying to process elements in parallel and use a
> CompletionService (which needs an Executor) to do something after all
> elements have been processed. I implemented a simple Executor with
> @Futureable run() but it does not work because run() is a void method.
>
> Thanks,
>
> Xavier
>

[ANNOUNCE] Release of Apache DeltaSpike 1.7.0

[John D. Ament]

The Apache DeltaSpike team is pleased to announce the 26th release of
DeltaSpike, v1.7.0.  This release includes 40 changes to the codebase
primarily focused on the data module.  We've added some initial Java 8
support and improved performance.

Apache DeltaSpike is not a CDI-container, but a portable CDI extension.

Documentation:
http://deltaspike.apache.org/documentation/

Download:
http://deltaspike.apache.org/download.html

Release Notes:
http://s.apache.org/DeltaSpike-1.7.0

Enjoy!

John

Re: Spurious NullPointerException in DelegateQueryBuilder

[John D. Ament]

Hi Mattias,

I was wondering if you could try with latest 1.7.0-SNAPSHOT and see if the
issue reproduces?  I see many changes going on in this class, and the line
referenced isn't in this spot anymore.  The NPE likely means that
beanManager is null, which doesn't make much sense to me.

I would also try to see if this reproduces on TomEE 7.

John

On Fri, Jun 17, 2016 at 8:02 AM Kettil, Mattias 
wrote:

> Hello,
>
> We have an application that uses Deltaspike 1.6.1 on TomEE 1.7.1 with
> EclipseLink 2.6.2. Java version is 1.8.0_74.
>
> During a batch operation (BatchEE 0.3-incubating) using 32 threads we
> sometimes get the following exception:
>
> java.lang.NullPointerException
>  at
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.selectDelegate(DelegateQueryBuilder.java:79)
>  at
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:52)
>  at
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:59)
>  at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$1.proceed(TransactionalQueryRunner.java:77)
>  at
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:133)
>  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$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
>  at
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:147)
>  at
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:129)
>  at
> org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
>  at
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.proceedOriginal(DelegateManualInvocationHandler.java:46)
>  at
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:63)
>  at
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:39)
>  at
> se.company.OurRepository$$DSPartialBeanProxy.save(Unknown Source)...
>
> Our repository class is defined like this:
> @Repository
> @ApplicationScoped
> public interface OurRepository extends EntityRepository {
> ...
> }
>
> And is called from a @Stateless bean.
>
> The entity itself is not null, since when we tried that in a unit test we
> got a different exception.
> The stacktrace suggests that the bean manager instance is null, but we
> have no idea how that can be. Are we missing something here? Do you have
> any idea how this exception can arise?
>
> Best regards,
> Mattias Kettil
>

Re: No JavaDocs for 1.6.1

[John D. Ament]

Chris,

The site is now published.  1.6.1 javadocs are out there.

John

On Fri, Jun 10, 2016 at 8:42 AM John D. Ament  wrote:

> Chris,
>
> Thanks, I'll take a look at generating them this evening.  It looks like
> there might be a step missing somewhere in the pipeline.
>
> John
>
> On Fri, Jun 10, 2016 at 8:36 AM Chris Baumgartner <
> chris.baumgart...@fujifilm.com> wrote:
>
>> Hello,
>>
>> I'm a new user to DeltaSpike. There are no JavaDocs for 1.6.1. When I
>> click
>> the link, https://deltaspike.apache.org/javadoc/1.6.1/, I get a "not
>> found"
>> error. The JavaDocs for  1.6.2-SNAPSHOT are there, but 1.6.1 are missing.
>>
>> Thanks.
>>
>> --
>> Chris Baumgartner
>> Java Software Developer
>> FUJIFILM Medical Systems U.S.A., Inc.
>> TeraMedica Division
>> 10400 Innovation Drive, Suite 200
>> Milwaukee, WI 53226
>> Office: (414) 908-7724
>> www.teramedica.com
>>
>> *Helping provide healthcare experiences that enhance the quality of life.
>> *
>>
>> --
>> NOTICE: This message, including any attachments, is only for the use of
>> the
>> intended recipient(s) and may contain confidential and privileged
>> information, or information otherwise protected from disclosure by law.
>> If
>> the reader of this message is not the intended recipient, you are hereby
>> notified that any use, disclosure, copying, dissemination or distribution
>> of this message or any of its attachments is strictly prohibited.  If you
>> received this message in error, please contact the sender immediately by
>> reply email and destroy this message, including all attachments, and any
>> copies thereof.
>>
>

Re: No JavaDocs for 1.6.1

[John D. Ament]

Chris,

Thanks, I'll take a look at generating them this evening.  It looks like
there might be a step missing somewhere in the pipeline.

John

On Fri, Jun 10, 2016 at 8:36 AM Chris Baumgartner <
chris.baumgart...@fujifilm.com> wrote:

> Hello,
>
> I'm a new user to DeltaSpike. There are no JavaDocs for 1.6.1. When I click
> the link, https://deltaspike.apache.org/javadoc/1.6.1/, I get a "not
> found"
> error. The JavaDocs for  1.6.2-SNAPSHOT are there, but 1.6.1 are missing.
>
> Thanks.
>
> --
> Chris Baumgartner
> Java Software Developer
> FUJIFILM Medical Systems U.S.A., Inc.
> TeraMedica Division
> 10400 Innovation Drive, Suite 200
> Milwaukee, WI 53226
> Office: (414) 908-7724
> www.teramedica.com
>
> *Helping provide healthcare experiences that enhance the quality of life. *
>
> --
> NOTICE: This message, including any attachments, is only for the use of the
> intended recipient(s) and may contain confidential and privileged
> information, or information otherwise protected from disclosure by law.  If
> the reader of this message is not the intended recipient, you are hereby
> notified that any use, disclosure, copying, dissemination or distribution
> of this message or any of its attachments is strictly prohibited.  If you
> received this message in error, please contact the sender immediately by
> reply email and destroy this message, including all attachments, and any
> copies thereof.
>

Re: Deltaspike Advanced authorization not working in WAS 8

[John D. Ament]

Hi Dmitry,

Not sure why you responded to this topic with a brand new issue.  Anyways I
believe Romain and I have helped you on this already

https://lists.apache.org/thread.html/Z1a7v5zunuiwdpq

John

On Tue, May 31, 2016 at 8:14 PM Shultz, Dmitry 
wrote:

> Hi All,
>
> I'm trying to use the CdiTestRunner + CDI 1.2 + OpenEJB + Camel CDI
> component and it fails with this exception (the app runs in TomEE 7 without
> problems):
>
> WARNING: Jar not loaded. classpath.ear.  Cannot unmarshall the beans.xml:
> unexpected element (uri:"http://java.sun.com/xml/ns/javaee";,
> local:"scan"). Expected elements are <{
> http://java.sun.com/xml/ns/javaee}decorators>,<{
> http://java.sun.com/xml/ns/javaee}interceptors>,<{
> http://java.sun.com/xml/ns/javaee}alternatives>
> org.apache.openejb.OpenEJBException: Cannot unmarshall the beans.xml:
> unexpected element (uri:"http://java.sun.com/xml/ns/javaee";,
> local:"scan"). Expected elements are <{
> http://java.sun.com/xml/ns/javaee}decorators>,<{
> http://java.sun.com/xml/ns/javaee}interceptors>,<{
> http://java.sun.com/xml/ns/javaee}alternatives>
> at
> org.apache.openejb.config.ReadDescriptors.readBeans(ReadDescriptors.java:652)
> at
> org.apache.openejb.config.ReadDescriptors.readBeans(ReadDescriptors.java:499)
> at
> org.apache.openejb.config.ReadDescriptors.deploy(ReadDescriptors.java:108)
> at
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:403)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:971)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:832)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:546)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:591)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:484)
> at
> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:463)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:151)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:68)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:309)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:289)
> 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:497)
> at
> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
> at
> org.apache.openejb.core.LocalInitialContextFactory.init(LocalInitialContextFactory.java:98)
> at
> org.apache.openejb.core.LocalInitialContextFactory.init(LocalInitialContextFactory.java:62)
> at
> org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:46)
> at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.(InitialContext.java:216)
> at
> org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:102)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:468)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:371)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:398)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:144)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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:497)
> at
> com.intellij.rt.execution.application.

Re: Transaction Scope activation

[John D. Ament]

Figured it out, turns out it was a conflict w/ the new bootstrap API in
Weld.

John

On Mon, May 16, 2016 at 10:47 AM Gerhard Petracek <
gerhard.petra...@gmail.com> wrote:

> please have a look at [1]
>
> regards,
> gerhard
>
> [1]
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jpa/impl/src/test/java/org/apache/deltaspike/test/jpa/api/transactionscoped/defaultinjection/DefaultTransactionScopedEntityManagerInjectionTest.java
>
>
>
> 2016-05-16 16:41 GMT+02:00 John D. Ament :
>
> > A couple of observations.
> >
> > The test doesn't match the docs.  For example, we use dependent EM
> >
> >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jpa/impl/src/test/java/org/apache/deltaspike/test/jpa/api/transactional/defaultinjection/TestEntityManagerProducer.java#L29
> >
> > Do we have any tests that use TransactionScoped ?
> >
> > On Mon, May 16, 2016 at 10:31 AM Gerhard Petracek 
> > wrote:
> >
> > > hi,
> > >
> > > that sounds like an issue with your setup.
> > > our tests pass with weld v2.3.4 (see [1]).
> > > -> please provide more information or a demo-application which
> > illustrates
> > > the issue.
> > >
> > > regards,
> > > gerhard
> > >
> > > [1]
> > >
> > >
> >
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%202.3.4/
> > >
> > >
> > >
> > > 2016-05-16 15:46 GMT+02:00 John D. Ament :
> > >
> > > > Hey guys
> > > >
> > > > I'm wondering if I'm doing something wrong.  I'm trying to leverage
> > DS's
> > > > transaction scope to start a context for the duration of a
> transaction,
> > > per
> > > > [1].  However, I keep getting a context not active.  I'm using DS
> 1.6.0
> > > and
> > > > Weld 2.3.4.
> > > >
> > > > John
> > > >
> > > >
> > > > [1]:
> > > >
> > https://deltaspike.apache.org/documentation/jpa.html#@TransactionScoped
> > > >
> > >
> >
>

Re: Transaction Scope activation

[John D. Ament]

A couple of observations.

The test doesn't match the docs.  For example, we use dependent EM

https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jpa/impl/src/test/java/org/apache/deltaspike/test/jpa/api/transactional/defaultinjection/TestEntityManagerProducer.java#L29

Do we have any tests that use TransactionScoped ?

On Mon, May 16, 2016 at 10:31 AM Gerhard Petracek 
wrote:

> hi,
>
> that sounds like an issue with your setup.
> our tests pass with weld v2.3.4 (see [1]).
> -> please provide more information or a demo-application which illustrates
> the issue.
>
> regards,
> gerhard
>
> [1]
>
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%202.3.4/
>
>
>
> 2016-05-16 15:46 GMT+02:00 John D. Ament :
>
> > Hey guys
> >
> > I'm wondering if I'm doing something wrong.  I'm trying to leverage DS's
> > transaction scope to start a context for the duration of a transaction,
> per
> > [1].  However, I keep getting a context not active.  I'm using DS 1.6.0
> and
> > Weld 2.3.4.
> >
> > John
> >
> >
> > [1]:
> > https://deltaspike.apache.org/documentation/jpa.html#@TransactionScoped
> >
>

Transaction Scope activation

[John D. Ament]

Hey guys

I'm wondering if I'm doing something wrong.  I'm trying to leverage DS's
transaction scope to start a context for the duration of a transaction, per
[1].  However, I keep getting a context not active.  I'm using DS 1.6.0 and
Weld 2.3.4.

John


[1]: https://deltaspike.apache.org/documentation/jpa.html#@TransactionScoped

Re: having problem with remove entity in data module

[John D. Ament]

That's normal JPA behavior.  You have to have a managed entity to do this.
Simple way is to do something like

Something something = new Something();
something.setName( "Name" );
Something saved = somethingDao.save( something );
somethingDao.remove( saved );

Otherwise you should extend from EntityManagerAware and use the find method
there.

John

On Tue, May 10, 2016 at 11:40 AM  wrote:

> Hi Team,
>
> Almost I succeeded to use data module except 'remove' method of my
> repository. Having simple test:
>
> @org.junit.Test
> public void test2(){
> Something something = new Something();
> something.setName( "Name" );
> somethingDao.save( something );
> log.info( something.getId() );
> somethingDao.remove( somethingDao.findBy(
> something.getId() ) );
> }
>
> fails with
>
> test2(test.DeltaspikeTest)  Time elapsed: 0.016 sec  <<< ERROR!
> org.apache.deltaspike.data.api.QueryInvocationException: Failed calling
> Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> org.apache.deltaspike.data.api.QueryInvocationException,message=Failed
> calling Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> org.apache.deltaspike.data.api.QueryInvocationException,message=Failed
> calling Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> java.lang.reflect.InvocationTargetException,message=null
> at test.DeltaspikeTest.test2(DeltaspikeTest.java:36)
> Caused by: org.apache.deltaspike.data.api.QueryInvocationException: Failed
> calling Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> org.apache.deltaspike.data.api.QueryInvocationException,message=Failed
> calling Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> java.lang.reflect.InvocationTargetException,message=null
> at test.DeltaspikeTest.test2(DeltaspikeTest.java:36)
> Caused by: org.apache.deltaspike.data.api.QueryInvocationException: Failed
> calling Repository:
>
> [Repository=pack1.SomethingDao,entity=pack1.Something,method=remove,exception=class
> java.lang.reflect.InvocationTargetException,message=null
> at test.DeltaspikeTest.test2(DeltaspikeTest.java:36)
> Caused by: java.lang.reflect.InvocationTargetException
> at test.DeltaspikeTest.test2(DeltaspikeTest.java:36)
> Caused by: java.lang.IllegalArgumentException: Entity must be managed to
> call remove: Name, try merging the detached and try the remove again.
> at test.DeltaspikeTest.test2(DeltaspikeTest.java:36)
>
>
> For me it should obviously work. To regenerate the proble I made a GitHub
> project : https://github.com/p4w3l/deltaspikeTest
>
> Simple call: mvn
>
> and you will see
>
> best regards
> Paweł

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Ah yes good point.  Fixed.

On Tue, Apr 5, 2016 at 4:13 AM Luigi Bitonti 
wrote:

> The note reads well, but isn't the example just before it
> (personRepository.findAllByAge...) inaccurate?
> Shouldn't that use .orderAsc("p.lastName", false) and .orderDesc("p.age",
> false)?
> Luigi
>
>
>
> On Monday, April 4, 2016 8:07 PM, John D. Ament 
> wrote:
>
>
>  I added a note to the docs about the extra method
>
> https://deltaspike.apache.org/documentation/data.html#QueryOptions21
>
> If you want to look and give feedback.
>
> John
>
> On Mon, Apr 4, 2016 at 3:02 PM Luigi Bitonti 
> wrote:
>
> > Ok, fantastic. Many thanks for that.
> > Cheers,Luigi
> >
> >On Monday, April 4, 2016 5:44 PM, John D. Ament <
> johndam...@apache.org>
> > wrote:
> >
> >
> >  Luigi,
> >
> > I actually already pushed in a fix.
> >
> > John
> >
> > On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti  wrote:
> >
> > > Hi John,
> > >
> > > I've created a fix for this, which you filed as DELTASPIKE-1105. Would
> > you
> > > accept a patch (as per http://deltaspike.apache.org/community.html)
> or a
> > > pull request?
> > >
> > > Cheers,
> > > Luigi
> > >
> > >
> > >
> > > On Thursday, March 31, 2016 12:43 PM, John D. Ament <
> > johndam...@apache.org>
> > > wrote:
> > >
> > >
> > > Hi Luigi,
> > >
> > > I think really the only way to solve this is to add the methods to
> > disable
> > > prefixing the entity name.  Even adding more attributes to control the
> > > entity name won't fix it, as the join problem you described will exist.
> > >
> > > John
> > >
> > > On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti
>  > >
> > > wrote:
> > >
> > > Hi John,
> > > Many thanks for your help with this. I am afraid neither of your
> > solutions
> > > would work for what I can see.
> > > What I am currently trying to implement is custom (i.e. client
> selected)
> > > sorting for a jpaql query. Something that looks a bit like this (in a
> > > simplified version as the real thing is more complex):
> > >  SELECT DISTINCT b FROM  Booking b JOIN FETCH b.items bi2 JOIN FETCH
> > > bi2.location l WHERE b.organisation = :organisation  AND b.timeFrom <
> > > :intervalEnd  AND b.timeTo > :intervalStart  AND b.status IN :statuses;
> > > If I use 'e' instead of 'b' as alias for the Booking entity, everything
> > > works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> > > cannot order by e.items.id as I get an error (using eclipselink at
> > > least) that the attribute cannot be accessed as I should really be
> using
> > > bi2.id, which I cannot use though as that is transformed into e.b2.id.
> > > The only solution that I can see would work with every use case I can
> > > think of, is to have a way to avoid the 'e' being prepended. This could
> > be:
> > > 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> > > string attribute (i.e. as it is). These could be called orderAscRaw and
> > > orderDescRaw or something similar.
> > > 2) Alternatively, a similar solution could be that there are overloaded
> > > versions of orderAsc(String attribute, boolean useEntityPrefix) and
> > > orderDesc. This still adds 2 extra methods to the interface (which is
> not
> > > really great).
> > > 3) Using a hint, but for what I can see this would be ugly in my
> opinion
> > > as the hint might be applied after the sorting(s) and therefore the
> > > implementation would have to "scan" the query and remove existing 'e'
> > > prefixes from the order by clause.
> > > I am not a great fan of overloading, so I'd personally go with 1), but
> I
> > > am not sure if this is acceptable or there are better solutions I have
> > > overlooked. If it is acceptable I can make the change a create a pull
> > > request if that helps.
> > > Cheers,Luigi
> > >
> > >On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> > > johndam...@apache.org> wrote:
> > >
> > >
> > >  Luigi,
> > > Actually would you be able to provide the exact query statement you
> have
> > > in your repo.  The reason it fails in this test is because the query
> >

Re: OrderByQueryStringPostProcessor

[John D. Ament]

I added a note to the docs about the extra method

https://deltaspike.apache.org/documentation/data.html#QueryOptions21

If you want to look and give feedback.

John

On Mon, Apr 4, 2016 at 3:02 PM Luigi Bitonti 
wrote:

> Ok, fantastic. Many thanks for that.
> Cheers,Luigi
>
> On Monday, April 4, 2016 5:44 PM, John D. Ament 
> wrote:
>
>
>  Luigi,
>
> I actually already pushed in a fix.
>
> John
>
> On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti  wrote:
>
> > Hi John,
> >
> > I've created a fix for this, which you filed as DELTASPIKE-1105. Would
> you
> > accept a patch (as per http://deltaspike.apache.org/community.html) or a
> > pull request?
> >
> > Cheers,
> > Luigi
> >
> >
> >
> > On Thursday, March 31, 2016 12:43 PM, John D. Ament <
> johndam...@apache.org>
> > wrote:
> >
> >
> > Hi Luigi,
> >
> > I think really the only way to solve this is to add the methods to
> disable
> > prefixing the entity name.  Even adding more attributes to control the
> > entity name won't fix it, as the join problem you described will exist.
> >
> > John
> >
> > On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti  >
> > wrote:
> >
> > Hi John,
> > Many thanks for your help with this. I am afraid neither of your
> solutions
> > would work for what I can see.
> > What I am currently trying to implement is custom (i.e. client selected)
> > sorting for a jpaql query. Something that looks a bit like this (in a
> > simplified version as the real thing is more complex):
> >  SELECT DISTINCT b FROM  Booking b JOIN FETCH b.items bi2 JOIN FETCH
> > bi2.location l WHERE b.organisation = :organisation  AND b.timeFrom <
> > :intervalEnd  AND b.timeTo > :intervalStart  AND b.status IN :statuses;
> > If I use 'e' instead of 'b' as alias for the Booking entity, everything
> > works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> > cannot order by e.items.id as I get an error (using eclipselink at
> > least) that the attribute cannot be accessed as I should really be using
> > bi2.id, which I cannot use though as that is transformed into e.b2.id.
> > The only solution that I can see would work with every use case I can
> > think of, is to have a way to avoid the 'e' being prepended. This could
> be:
> > 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> > string attribute (i.e. as it is). These could be called orderAscRaw and
> > orderDescRaw or something similar.
> > 2) Alternatively, a similar solution could be that there are overloaded
> > versions of orderAsc(String attribute, boolean useEntityPrefix) and
> > orderDesc. This still adds 2 extra methods to the interface (which is not
> > really great).
> > 3) Using a hint, but for what I can see this would be ugly in my opinion
> > as the hint might be applied after the sorting(s) and therefore the
> > implementation would have to "scan" the query and remove existing 'e'
> > prefixes from the order by clause.
> > I am not a great fan of overloading, so I'd personally go with 1), but I
> > am not sure if this is acceptable or there are better solutions I have
> > overlooked. If it is acceptable I can make the change a create a pull
> > request if that helps.
> > Cheers,Luigi
> >
> >On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> > johndam...@apache.org> wrote:
> >
> >
> >  Luigi,
> > Actually would you be able to provide the exact query statement you have
> > in your repo.  The reason it fails in this test is because the query
> looks
> > like this:
> > @Query("select s from Simple s")public abstract QueryResult
> > queryAll();
> > Whereas the identifier is expecting e, in order to work with QueryResult.
> > A similar problem happens with the named query when I change the
> identifier.
> > There's a couple of thoughts I had.1. We can introduce an attribute in
> > query (or even a hint) that says what the identifier is in "select s from
> > Something s".  This would be more robust and configurable, but introduce
> a
> > burden.
> > 2. Update documentation to clarify that "e" should be used as your query
> > identifier by default.
> > John
> > On Wed, Mar 30, 2016 at 7:50 PM John D. Ament 
> > wrote:
> >
> > Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> > John
> >
> > On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti 
> wro

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Luigi,

I actually already pushed in a fix.

John

On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti  wrote:

> Hi John,
>
> I've created a fix for this, which you filed as DELTASPIKE-1105. Would you
> accept a patch (as per http://deltaspike.apache.org/community.html) or a
> pull request?
>
> Cheers,
> Luigi
>
>
>
> On Thursday, March 31, 2016 12:43 PM, John D. Ament 
> wrote:
>
>
> Hi Luigi,
>
> I think really the only way to solve this is to add the methods to disable
> prefixing the entity name.  Even adding more attributes to control the
> entity name won't fix it, as the join problem you described will exist.
>
> John
>
> On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti 
> wrote:
>
> Hi John,
> Many thanks for your help with this. I am afraid neither of your solutions
> would work for what I can see.
> What I am currently trying to implement is custom (i.e. client selected)
> sorting for a jpaql query. Something that looks a bit like this (in a
> simplified version as the real thing is more complex):
>  SELECT DISTINCT b FROM  Booking b JOIN FETCH b.items bi2 JOIN FETCH
> bi2.location l WHERE b.organisation = :organisation   AND b.timeFrom <
> :intervalEnd   AND b.timeTo > :intervalStart   AND b.status IN :statuses;
> If I use 'e' instead of 'b' as alias for the Booking entity, everything
> works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> cannot order by e.items.id as I get an error (using eclipselink at
> least) that the attribute cannot be accessed as I should really be using
> bi2.id, which I cannot use though as that is transformed into e.b2.id.
> The only solution that I can see would work with every use case I can
> think of, is to have a way to avoid the 'e' being prepended. This could be:
> 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> string attribute (i.e. as it is). These could be called orderAscRaw and
> orderDescRaw or something similar.
> 2) Alternatively, a similar solution could be that there are overloaded
> versions of orderAsc(String attribute, boolean useEntityPrefix) and
> orderDesc. This still adds 2 extra methods to the interface (which is not
> really great).
> 3) Using a hint, but for what I can see this would be ugly in my opinion
> as the hint might be applied after the sorting(s) and therefore the
> implementation would have to "scan" the query and remove existing 'e'
> prefixes from the order by clause.
> I am not a great fan of overloading, so I'd personally go with 1), but I
> am not sure if this is acceptable or there are better solutions I have
> overlooked. If it is acceptable I can make the change a create a pull
> request if that helps.
> Cheers,Luigi
>
> On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> johndam...@apache.org> wrote:
>
>
>  Luigi,
> Actually would you be able to provide the exact query statement you have
> in your repo.  The reason it fails in this test is because the query looks
> like this:
> @Query("select s from Simple s")public abstract QueryResult
> queryAll();
> Whereas the identifier is expecting e, in order to work with QueryResult.
> A similar problem happens with the named query when I change the identifier.
> There's a couple of thoughts I had.1. We can introduce an attribute in
> query (or even a hint) that says what the identifier is in "select s from
> Something s".  This would be more robust and configurable, but introduce a
> burden.
> 2. Update documentation to clarify that "e" should be used as your query
> identifier by default.
> John
> On Wed, Mar 30, 2016 at 7:50 PM John D. Ament 
> wrote:
>
> Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> John
>
> On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti  wrote:
>
> Hi John,
> If you add the following test to QueryResultTest.java in
> deltaspike-data-module:
> @Testpublic void should_sort_all_result(){List
> result = repo.queryAll()
> .orderDesc(Simple_.counter)
> .orderAsc(Simple_.id).getResultList();}
>  You'll get the following error:
>
> Tests in error:
> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
> order by e.counter DESC,e.id ASC]
> This is an overly simplistic case that could be worked around by using 'e'
> as an alias in queryAll (instead of 's'), but in more complex case with
> joins and order by clauses that use ass

Doc Updates - Using DeltaSpike with Gradle

[John D. Ament]

All,

I've updated the DeltaSpike documentation to include how to setup with
Gradle.  All dependencies listed now have segments that show both Maven and
Gradle configurations.

John

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Hi Luigi,

I think really the only way to solve this is to add the methods to disable
prefixing the entity name.  Even adding more attributes to control the
entity name won't fix it, as the join problem you described will exist.

John

On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti 
wrote:

> Hi John,
> Many thanks for your help with this. I am afraid neither of your solutions
> would work for what I can see.
> What I am currently trying to implement is custom (i.e. client selected)
> sorting for a jpaql query. Something that looks a bit like this (in a
> simplified version as the real thing is more complex):
>  SELECT DISTINCT b FROM  Booking b JOIN FETCH b.items bi2 JOIN FETCH
> bi2.location l WHERE b.organisation = :organisation   AND b.timeFrom <
> :intervalEnd   AND b.timeTo > :intervalStart   AND b.status IN :statuses;
> If I use 'e' instead of 'b' as alias for the Booking entity, everything
> works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> cannot order by e.items.id as I get an error (using eclipselink at
> least) that the attribute cannot be accessed as I should really be using
> bi2.id, which I cannot use though as that is transformed into e.b2.id.
> The only solution that I can see would work with every use case I can
> think of, is to have a way to avoid the 'e' being prepended. This could be:
> 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> string attribute (i.e. as it is). These could be called orderAscRaw and
> orderDescRaw or something similar.
> 2) Alternatively, a similar solution could be that there are overloaded
> versions of orderAsc(String attribute, boolean useEntityPrefix) and
> orderDesc. This still adds 2 extra methods to the interface (which is not
> really great).
> 3) Using a hint, but for what I can see this would be ugly in my opinion
> as the hint might be applied after the sorting(s) and therefore the
> implementation would have to "scan" the query and remove existing 'e'
> prefixes from the order by clause.
> I am not a great fan of overloading, so I'd personally go with 1), but I
> am not sure if this is acceptable or there are better solutions I have
> overlooked. If it is acceptable I can make the change a create a pull
> request if that helps.
> Cheers,Luigi
>
> On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> johndam...@apache.org> wrote:
>
>
>  Luigi,
> Actually would you be able to provide the exact query statement you have
> in your repo.  The reason it fails in this test is because the query looks
> like this:
> @Query("select s from Simple s")public abstract QueryResult
> queryAll();
> Whereas the identifier is expecting e, in order to work with QueryResult.
> A similar problem happens with the named query when I change the identifier.
> There's a couple of thoughts I had.1. We can introduce an attribute in
> query (or even a hint) that says what the identifier is in "select s from
> Something s".  This would be more robust and configurable, but introduce a
> burden.
> 2. Update documentation to clarify that "e" should be used as your query
> identifier by default.
> John
> On Wed, Mar 30, 2016 at 7:50 PM John D. Ament 
> wrote:
>
> Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> John
>
> On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti  wrote:
>
> Hi John,
> If you add the following test to QueryResultTest.java in
> deltaspike-data-module:
> @Testpublic void should_sort_all_result(){List
> result = repo.queryAll()
> .orderDesc(Simple_.counter)
> .orderAsc(Simple_.id).getResultList();}
>  You'll get the following error:
>
> Tests in error:
> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
> order by e.counter DESC,e.id ASC]
> This is an overly simplistic case that could be worked around by using 'e'
> as an alias in queryAll (instead of 's'), but in more complex case with
> joins and order by clauses that use associated entities there's no
> workaround that I can see.
> I tried (briefly I must confess) to work around this by creating an
> alternative QueryBuilderFactory that could then allow me to avoid using
> WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> OrderByQueryStringPostProcessor but code duplication made the solution
> rather ugly, so I gave up and decided to ask.
> Cheers,Luigi
> On Wednesday, March 30, 2016 12:32 AM, John D. Ament &l

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Luigi,

Actually would you be able to provide the exact query statement you have in
your repo.  The reason it fails in this test is because the query looks
like this:

@Query("select s from Simple s")
public abstract QueryResult queryAll();

Whereas the identifier is expecting e, in order to work with QueryResult.
A similar problem happens with the named query when I change the identifier.

There's a couple of thoughts I had.
1. We can introduce an attribute in query (or even a hint) that says what
the identifier is in "select s from Something s".  This would be more
robust and configurable, but introduce a burden.

2. Update documentation to clarify that "e" should be used as your query
identifier by default.

John

On Wed, Mar 30, 2016 at 7:50 PM John D. Ament  wrote:

> Thank you Luigi!
> I'm able to reproduce, I'll create a ticket.
>
> John
>
>
> On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti  wrote:
>
>> Hi John,
>>
>> If you add the following test to QueryResultTest.java in
>> deltaspike-data-module:
>>
>> @Test
>> public void should_sort_all_result()
>> {
>> List result = repo.queryAll()
>> .orderDesc(Simple_.counter)
>> .orderAsc(Simple_.id)
>> .getResultList();
>> }
>>
>> You'll get the following error:
>>
>> Tests in error:
>>
>> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
>> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
>> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
>> order by e.counter DESC,e.id ASC]
>>
>> This is an overly simplistic case that could be worked around by using
>> 'e' as an alias in queryAll (instead of 's'), but in more complex case with
>> joins and order by clauses that use associated entities there's no
>> workaround that I can see.
>>
>> I tried (briefly I must confess) to work around this by creating an
>> alternative QueryBuilderFactory that could then allow me to avoid using
>> WrappedQueryBuilder, DefaultQueryResult and (ultimately)
>> OrderByQueryStringPostProcessor but code duplication made the solution
>> rather ugly, so I gave up and decided to ask.
>>
>> Cheers,
>> Luigi
>>
>> On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
>> johndam...@apache.org> wrote:
>>
>>
>> Luigi,
>>
>> Do you happen to have a test that can reproduce this?
>>
>> John
>>
>> On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti 
>> wrote:
>>
>> Hi all,
>> I am having issues with using the orderAsc and orderDesc methods on
>> QueryResult as the order by clause always ends up having an "e." prepended
>> to its sort-by properties (e.g "...order by e.i.date_from" instead of
>>  "...order by i.date_from". Is there any way to avoid that from happening?I
>> am using Deltaspike 1.4.2 but from what I can see in the
>> OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and
>> also current git master.
>> Many thanks,Luigi
>>
>>
>>
>>

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Thank you Luigi!
I'm able to reproduce, I'll create a ticket.

John

On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti  wrote:

> Hi John,
>
> If you add the following test to QueryResultTest.java in
> deltaspike-data-module:
>
> @Test
> public void should_sort_all_result()
> {
> List result = repo.queryAll()
> .orderDesc(Simple_.counter)
> .orderAsc(Simple_.id)
> .getResultList();
> }
>
> You'll get the following error:
>
> Tests in error:
>   should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
> order by e.counter DESC,e.id ASC]
>
> This is an overly simplistic case that could be worked around by using 'e'
> as an alias in queryAll (instead of 's'), but in more complex case with
> joins and order by clauses that use associated entities there's no
> workaround that I can see.
>
> I tried (briefly I must confess) to work around this by creating an
> alternative QueryBuilderFactory that could then allow me to avoid using
> WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> OrderByQueryStringPostProcessor but code duplication made the solution
> rather ugly, so I gave up and decided to ask.
>
> Cheers,
> Luigi
>
> On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> johndam...@apache.org> wrote:
>
>
> Luigi,
>
> Do you happen to have a test that can reproduce this?
>
> John
>
> On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti 
> wrote:
>
> Hi all,
> I am having issues with using the orderAsc and orderDesc methods on
> QueryResult as the order by clause always ends up having an "e." prepended
> to its sort-by properties (e.g "...order by e.i.date_from" instead of
>  "...order by i.date_from". Is there any way to avoid that from happening?I
> am using Deltaspike 1.4.2 but from what I can see in the
> OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and
> also current git master.
> Many thanks,Luigi
>
>
>
>

Re: OrderByQueryStringPostProcessor

[John D. Ament]

Luigi,

Do you happen to have a test that can reproduce this?

John

On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti 
wrote:

> Hi all,
> I am having issues with using the orderAsc and orderDesc methods on
> QueryResult as the order by clause always ends up having an "e." prepended
> to its sort-by properties (e.g "...order by e.i.date_from" instead of
>  "...order by i.date_from". Is there any way to avoid that from happening?I
> am using Deltaspike 1.4.2 but from what I can see in the
> OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and
> also current git master.
> Many thanks,Luigi

Re: Extends AbstractEntityRepository Create custom methods

[John D. Ament]

Hi,

Are you sure you need to return query result? Seems like you're crossing
boundaries.

typedQuery("").setFirstResult(2).setMaxResults(4).getResultList()

That should take care of the pagination for you.

John

On Fri, Feb 26, 2016 at 6:58 AM Pedro Belmino 
wrote:

> Hi,
> Daniel Cunha,
>
> I appreciate the support but this solution to make the logic in the
> business layer is not viable for me , I would have to combine all the
> possible filters.
>
> I'm at that point, but still no solution.
> public QueryResult findByNameLikeIgnoreCaseAndAssigment(String
> name, Assigment assigment, @FirstResult int start, @MaxResults int
> pageSize){ String queryString = "select p "+ " FROM Person p " + "WHERE
> p.name = :name and p.assigment = :assigment"; javax.persistence.Query
> query
> = entityManager().createQuery(queryString); query.setParameter("name",
> name); query.setParameter("assigment", assigment); QueryResult d =
> new DefaultQueryResult<>(new QueryBuilder() { @Override protected Object
> execute(CdiQueryInvocationContext ctx) {
> ctx.applyJpaQueryPostProcessors(query); return ctx.executeQuery(query); }
> }, cdiQueryContextHolder.get());// OCCURS NullPointerException return d; }
>
> Can someone help me?
>
> 2016-02-25 15:11 GMT-03:00 Daniel Cunha :
>
> > Hi Pedro,
> >
> > You can try that:
> >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/test/service/SimpleRepository.java#L103
> >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/QueryResultTest.java#L167
> >
> > So, you'll create methods on your repository, something like:
> > findByNameLikeIgnoreCase
> > findByAssigment
> > findByNameLikeIgnoreCaseAndAssigment
> >
> >
> > So you can put your business logic on your business class.
> >
> > You'll call the method that you need:
> >
> > @Inject
> > private RepositoryClass repository
> >
> > if (YOUR_LOGIC)
> >   repository.findByNameLikeIgnoreCaseAndAssigment
> > ...
> >
> > To be honest, I don't know if possible to do like you was trying.
> > I needed checking it.
> >
> >
> > On Thu, Feb 25, 2016 at 2:04 PM, Pedro Belmino 
> > wrote:
> >
> > > Daniel,
> > > OK to return an object of type List.
> > >
> > > However i need return an QueryResult, because the pagination is
> > > important for me.
> > >
> > >
> > >
> > > 2016-02-25 13:59 GMT-03:00 Daniel Cunha :
> > >
> > > > Hi Pedro,
> > > >
> > > > JPA Criteria API Support sounds better for this cases:
> > > >
> > >
> >
> http://deltaspike.apache.org/documentation/data.html#JPACriteriaAPISupport
> > > >
> > > > On Thu, Feb 25, 2016 at 1:50 PM, Pedro Belmino <
> pedrobelm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > > I need construct an method that receive dynamic parameters for HQL
> > > query
> > > > > construct.
> > > > >
> > > > > For example:
> > > > > @Repository(forEntity = Person.class)
> > > > > public abstract class PersonCustomRepository extends
> > > > > AbstractEntityRepository  {
> > > > >
> > > > >public QueryResult
> > > > > findByNameLikeIgnoreCaseAndAssigment(String name,
> > > > > Assigment assigment, @FirstResult int start, @MaxResults int
> > pageSize){
> > > > > String query = "select p from person p WHERE 1 = 1 ";
> > > > > if(name!=null&&!name.equals("")){
> > > > >   query+= " and name = ?1 ";
> > > > > }
> > > > > if(assigment!=null){
> > > > >   query+= " and assigment = ?2 ";
> > > > > }
> > > > > // WHAT IS NECESSARY CODE FOR RETURN  paginated object of type
> > > > > QueryResult.
> > > > > }
> > > > > }
> > > > >
> > > > > I'm doing something wrong? I do otherwise?
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > >
> > > > > *Pedro Belmino *System Analist
> > > > > Laboratory of Mobile Computing and Design
> > > > > Federal University of Ceará
> > > > > Office: + 55 85 3366-9797
> > > > > E-mail: pedrobelm...@great.ufc.br 
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Cunha
> > > > https://twitter.com/dvlc_
> > > > http://www.tomitribe.com
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > *Pedro Belmino *System Analist
> > > Laboratory of Mobile Computing and Design
> > > Federal University of Ceará
> > > Office: + 55 85 3366-9797
> > > E-mail: pedrobelm...@great.ufc.br 
> > >
> >
> >
> >
> > --
> > Daniel Cunha
> > https://twitter.com/dvlc_
> > http://www.tomitribe.com
> >
>
>
>
> --
>
>
>
> *Pedro Belmino *System Analist
> Laboratory of Mobile Computing and Design
> Federal University of Ceará
> Office: + 55 85 3366-9797
> E-mail: pedrobelm...@great.ufc.br 
>

Re: Transactional with extended EntityManager is not working?

[John D. Ament]

Alex,

Now i'm very intrigued (I was previously just intrigued/confused).  Any
chance you have a sample project that reproduces the issue?

John

On Mon, Jan 18, 2016 at 9:32 PM Alex Roytman  wrote:

> John,
>
> It is weld latest version plus jersey in tomcat 7.
>
> It really is weld that's in play here. It creates client proxy for injected
> entity manager and the interface for which proxy is created depend on
> return type of producer not the declared type of the field being injected.
> So when my producer was returning EntityManager I could not cast it to my
> JdoEntityManager. As for transactional interceptor it seems to me it should
> recognize any injected interface that extends EntityManager. Or even better
> be configurable to provide transactional semantics to any interface that
> can expose transaction methods in some way
>
>
> On Mon, Jan 18, 2016, 7:37 PM John D. Ament  wrote:
>
> > Alex,
> >
> > That... doesn't make any sense, though I'm glad you were able to solve
> it.
> >
> > What container are you targetting? The method return type on a producer
> has
> > nothing to do with the possible types that it can inject into (though
> they
> > generally should be of similar types, you're just providing an extra bean
> > into the context).
> >
> > John
> >
> > On Sun, Jan 17, 2016 at 10:31 PM Alex Roytman 
> wrote:
> >
> > > John,
> > >
> > > I solved it. I guess it was my inexperience with CDI. In producer I
> > > returned my JdoEntityManagerImpl by the cretor method return type was
> > > EntityManager not JdoEntityManager and so typecast of injected
> > > EntityManager to JdoEntityManager failed. I assumed that proxy is build
> > > based on injection point field type but so I was trying to inject
> > > JdoEntityManager but it actually looks like (and it makes much more
> sense
> > > as I think about it) the client proxy for injected bean is based on
> > return
> > > type of provider's creator method. so a small change from
> > >
> > > @Produces
> > > @RequestScoped
> > > protected EntityManager create() {
> > >   return new
> > > JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> > > }
> > >
> > > to
> > >
> > > @Produces
> > > @RequestScoped
> > > protected JdoEntityManager create() {
> > >   return new
> > > JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> > > }
> > >
> > > took care of it!
> > >
> > > thanks again for looking into it!
> > >
> > > if you think that @Transactional should have worked for injecting
> > >
> > > @Inject private JdoEntityManager entityManager;
> > >
> > > please let me know and I will experiment a bit more with it
> > >
> > >
> > > On Sun, Jan 17, 2016 at 10:13 PM John D. Ament 
> > > wrote:
> > >
> > > > I'll take a closer look tomorrow but I believe you are creating a
> > > > non-proxyable bean here which is why interceptors aren't working.  If
> > you
> > > > get to it before I do, please try another interceptor on this class
> > > >
> > > > A proxyable bean should require a noargs constructor or one with
> > @Inject
> > > on
> > > > it
> > > > On Jan 17, 2016 21:46, "Alex Roytman"  wrote:
> > > >
> > > > > Also, @Transactional behavior seems to be such a useful thing which
> > > > should
> > > > > not be hardwired to EntityManager. Wouldn't it make sense to make
> > > > > transactional resource interface be configurable so that it would
> be
> > > easy
> > > > > to replicate transactional behavior for any resource as long as it
> > > > provide
> > > > > access to its begin/commit/rollback/rollbackOnly methods?
> > > > >
> > > > > On Sun, Jan 17, 2016 at 9:12 PM Alex Roytman 
> > > wrote:
> > > > >
> > > > > > John,
> > > > > >
> > > > > > Here is how I create it:
> > > > > >
> > > > > > @ApplicationScoped
> > > > > > public class JdoEntityManagerProducer {
> > > > > >   private final PersistenceManagerFactory gctrackJdoFactory =
> > > > > JDOFactory.getFactory();
> > > > > >
> > > > > >   @Produces
> > > 

Re: Transactional with extended EntityManager is not working?

[John D. Ament]

Alex,

That... doesn't make any sense, though I'm glad you were able to solve it.

What container are you targetting? The method return type on a producer has
nothing to do with the possible types that it can inject into (though they
generally should be of similar types, you're just providing an extra bean
into the context).

John

On Sun, Jan 17, 2016 at 10:31 PM Alex Roytman  wrote:

> John,
>
> I solved it. I guess it was my inexperience with CDI. In producer I
> returned my JdoEntityManagerImpl by the cretor method return type was
> EntityManager not JdoEntityManager and so typecast of injected
> EntityManager to JdoEntityManager failed. I assumed that proxy is build
> based on injection point field type but so I was trying to inject
> JdoEntityManager but it actually looks like (and it makes much more sense
> as I think about it) the client proxy for injected bean is based on return
> type of provider's creator method. so a small change from
>
> @Produces
> @RequestScoped
> protected EntityManager create() {
>   return new
> JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> }
>
> to
>
> @Produces
> @RequestScoped
> protected JdoEntityManager create() {
>   return new
> JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> }
>
> took care of it!
>
> thanks again for looking into it!
>
> if you think that @Transactional should have worked for injecting
>
> @Inject private JdoEntityManager entityManager;
>
> please let me know and I will experiment a bit more with it
>
>
> On Sun, Jan 17, 2016 at 10:13 PM John D. Ament 
> wrote:
>
> > I'll take a closer look tomorrow but I believe you are creating a
> > non-proxyable bean here which is why interceptors aren't working.  If you
> > get to it before I do, please try another interceptor on this class
> >
> > A proxyable bean should require a noargs constructor or one with @Inject
> on
> > it
> > On Jan 17, 2016 21:46, "Alex Roytman"  wrote:
> >
> > > Also, @Transactional behavior seems to be such a useful thing which
> > should
> > > not be hardwired to EntityManager. Wouldn't it make sense to make
> > > transactional resource interface be configurable so that it would be
> easy
> > > to replicate transactional behavior for any resource as long as it
> > provide
> > > access to its begin/commit/rollback/rollbackOnly methods?
> > >
> > > On Sun, Jan 17, 2016 at 9:12 PM Alex Roytman 
> wrote:
> > >
> > > > John,
> > > >
> > > > Here is how I create it:
> > > >
> > > > @ApplicationScoped
> > > > public class JdoEntityManagerProducer {
> > > >   private final PersistenceManagerFactory gctrackJdoFactory =
> > > JDOFactory.getFactory();
> > > >
> > > >   @Produces
> > > >   @GCTrack
> > > >   @RequestScoped
> > > >   protected EntityManager create() {
> > > > return new
> > > JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> > > >   }
> > > >
> > > >   protected void closeEntityManager(@Disposes @GCTrack EntityManager
> > > entityManager) {
> > > > if (entityManager.isOpen()) {
> > > >   entityManager.close();
> > > > }
> > > >   }
> > > > }
> > > >
> > > >
> > > > here is how I inject it
> > > >
> > > > @Inject @GCTrack private JdoEntityManager entityManager;
> > > >
> > > >
> > > >
> > > > On Sun, Jan 17, 2016 at 6:12 PM John D. Ament  >
> > > > wrote:
> > > >
> > > >> Hi Alex,
> > > >>
> > > >> Just want to check, your usecase is something like
> > > >>
> > > >> public interface MyEntityManager extends EntityManager {
> > > >>
> > > >> }
> > > >>
> > > >> but then how are you creating instances of this object?
> > > >>
> > > >> John
> > > >>
> > > >> On Sun, Jan 17, 2016 at 5:45 PM Alex Roytman 
> > > wrote:
> > > >>
> > > >> > It looks like of a bean is injected with a field of type not
> > > >> EntityManager
> > > >> > but an interface extending it, transactional annotation does not
> > work.
> > > >> Is
> > > >> > there any way to have transactional to recognize interfaces that
> > > extend
> > > >> > from EntityManager
> > > >> >
> > > >> > Thanks
> > > >> > Alex
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Transactional with extended EntityManager is not working?

[John D. Ament]

Sorry I'm also assuming that you added @Transactional to your jdo entity
manager, and not on other classes.
On Jan 17, 2016 22:13, "John D. Ament"  wrote:

> I'll take a closer look tomorrow but I believe you are creating a
> non-proxyable bean here which is why interceptors aren't working.  If you
> get to it before I do, please try another interceptor on this class
>
> A proxyable bean should require a noargs constructor or one with @Inject
> on it
> On Jan 17, 2016 21:46, "Alex Roytman"  wrote:
>
>> Also, @Transactional behavior seems to be such a useful thing which should
>> not be hardwired to EntityManager. Wouldn't it make sense to make
>> transactional resource interface be configurable so that it would be easy
>> to replicate transactional behavior for any resource as long as it provide
>> access to its begin/commit/rollback/rollbackOnly methods?
>>
>> On Sun, Jan 17, 2016 at 9:12 PM Alex Roytman  wrote:
>>
>> > John,
>> >
>> > Here is how I create it:
>> >
>> > @ApplicationScoped
>> > public class JdoEntityManagerProducer {
>> >   private final PersistenceManagerFactory gctrackJdoFactory =
>> JDOFactory.getFactory();
>> >
>> >   @Produces
>> >   @GCTrack
>> >   @RequestScoped
>> >   protected EntityManager create() {
>> > return new
>> JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
>> >   }
>> >
>> >   protected void closeEntityManager(@Disposes @GCTrack EntityManager
>> entityManager) {
>> > if (entityManager.isOpen()) {
>> >   entityManager.close();
>> > }
>> >   }
>> > }
>> >
>> >
>> > here is how I inject it
>> >
>> > @Inject @GCTrack private JdoEntityManager entityManager;
>> >
>> >
>> >
>> > On Sun, Jan 17, 2016 at 6:12 PM John D. Ament 
>> > wrote:
>> >
>> >> Hi Alex,
>> >>
>> >> Just want to check, your usecase is something like
>> >>
>> >> public interface MyEntityManager extends EntityManager {
>> >>
>> >> }
>> >>
>> >> but then how are you creating instances of this object?
>> >>
>> >> John
>> >>
>> >> On Sun, Jan 17, 2016 at 5:45 PM Alex Roytman 
>> wrote:
>> >>
>> >> > It looks like of a bean is injected with a field of type not
>> >> EntityManager
>> >> > but an interface extending it, transactional annotation does not
>> work.
>> >> Is
>> >> > there any way to have transactional to recognize interfaces that
>> extend
>> >> > from EntityManager
>> >> >
>> >> > Thanks
>> >> > Alex
>> >> >
>> >>
>> >
>>
>

Re: Transactional with extended EntityManager is not working?

[John D. Ament]

I'll take a closer look tomorrow but I believe you are creating a
non-proxyable bean here which is why interceptors aren't working.  If you
get to it before I do, please try another interceptor on this class

A proxyable bean should require a noargs constructor or one with @Inject on
it
On Jan 17, 2016 21:46, "Alex Roytman"  wrote:

> Also, @Transactional behavior seems to be such a useful thing which should
> not be hardwired to EntityManager. Wouldn't it make sense to make
> transactional resource interface be configurable so that it would be easy
> to replicate transactional behavior for any resource as long as it provide
> access to its begin/commit/rollback/rollbackOnly methods?
>
> On Sun, Jan 17, 2016 at 9:12 PM Alex Roytman  wrote:
>
> > John,
> >
> > Here is how I create it:
> >
> > @ApplicationScoped
> > public class JdoEntityManagerProducer {
> >   private final PersistenceManagerFactory gctrackJdoFactory =
> JDOFactory.getFactory();
> >
> >   @Produces
> >   @GCTrack
> >   @RequestScoped
> >   protected EntityManager create() {
> > return new
> JdoEntityManagerImpl(gctrackJdoFactory.getPersistenceManager());
> >   }
> >
> >   protected void closeEntityManager(@Disposes @GCTrack EntityManager
> entityManager) {
> > if (entityManager.isOpen()) {
> >   entityManager.close();
> >     }
> >   }
> > }
> >
> >
> > here is how I inject it
> >
> > @Inject @GCTrack private JdoEntityManager entityManager;
> >
> >
> >
> > On Sun, Jan 17, 2016 at 6:12 PM John D. Ament 
> > wrote:
> >
> >> Hi Alex,
> >>
> >> Just want to check, your usecase is something like
> >>
> >> public interface MyEntityManager extends EntityManager {
> >>
> >> }
> >>
> >> but then how are you creating instances of this object?
> >>
> >> John
> >>
> >> On Sun, Jan 17, 2016 at 5:45 PM Alex Roytman 
> wrote:
> >>
> >> > It looks like of a bean is injected with a field of type not
> >> EntityManager
> >> > but an interface extending it, transactional annotation does not work.
> >> Is
> >> > there any way to have transactional to recognize interfaces that
> extend
> >> > from EntityManager
> >> >
> >> > Thanks
> >> > Alex
> >> >
> >>
> >
>

Re: Transactional with extended EntityManager is not working?

[John D. Ament]

Hi Alex,

Just want to check, your usecase is something like

public interface MyEntityManager extends EntityManager {

}

but then how are you creating instances of this object?

John

On Sun, Jan 17, 2016 at 5:45 PM Alex Roytman  wrote:

> It looks like of a bean is injected with a field of type not EntityManager
> but an interface extending it, transactional annotation does not work. Is
> there any way to have transactional to recognize interfaces that extend
> from EntityManager
>
> Thanks
> Alex
>

Re: During @Transactional method EntityManager.flush() causes TransactionRequiredException

[John D. Ament]

Paul,

Glad its working.  Please don't hesitate to reach out to the list if you
have further questions.

John

On Mon, Dec 14, 2015 at 7:20 PM Paul Wills  wrote:

> Hi John,
>
> I've done the change and it works perfectly :-)
>
> Thanks very much,
> Paul
>
> On 15 December 2015 at 09:06, Paul Wills  wrote:
>
> > Thanks John.
> >
> > Thats a simple workaround. The reason I use @Database because the code
> > assist can tell me all the choices of database that I have, instead  of
> > remembering all the different annotations (maybe younger programmers
> don't
> > have many problems remembering everything).
> >
> > I will add @DatabaseApp and @DatabaseVault and see how it goes.
> >
> > Thanks again for your help and suggested workaround.
> >
> > Regards,
> > Paul
> >
> > On 14 December 2015 at 23:51, John D. Ament 
> wrote:
> >
> >> Hi Paul,
> >>
> >> If I had to guess, the main reason this hasn't been fixed is because it
> >> hasn't been a need.  The workaround for the issue is pretty straight
> >> forward -instead of using @Database(APP) and @Database(VAULT) you use
> >> dedicated qualifiers - @VaultDB and @AppDB.  I believe most people would
> >> agree that this is the more correct way to do it anyways, since the
> >> attribute just makes it a bit more confusing.
> >>
> >> I can look to see what it takes to fix 259, I would still recommend this
> >> approach of a dedicated qualifier per instead of common qualifier.
> >>
> >> John
> >>
> >>
> >> On Mon, Dec 14, 2015 at 8:29 AM Paul Wills 
> >> wrote:
> >>
> >> > Hi Gerhard,
> >> >
> >> > I've been doing a lot more complicated transactional things in Spring
> >> for 7
> >> > years in Tomcat, so its a little frustrating to "go out on a limb"
> >> against
> >> > the Spring crowd to head down what I believe to be the better path
> (JEE
> >> +
> >> > CDI) only to hit problems which undermine the use of the technology
> (in
> >> > this case Deltaspike Transactional handling).
> >> >
> >> > I have to deploy on Tomcat, so it looks like I have to go with OpenEJB
> >> to
> >> > handle the transactions correctly.
> >> >
> >> > Don't get me wrong, Deltaspike is an essential and great library when
> >> using
> >> > CDI, but it doesn't appear that this issue (DELTASPIKE-259) will be
> >> > resolved any time soon.
> >> >
> >> > Regards,
> >> > Paul
> >> >
> >> > On 14 December 2015 at 21:20, Gerhard Petracek <
> >> gerhard.petra...@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > hi paul,
> >> > >
> >> > > it doesn't work due to [1].
> >> > >
> >> > > regards,
> >> > > gerhard
> >> > >
> >> > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-259
> >> > >
> >> > >
> >> > >
> >> > > 2015-12-14 9:59 GMT+01:00 Paul Wills :
> >> > >
> >> > >> The EntityManager is injected into the test case like so
> >> > >> @Inject @Database(Instance.APP) private EntityManager
> entityManager;
> >> > >>
> >> > >> The database producer creates entity managers for 2 database
> >> instances
> >> > >> (APP
> >> > >> and VAULT). I originally had the getAppEntityManager() method
> >> annotated
> >> > >> with TransactionScoped but removing it made no difference to the
> >> > flushing
> >> > >> problem. All other test cases which use the entity manager work
> fine,
> >> > but
> >> > >> they are rather simple, ie no reading back from the database before
> >> > >> commiting.
> >> > >>
> >> > >> Here is the producer for the EntityManager(s).
> >> > >> 
> >> > >> @ApplicationScoped
> >> > >> public class DatabaseProducer {
> >> > >> // ~ Static Variables and Methods
> >> > >> --
> >> > >> private static Logger LOGGER =
> >> > >> LoggerFactory.getLogger(DatabaseProducer.class);
> >> > >>
&

Re: During @Transactional method EntityManager.flush() causes TransactionRequiredException

[John D. Ament]

> >> }
> >> returnValue = appEntityManager;
> >> }
> >> break;
> >>
> >> case VAULT:
> >> if (transactionScoped) {
> >> returnValue =
> >> vaultEntityManagerFactory.createEntityManager();
> >>
> >> } else {
> >> if (vaultEntityManager == null) {
> >> vaultEntityManager =
> >> vaultEntityManagerFactory.createEntityManager();
> >> logDatabaseConnectionInfo(instance);
> >> }
> >> returnValue = vaultEntityManager;
> >> }
> >> break;
> >> }
> >>
> >> return returnValue;
> >> }
> >>
> >> 
> >>
> >> Regards,
> >> Paul
> >>
> >> On 14 December 2015 at 16:42, Mark Struberg  wrote:
> >>
> >> > And how is the entity manager being created?
> >> >
> >> > LieGrue,
> >> > Strub
> >> >
> >> > > Am 14.12.2015 um 04:25 schrieb John D. Ament  >:
> >> > >
> >> > > Paul,
> >> > >
> >> > > Could you show us what your test looks like, including how it
> injects
> >> the
> >> > > bean that is used here.
> >> > >
> >> > > John
> >> > >
> >> > > On Sun, Dec 13, 2015 at 10:09 PM Paul Wills <
> paul.wi...@engsol.com.au
> >> >
> >> > > wrote:
> >> > >
> >> > >> I can confirm the Transactional annotation is being imported as
> >> follows
> >> > >>
> >> > >> *import* org.apache.deltaspike.jpa.api.transaction.Transactional;
> >> > >>
> >> > >> Regards,
> >> > >>
> >> > >> Paul
> >> > >>
> >> > >>
> >> > >>> On 10 December 2015 at 15:06, Paul Wills <
> paul.wi...@engsol.com.au>
> >> > wrote:
> >> > >>>
> >> > >>> Whilst the following method is called in a test case, run with
> >> > >>> CdiTestRunner, the entityManager.flush() call causes a
> >> > >>> TransactionRequiredException.
> >> > >>>
> >> > >>> @Transactional
> >> > >>> public void saveAndFetchUser() {
> >> > >>>// Given - a new user
> >> > >>>final User randomUser = createRandomUser(false);
> >> > >>>
> >> > >>>   // When - saved
> >> > >>>final User savedUser = userService.saveUser(randomUser);
> >> > >>>// Then - user is saved as well as history and can be retrieved
> >> by
> >> > id
> >> > >>> and username
> >> > >>>assertThat(savedUser.getRoles(), hasSize(greaterThan(0)));
> >> > >>>
> >> > >>>entityManager.flush();  // manually flush as UaiCriteriaQueries
> >> > >> aren't
> >> > >>> flushed automatically
> >> > >>>final Paged pagedHistory =
> >> > >>> findUserHistoryMostRecentFirst(randomUser.getUsername());
> >> > >>>assertThat(pagedHistory.getDerivedTotal(), equalTo(1));
> >> > >>>assertThat(pagedHistory.getList(), hasSize(1));
> >> > >>>
> >> > >>>...
> >> > >>> }
> >> > >>>
> >> > >>> Is this a bug, or is there another way to flush the changes to the
> >> > >>> database?
> >> > >>>
> >> > >>> Environment:
> >> > >>> weld: 2.3.1.Final
> >> > >>> deltaspike: 1.5.1.Final
> >> > >>> deltaspike dependencies
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.apache.deltaspike.modules
> >> > >>>
> >> > >>> *deltaspike*-*jpa*-module-*api*
> >> > >>>
> >> > >>> ${deltaspike.version}
> >> > >>>
> >> > >>> compile
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.apache.deltaspike.modules
> >> > >>>
> >> > >>> *deltaspike*-*jpa*-module-*impl*
> >> > >>>
> >> > >>> ${deltaspike.version}
> >> > >>>
> >> > >>> compile
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.apache.deltaspike.core
> >> > >>>
> >> > >>> *deltaspike*-core-*api*
> >> > >>>
> >> > >>> *${deltaspike.version}*
> >> > >>>
> >> > >>> compile
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.apache.deltaspike.core
> >> > >>>
> >> > >>> *deltaspike*-core-*impl*
> >> > >>>
> >> > >>> *${deltaspike.version}*
> >> > >>>
> >> > >>> compile
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.apache.deltaspike.cdictrl
> >> > >>>
> >> > >>> *deltaspike*-*cdictrl*-weld
> >> > >>>
> >> > >>> ${deltaspike.version}
> >> > >>>
> >> > >>> test
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> org.jboss.weld.se
> >> > >>>
> >> > >>> weld-*se*-core
> >> > >>>
> >> > >>> *${weld.version}*
> >> > >>>
> >> > >>> test
> >> > >>>
> >> > >>> 
> >> > >>>
> >> > >>> Regards,
> >> > >>> Paul Wills
> >> > >>
> >> >
> >>
> >
> >
>

Re: During @Transactional method EntityManager.flush() causes TransactionRequiredException

[John D. Ament]

Paul,

Could you show us what your test looks like, including how it injects the
bean that is used here.

John

On Sun, Dec 13, 2015 at 10:09 PM Paul Wills 
wrote:

> I can confirm the Transactional annotation is being imported as follows
>
> *import* org.apache.deltaspike.jpa.api.transaction.Transactional;
>
> Regards,
>
> Paul
>
>
> On 10 December 2015 at 15:06, Paul Wills  wrote:
>
> > Whilst the following method is called in a test case, run with
> > CdiTestRunner, the entityManager.flush() call causes a
> > TransactionRequiredException.
> >
> > @Transactional
> > public void saveAndFetchUser() {
> > // Given - a new user
> > final User randomUser = createRandomUser(false);
> >
> >// When - saved
> > final User savedUser = userService.saveUser(randomUser);
> > // Then - user is saved as well as history and can be retrieved by id
> > and username
> > assertThat(savedUser.getRoles(), hasSize(greaterThan(0)));
> >
> > entityManager.flush();  // manually flush as UaiCriteriaQueries
> aren't
> > flushed automatically
> > final Paged pagedHistory =
> > findUserHistoryMostRecentFirst(randomUser.getUsername());
> > assertThat(pagedHistory.getDerivedTotal(), equalTo(1));
> > assertThat(pagedHistory.getList(), hasSize(1));
> >
> > ...
> > }
> >
> > Is this a bug, or is there another way to flush the changes to the
> > database?
> >
> > Environment:
> > weld: 2.3.1.Final
> > deltaspike: 1.5.1.Final
> > deltaspike dependencies
> >
> > 
> >
> > org.apache.deltaspike.modules
> >
> > *deltaspike*-*jpa*-module-*api*
> >
> > ${deltaspike.version}
> >
> > compile
> >
> > 
> >
> > 
> >
> > org.apache.deltaspike.modules
> >
> > *deltaspike*-*jpa*-module-*impl*
> >
> > ${deltaspike.version}
> >
> > compile
> >
> > 
> >
> > 
> >
> > org.apache.deltaspike.core
> >
> > *deltaspike*-core-*api*
> >
> > *${deltaspike.version}*
> >
> > compile
> >
> > 
> >
> > 
> >
> > org.apache.deltaspike.core
> >
> > *deltaspike*-core-*impl*
> >
> > *${deltaspike.version}*
> >
> > compile
> >
> > 
> >
> > 
> >
> > org.apache.deltaspike.cdictrl
> >
> > *deltaspike*-*cdictrl*-weld
> >
> > ${deltaspike.version}
> >
> > test
> >
> > 
> >
> > 
> >
> > org.jboss.weld.se
> >
> > weld-*se*-core
> >
> > *${weld.version}*
> >
> > test
> >
> > 
> >
> > Regards,
> > Paul Wills
> >
>

Re: WARNING on BeanProvider shall not be used to create ...

[John D. Ament]

On Tue, Dec 8, 2015 at 10:55 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Which version do you use?
>

Which version allowed us to start specifying scope on an interface for
partial bean?


> Please use the newest, otherwise provide a issue to replicate the
> AbstractMethodError. This should not occur.
>
> 2015-12-08 16:24 GMT+01:00 Esteve Avilés :
>
> > Yes,
> >
> > This is an exception when added @ApplicationScoped annotation to the
> > repository.
> >
> > Data module is included.
> >
> > Every thing works fine (without @ApplicationScoped ) but the WARNING
> > message appears every time it is called.
> >
> > Thanks
> >
> > On Tue, Dec 8, 2015 at 3:54 PM, Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> > > hmm? thats a completely other error as in the first mail.
> > > Make sure you have the data-impl module included.
> > >
> > >
> > > 2015-12-08 15:40 GMT+01:00 Esteve Avilés :
> > >
> > > > Hi Thomas,
> > > >
> > > > I have the repository declared as:
> > > >
> > > > @Repository
> > > >
> > > > public abstract class ServeiVendaRepository extends
> > > > BaseRepository {
> > > >
> > > >
> > > > And BaseRespository:
> > > >
> > > > public abstract class BaseRepository implements
> > > > CriteriaSupport, EntityRepository,
> > > > EntityManagerDelegate {
> > > >
> > > > 
> > > >
> > > >
> > > > Then I get this error:
> > > >
> > > >
> > > > Caused by: java.lang.AbstractMethodError:
> > > >
> > > >
> > >
> >
> cat.tmb.tdo.ocicommerce.domain.bo.BaseRepository.save(Ljava/lang/Object;)Ljava/lang/Object;
> > > >
> > > > at cat.tmb.tdo.ocicommerce.domain.bo.BaseBO.save(BaseBO.java:192)
> > > > [domain-1.14.0-snapshot.jar:]
> > > >
> > > > at cat.tmb.tdo.ocicommerce.domain.bo.venda.ServeiVendaBO.save(
> > > > ServeiVendaBO.java:381) [domain-1.14.0-snapshot.jar:]
> > > >
> > > >
> > > > Thanks:
> > > >
> > > > On Tue, Dec 8, 2015 at 3:09 PM, Thomas Andraschko <
> > > > andraschko.tho...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > setting a scope (e.g. ApplicationScope) on your repositories should
> > fix
> > > > the
> > > > > warning.
> > > > > Repositories are normally stateless, so using ApplicationScoped
> > should
> > > be
> > > > > fine.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Esteve Avilés
> > > >
> > >
> >
> >
> >
> > --
> > Esteve Avilés
> >
>

Re: Problems getting to run unit test with CdiTestRunner

[John D. Ament]

Hi Oliver,

does your alternative not extend anything? or was that left out?

John


On Sun, Dec 6, 2015 at 9:43 AM Oliver Weise  wrote:

> Hi everyone,
>
> I'm having a hard time finding a way to write unittests for my CDI enabled
> project using CdiTestRunner from Deltaspike
> Test-Control. I'm trying a pretty basic setup, effectively consisting of
> these four classes:
>
> 1. A facade to retrieve Company entities (which are simple JPA entity
> beans):
>
> @Default
> @RequestScoped
> public class CompanyFacade {
>
>  @Inject
>  private CompanyDAO _companyDao; // This is a deltaspike data DAO
>
>  @Transactional
>  public Company get(String id) {
>  return _companyDao.findBy(id);
>  }
>
>  @Transactional
>  public Company save(Company company) {
>  if (company.getCreateTimeStamp() == null) {
>  company.setCreateTimeStamp(new Date());
>  }
>  return _companyDao.save(company);
>  }
>
>  @Transactional
>  public SortableLazyList findAll() {
>  ...
>  }
>
> }
>
> 2. The DAO:
>
> @Repository(forEntity=Company.class)
> @Default
> @Dependent
> public interface CompanyDAO extends EntityRepository,
> EntityManagerDelegate {
>
>  @Query(value = "select e from Company e")
>  public QueryResult findCompanies();
>
> }
>
> 3. An Entity Manager Provider for the Tests, which uses a temporary H2
> database, registered via beans.xml:
>
> @Alternative
> public class TestEntityManagerProducer {
>
>  @Produces
>  public EntityManager create() {
>  return
> Persistence.createEntityManagerFactory("mamsTestCDI").createEntityManager();
>  }
>
>  public void close(@Disposes EntityManager em) {
>  if (em.isOpen()) {
>  em.close();
>  }
>
>  }
>
> }
>
> 4. And the test class:
>
> @RunWith(CdiTestRunner.class)
> public class CompanyFacadeTest extends TestCase {
>
>  @Inject
>  private CompanyFacade _companyFacade;
>
>  @Test
>  public void generalTest() {
>
>  Company c;
>  c = new Company();
>  c.setKey(UUID.randomUUID().toString());
>  c.setName("A company");
>  c.setDescription("Such a company");
>  _companyFacade.save(c);
>
>  assertEquals(_companyFacade.findAll().size(), 1);
>  }
>
> }
>
>
>
> My Problems:
>
> 1.) The Test will not inject the CompanyFacade class. I'm trying with two
> different CDI implementations, Weld and
> OpenEJB. Both say that they cannot find something to inject. Weld uses the
> infamous error "WELD-001408: Unsatisfied
> dependencies". OpenEJB says "Api type
> [com.musicacademy.mams.facades.CompanyFacade] is not found with the
> qualifiers".
>
> The only way that I can make this work is to a) Also add @Alternative to
> the CompanyFacade and b) add it to the
> beans.xml (which will break this functionality on the live server, where
> everything is actually working as intended).
>
> 2.) But then I get a different error when saving the Company in the test,
> which effectively tells me that JTA is not
> properly setup (as I think):
>
> org.apache.deltaspike.data.api.QueryInvocationException: Failed calling
> Repository:
>
> [Repository=com.musicacademy.mams.dao.CompanyDAO,entity=com.musicacademy.mams.data.Company,method=save,exception=class
> javax.naming.NameNotFoundException,message=null
>  at
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:134)
>  at
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:108)
>  at
>
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.proceedOriginal(DelegateManualInvocationHandler.java:46)
>  at
>
> org.apache.deltaspike.proxy.impl.invocation.AbstractManualInvocationHandler.invoke(AbstractManualInvocationHandler.java:63)
>  at
>
> org.apache.deltaspike.proxy.impl.invocation.DelegateManualInvocationHandler.staticInvoke(DelegateManualInvocationHandler.java:39)
>  at
> com.musicacademy.mams.dao.CompanyDAO$$DSPartialBeanProxy.save(Unknown
> Source)
>  at
> com.musicacademy.mams.facades.CompanyFacade.save(CompanyFacade.java:74)
>  ...
> Caused by: javax.naming.NameNotFoundException; remaining name
> 'TransactionSynchronizationRegistry'
>  at org.eclipse.jetty.jndi.NamingContext.lookup(NamingContext.java:449)
>  at org.eclipse.jetty.jndi.NamingContext.lookup(NamingContext.java:536)
>  at org.eclipse.jetty.jndi.NamingContext.lookup(NamingContext.java:551)
>  at
> org.eclipse.jetty.jndi.java.javaRootURLContext.lookup(javaRootURLContext.java:117)
>  at javax.naming.InitialContext.lookup(InitialContext.java:417)
>  at
> org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:96)
>  at
>
> org.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy.resolveTransactionRegistry(BeanManagedUserTransactionStrategy.java:195)
>  at
>
> org.apache.deltaspike.jpa.impl.transaction.BeanM

Re: Extending EntityRepository interface and EntityRepositoryHandler class

[John D. Ament]

Or even leverage the EntityManagerAware interface.

On Thu, Nov 26, 2015 at 9:50 AM Thomas Hug  wrote:

> Hi Robin
>
> Did you already look at the Query Delegates?
> http://deltaspike.apache.org/documentation/data.html#Extensions
>
> To summarize it for your context:
> - You can define a new interface with the add method
> - Provide an implementation of it which implements the new interface as
> well as DelegateQueryHandler. You can access the entityManager over an
> injected QueryInvocationContext (as in the docs).
> - Have your repositories implement / extend the new interface
> - Then ... No that's actually all, use the new add method :)
>
> Hope this helps.
>
> Cheers,
> Thomas
>
>
> On Thu, Nov 26, 2015 at 1:27 PM, Roos, Robin 
> wrote:
>
> > Of course, the method would be called add() and would return voidthis
> > is consistent with the notion that Repositories model a persistent
> > Collection.
> >
> > @RequiresTransaction
> > public void add(E entity) {
> > this.entityManager().persist(entity);
> > }
> >
> > -Original Message-
> > From: Roos, Robin [mailto:robin.r...@ntc-europe.co.uk]
> > Sent: 26 November 2015 12:21
> > To: users@deltaspike.apache.org
> > Subject: Extending EntityRepository interface and EntityRepositoryHandler
> > class
> >
> > Hi Folks
> >
> > My developers are building a JPA application in which Domain objects
> > remain entirely within the transactional context.  This means we never do
> > detach/merge, whether implicitly or explicitly.
> >
> > I am concerned that the default Save() implementation in
> > EntityRepositoryHandler would incur a merge() if an already-persistent
> > instance was passed to save().
> >
> >
> > @RequiresTransaction
> > public E save(E entity) {
> > if(this.context.isNew(entity)) {
> > this.entityManager().persist(entity);
> > return entity;
> > } else {
> > return this.entityManager().merge(entity);
> > }
> > }
> >
> > To preclude this I would like to extend EntityRepositoryHandler to
> provide
> > an implementation of a new method add(), as follows:
> >
> > @RequiresTransaction
> > public E save(E entity) {
> > this.entityManager().persist(entity);
> > return entity;
> > }
> >
> > Presumably I would put this method signature into interface
> > MyEntityRepository extends EntityRepository, and the implementation into
> > class MyEntityRepositoryHandler extends EntityRepositoryHandler.
> > Repository interfaces would then implement MyEntityRepository.  (We do
> not
> > have any Repository "implementations" since DeltaSpike takes care of that
> > for us.)
> >
> > But how do I get it all joined up, i.e.  how to I nominate my new Handler
> > to be used when CDI is working its magic on the Repository interfaces?
> >
> > Thanks, Robin.
> >
> >
> >
> ***
> > Nissan Motor Manufacturing (UK) Limited is a limited liability company
> > registered in England and Wales under number 01806912 with its registered
> > office at Washington Road, Sunderland, Tyne and Wear SR5 3NS.
> >
> > CONFIDENTIALITY NOTICE AND DISCLAIMER
> >
> > This message including any attachments to it (Message) is private and
> > confidential and may contain proprietary or legally privileged
> > information.  If you have received this Message in error, please send an
> > email to email.secur...@nissan-europe.com with a copy of this Message
> and
> > remove it from your system. You must not, directly or indirectly, use,
> > disclose, distribute, print or copy any part of this Message if you are
> not
> > the intended recipient. The NISSAN EUROPE S.A.S group of companies
> (NISSAN)
> > reserve the right to monitor all e-mail communications through its
> networks.
> >
> > NISSAN is not liable for the proper/complete transmission or any delay in
> > the receipt of this Message .  Whilst NISSAN takes care to protect its
> > systems from electronic virus attack or other harmful event, NISSAN gives
> > no warranty that this Message is free of any virus or other harmful
> matter
> > and accepts no liability for any loss or damage resulting from the
> > recipient receiving, opening or using it.
> >
> > Any views or opinions expressed in this Message are those of the author
> > and do not necessarily represent those of NISSAN.
> >
> >
> ***
> >
> >
> >
> ***
> > Nissan Motor Manufacturing (UK) Limited is a limited liability company
> > registered in England and Wales under number 01806912 with its registered
> > office at Washington Road, Sunderland, Tyne and Wear SR5 3NS.
> >
> > CONFIDENTIALITY NOTICE AND DISCLAIMER
> >
> > This message including any attachments to it (Message) is private and
> > confidential and may contain proprietary 

Re: DeltaSpike scheduler module

[John D. Ament]

Hi Emily,

The scheduler is dependent on the context control API only, not the
container control.  It is used only to enable starting additional contexts
during the bean method execution of the job.

You shouldn't need the SE JARs in this case.  You do need the CDI Ctrl impl
JAR for your container, e.g. the weld one here
https://github.com/apache/deltaspike/tree/master/deltaspike/cdictrl/impl-weld

John

On Mon, Sep 28, 2015 at 6:24 AM Emily Jiang 
wrote:

> I looked at the usage of DeltaSpike scheduler module, which depends on the
> Container module. The Container module is mainly for Java SE environment.
> How can I use the Scheduler module in Java EE environment? Do I have to
> declare the dependencies the se impl jars (e.g. weld se) in my pom.xml as
> the application servers won't have any se jars packaged?
> --
> Thanks
> Emily
> =
> Emily Jiang
> eji...@apache.org
>