Re: DeltaspikeData not initialized in UnitTest?
hi thomas,
since your repository works basically and the NPE occurs in hibernate,
it sounds like a hibernate init-bug.
if your setup requires some kind of init-logic (for whatever reason),
you can provide a custom implementation of the ExternalContainer spi
[1].
regards,
gerhard
[1]
http://deltaspike.apache.org/documentation/test-control.html#ExternalContainer
Am So., 10. Nov. 2019 um 20:15 Uhr schrieb Thomas Frühbeck
:
>
> Hi,
> I just found a phenomenon which I would like to discuss before posting a
> bug.
>
> I have a UnitTest using CDITestRunner which accesses JPA persistence via
> Repositories.
> The _first_ test accessing the Repository gets an NPE from JPA - see below.
>
> Debugging shows, that at first access the SetAttribute in this case is
> NULL!!
>
> public JoinBuilder(Criteria criteria, JoinType joinType,
> SetAttribute set)
> {
> this(criteria, joinType);
> this.set = set; <-- is NULL at first run!!
> }
>
> So the JoinBuilder cannot create a correct Predicate and returns null.
>
> Solution was: run some unnecessary query @Before, so that everything is
> initialized
>
> Is this something known to the informed user, that I missed until now?
>
> Many thanks and best regards,
> Thomas
>
>
> java.lang.NullPointerException
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.constructJoin(AbstractFromImpl.java:385)
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:373)
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:364)
> at
> org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.joinMap(JoinBuilder.java:153)
> at
> org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.build(JoinBuilder.java:108)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:291)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:155)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:109)
> at at.tfr.pfad.dao.SquadRepository.findByAssistant(SquadRepository.java:46)
> at at.tfr.pfad.processing.MemberValidator.validate(MemberValidator.java:133)
> at
> at.tfr.pfad.view.TestDownloadBean.testValidationTruppVerein(TestDownloadBean.java:175)
> 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.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:359)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:331)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:190)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:78)
[jira] [Resolved] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-558.
--
Resolution: Fixed
Fixed long time ago. Was an ancient OpenEJB issue.
> OpenEJB-ContainerControl tests randomly lock up on Solaris
> --
>
> Key: DELTASPIKE-558
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl
>Affects Versions: 0.6
> Environment: Solaris 10/11
> Java 1.6/1.8
>Reporter: Ron Smeral
>Assignee: Romain Manni-Bucau
>Priority: Major
>
> The tests for OpenEJB-ContainerControl often hang on Solaris.
> Noticed on Solaris 10/11 with Java 1.6/1.8.
> Output of jstack suggests that this might be an issue of the OpenEJB
> container itself.
> jstack output:
> {noformat}
> 2014-04-03 08:07:18
> Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
> "Attach Listener" daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
> [0x]
>java.lang.Thread.State: RUNNABLE
> "RetryTimer" daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
> [0xb2eef000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xead92c58> (a java.util.TaskQueue)
> at java.lang.Object.wait(Object.java:503)
> at java.util.TimerThread.mainLoop(Timer.java:526)
> - locked <0xead92c58> (a java.util.TaskQueue)
> at java.util.TimerThread.run(Timer.java:505)
> "Service Thread" daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=3 tid=0x0023 nid=0x21 waiting on
> condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
> condition [0x]
>java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=3 tid=0x0022c000 nid=0x1f runnable
> [0x]
>java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
> [0xb382f000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xead9ed68> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0xead9ed68> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
> "Reference Handler" daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
> [0xb38bf000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xead93db8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:503)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
> - locked <0xead93db8> (a java.lang.ref.Reference$Lock)
> "main" prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xead91ce0> (a
> java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
> at org.apache.openejb.Core.(Core.java:138)
> at
> org.apache.openejb.core.LocalInitialContext.(LocalInitialContext.java:51)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at
> org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
> at
> org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
> at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> at javax.naming.InitialContext.init(InitialContext.java:242)
> at javax.naming.InitialContext.(InitialContext.java:216)
> at
> org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainer
[jira] [Resolved] (DELTASPIKE-406) PersistenceUnits#instance singleton does not work in EAR scenarios
[
https://issues.apache.org/jira/browse/DELTASPIKE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-406.
--
Resolution: Won't Fix
Resolved with {{PersistenceUnitDescriptorProvider}}
> PersistenceUnits#instance singleton does not work in EAR scenarios
> ---
>
> Key: DELTASPIKE-406
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-406
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 0.5
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
>
> Currently the info regarding the various persistence.xml files on the
> classpath only gets scanned once and stored in the static
> PersistenceUnits#instance.
> This does not work in EAR scenarios if one of the persistence.xml is in a
> webapp or if the deltaspike-data-impl is on any other shared ClassLoader.
> We should at least document this restriction it until it's properly fixed.
> A possible fix would be to have a (weak) Map
> which also looks up the parent ClassLodaer chain.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-265) ComparableAnnotation
[
https://issues.apache.org/jira/browse/DELTASPIKE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-265.
--
Resolution: Won't Fix
We already have
{{org.apache.deltaspike.core.util.AnnotationUtils#getQualifierHashCode}} which
should do the trick most times.
> ComparableAnnotation
>
>
> Key: DELTASPIKE-265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-265
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Core
>Affects Versions: 0.3-incubating
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> We pretty often faced the problem that we have to compare Qualifiers,
> InterceptorBindings or other CDI annotations which support the "@Nonbinding"
> annotation.
> By providing a simple wrapper which implements the equals() and hashCode(),
> we can use this wrapper as key in HashMaps, etc.
> A method #getAnnotation() gives access to the wrapped underlying annotation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-404. -- Resolution: Not A Problem This already got fixed along the way a long time ago. When containers do an undeploy then they also MUST stop the Application as per EE spec. And DeltaSpike already removes itself from the BMI Map. > BeanManagerProvider leaks in case of undeploy/redeploy > -- > > Key: DELTASPIKE-404 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 > Project: DeltaSpike > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg >Priority: Major > Attachments: patch.diff > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1143) Implement an extension to veto AnnotatedType without a bean defining annotation
[ https://issues.apache.org/jira/browse/DELTASPIKE-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1143. --- Resolution: Won't Fix This is a nice idea, but the effort is way too high. Extensions do not really have a notion of BDA. So they don't really know from which jar the scanned AnnotatedType is coming from. That means that we would really need to configure all the allowed/disallowed packages via Strings. And this is really ugly and expensive. > Implement an extension to veto AnnotatedType without a bean defining > annotation > --- > > Key: DELTASPIKE-1143 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1143 > Project: DeltaSpike > Issue Type: New Feature > Components: Core >Reporter: Martin Kouba >Assignee: Mark Struberg >Priority: Major > > This would essentially replace the need for a new bean discovery mode (see > also CDI-420). The difference is the extension would be enabled globally and > bean discovery mode is defined per bean archive. > The extension should be configurable so that it was possible to exclude > packages/classes from processing. > * https://issues.jboss.org/browse/CDI-420 > * > http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2016/%23cdi-dev.2016-05-04.log.html#t2016-05-04T13:16:21 > * http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (DELTASPIKE-1143) Implement an extension to veto AnnotatedType without a bean defining annotation
[ https://issues.apache.org/jira/browse/DELTASPIKE-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned DELTASPIKE-1143: - Assignee: Mark Struberg > Implement an extension to veto AnnotatedType without a bean defining > annotation > --- > > Key: DELTASPIKE-1143 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1143 > Project: DeltaSpike > Issue Type: New Feature > Components: Core >Reporter: Martin Kouba >Assignee: Mark Struberg >Priority: Major > > This would essentially replace the need for a new bean discovery mode (see > also CDI-420). The difference is the extension would be enabled globally and > bean discovery mode is defined per bean archive. > The extension should be configurable so that it was possible to exclude > packages/classes from processing. > * https://issues.jboss.org/browse/CDI-420 > * > http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2016/%23cdi-dev.2016-05-04.log.html#t2016-05-04T13:16:21 > * http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1360) NPE at resolveEntityManagerBeans during heavy load
[
https://issues.apache.org/jira/browse/DELTASPIKE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1360.
---
Resolution: Not A Problem
In any case it is not a DeltaSpike issue I'd say!
It seems more like the resources configured in TomEE are exhaused. If you have
400 TPS then you might likely just be limited by e.g. the connection pool or
some other resource constraint. DeltaSpike does nothing else than requesting an
EntityManager from the container.
If the problem persists even in new TomEE versions, then please open a Ticket
in Apache TomEE
> NPE at resolveEntityManagerBeans during heavy load
> --
>
> Key: DELTASPIKE-1360
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1360
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Abhishek Rao
>Assignee: Romain Manni-Bucau
>Priority: Major
>
> We're running a web-app which is experiencing inconsistent 500 Internal
> Server Errors from TomEE during medium-high concurrency. The stack trace
> follows:
> {code:java}
> EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: null
> java.lang.NullPointerException
> at
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManagerBeans(QualifierBackedEntityManagerResolver.java:64)
> at
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManager(QualifierBackedEntityManagerResolver.java:46)
> at
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.resolveEntityManagerForQualifier(ResourceLocalTransactionStrategy.java:381)
> at
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:113)
> at
> org.apache.deltaspike.jpa.impl.transaction.TransactionalInterceptor.executeInTransaction(TransactionalInterceptor.java:57)
> at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
> at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
> at
> org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
> at **REMOVED_CONFIDENTIAL**
> at **REMOVED_CONFIDENTIAL**
> at **REMOVED_CONFIDENTIAL**
> at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.GeneratedMethodAccessor86.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at org.apache.openejb.util.proxy.ProxyEJB$Handler.invoke(ProxyEJB.java:74)
> at **REMOVED_CONFIDENTIAL**
> at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.server.cxf.rs.OpenEJBEJBInvoker.performInvocation(OpenEJBEJBInvoker.java:95)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:191)
> at
> org.apache.openejb.server.cxf.rs.OpenEJBEJBInvoker.invoke(OpenEJBEJBInvoker.java:68)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> at
> org.apache.openejb.server.cxf.rs.AutoJAXRSInvoker.invoke(AutoJAXRSInvoker.java:64)
> at
> org.apache.cxf.interce
[jira] [Commented] (DELTASPIKE-1360) NPE at resolveEntityManagerBeans during heavy load
[
https://issues.apache.org/jira/browse/DELTASPIKE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971208#comment-16971208
]
Mark Struberg commented on DELTASPIKE-1360:
---
ping [~rmannibucau] , did you find anything?
> NPE at resolveEntityManagerBeans during heavy load
> --
>
> Key: DELTASPIKE-1360
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1360
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Abhishek Rao
>Assignee: Romain Manni-Bucau
>Priority: Major
>
> We're running a web-app which is experiencing inconsistent 500 Internal
> Server Errors from TomEE during medium-high concurrency. The stack trace
> follows:
> {code:java}
> EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: null
> java.lang.NullPointerException
> at
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManagerBeans(QualifierBackedEntityManagerResolver.java:64)
> at
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManager(QualifierBackedEntityManagerResolver.java:46)
> at
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.resolveEntityManagerForQualifier(ResourceLocalTransactionStrategy.java:381)
> at
> org.apache.deltaspike.jpa.impl.transaction.ResourceLocalTransactionStrategy.execute(ResourceLocalTransactionStrategy.java:113)
> at
> org.apache.deltaspike.jpa.impl.transaction.TransactionalInterceptor.executeInTransaction(TransactionalInterceptor.java:57)
> at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
> at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
> at
> org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
> at **REMOVED_CONFIDENTIAL**
> at **REMOVED_CONFIDENTIAL**
> at **REMOVED_CONFIDENTIAL**
> at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.GeneratedMethodAccessor86.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at org.apache.openejb.util.proxy.ProxyEJB$Handler.invoke(ProxyEJB.java:74)
> at **REMOVED_CONFIDENTIAL**
> at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.server.cxf.rs.OpenEJBEJBInvoker.performInvocation(OpenEJBEJBInvoker.java:95)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:191)
> at
> org.apache.openejb.server.cxf.rs.OpenEJBEJBInvoker.invoke(OpenEJBEJBInvoker.java:68)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> at
> org.apache.openejb.server.cxf.rs.AutoJAXRSInvoker.invoke(AutoJAXRSInvoker.java:64)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
[jira] [Assigned] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7
[ https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned DELTASPIKE-1359: - Assignee: Gerhard Petracek (was: Mark Struberg) > wrong parent version of deltaspike-data-module-test-ee7 > --- > > Key: DELTASPIKE-1359 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Minor > > deltaspike-data-module-test-ee7 wasn't upgraded to 1.9.1-SNAPSHOT during the > release of 1.9.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7
[ https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971207#comment-16971207 ] Mark Struberg commented on DELTASPIKE-1359: --- Well, modules which are not active by default will always get ignored during a release :( Please feel free to come up with a better solution! > wrong parent version of deltaspike-data-module-test-ee7 > --- > > Key: DELTASPIKE-1359 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Mark Struberg >Priority: Minor > > deltaspike-data-module-test-ee7 wasn't upgraded to 1.9.1-SNAPSHOT during the > release of 1.9.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1364) Variable Replacement with @ConfigProperty not project stage aware
[
https://issues.apache.org/jira/browse/DELTASPIKE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1364.
---
Fix Version/s: 1.9.2
Resolution: Fixed
Seems I've already fixed that with the rework of the ConfigResolver to the
Config interface in 1.9.1. Now added a unit test to make sure it stays resolved.
> Variable Replacement with @ConfigProperty not project stage aware
> -
>
> Key: DELTASPIKE-1364
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1364
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.2
>Reporter: Nicolò Chieffo
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.2
>
>
> reading a property with injection does not correctly use project stage
> properties.
> I have a property file with this content:
>
> {code:java}
> xxx.frontend.prefix=https://dev.xxx.it
> xxx.frontend.prefix.Production=https://prod.xxx.it
> xxx.rsalogin.url=${xxx.frontend.prefix}/#/rsalogin/{rsalogin}
> {code}
>
>
> when reading xxx.rsalogin.url using annontations
> {code:java}
> @Inject
> @ConfigProperty(name = "xxx.rsalogin.url")
> private String url;
> {code}
> In the production environment (noticed that I don't have a
> org.apache.deltaspike.ProjectStage=Production property set because by default
> the stage is Production) it should be evaluated as
> *[https://prod.xxx.it/#/rsalogin/\{rsalogin}|https://prod.xxx.it/#/rsalogin/]*
> but instead I get
> *[https://dev.xxx.it/#/rsalogin/\{rsalogin}|https://dev.xxx.it/#/rsalogin/]*
> When using the declarative API it works correctly
> {code:java}
> ConfigResolver.getProjectStageAwarePropertyValue("xxx.rsalogin.url",
> "");{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1364) Variable Replacement with @ConfigProperty not project stage aware
[
https://issues.apache.org/jira/browse/DELTASPIKE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971205#comment-16971205
]
ASF subversion and git services commented on DELTASPIKE-1364:
-
Commit 63bbcfb75f437c7cee2578c07a4131e18e709ecf in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=63bbcfb ]
DELTASPIKE-1364 Variables in @ConfigProperty
Unit test only.
Seems I already fixed that while reworking the Config to an interface.
> Variable Replacement with @ConfigProperty not project stage aware
> -
>
> Key: DELTASPIKE-1364
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1364
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.2
>Reporter: Nicolò Chieffo
>Assignee: Mark Struberg
>Priority: Major
>
> reading a property with injection does not correctly use project stage
> properties.
> I have a property file with this content:
>
> {code:java}
> xxx.frontend.prefix=https://dev.xxx.it
> xxx.frontend.prefix.Production=https://prod.xxx.it
> xxx.rsalogin.url=${xxx.frontend.prefix}/#/rsalogin/{rsalogin}
> {code}
>
>
> when reading xxx.rsalogin.url using annontations
> {code:java}
> @Inject
> @ConfigProperty(name = "xxx.rsalogin.url")
> private String url;
> {code}
> In the production environment (noticed that I don't have a
> org.apache.deltaspike.ProjectStage=Production property set because by default
> the stage is Production) it should be evaluated as
> *[https://prod.xxx.it/#/rsalogin/\{rsalogin}|https://prod.xxx.it/#/rsalogin/]*
> but instead I get
> *[https://dev.xxx.it/#/rsalogin/\{rsalogin}|https://dev.xxx.it/#/rsalogin/]*
> When using the declarative API it works correctly
> {code:java}
> ConfigResolver.getProjectStageAwarePropertyValue("xxx.rsalogin.url",
> "");{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
DeltaspikeData not initialized in UnitTest?
Hi,
I just found a phenomenon which I would like to discuss before posting a
bug.
I have a UnitTest using CDITestRunner which accesses JPA persistence via
Repositories.
The _first_ test accessing the Repository gets an NPE from JPA - see below.
Debugging shows, that at first access the SetAttribute in this case is
NULL!!
public JoinBuilder(Criteria criteria, JoinType joinType,
SetAttribute set)
{
this(criteria, joinType);
this.set = set; <-- is NULL at first run!!
}
So the JoinBuilder cannot create a correct Predicate and returns null.
Solution was: run some unnecessary query @Before, so that everything is
initialized
Is this something known to the informed user, that I missed until now?
Many thanks and best regards,
Thomas
java.lang.NullPointerException
at
org.hibernate.jpa.criteria.path.AbstractFromImpl.constructJoin(AbstractFromImpl.java:385)
at
org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:373)
at
org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:364)
at
org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.joinMap(JoinBuilder.java:153)
at
org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.build(JoinBuilder.java:108)
at
org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:291)
at
org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:155)
at
org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:109)
at at.tfr.pfad.dao.SquadRepository.findByAssistant(SquadRepository.java:46)
at at.tfr.pfad.processing.MemberValidator.validate(MemberValidator.java:133)
at
at.tfr.pfad.view.TestDownloadBean.testValidationTruppVerein(TestDownloadBean.java:175)
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.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:359)
at
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:331)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:190)
at
org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:78)
[jira] [Assigned] (DELTASPIKE-1364) Variable Replacement with @ConfigProperty not project stage aware
[
https://issues.apache.org/jira/browse/DELTASPIKE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned DELTASPIKE-1364:
-
Assignee: Mark Struberg
> Variable Replacement with @ConfigProperty not project stage aware
> -
>
> Key: DELTASPIKE-1364
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1364
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.2
>Reporter: Nicolò Chieffo
>Assignee: Mark Struberg
>Priority: Major
>
> reading a property with injection does not correctly use project stage
> properties.
> I have a property file with this content:
>
> {code:java}
> xxx.frontend.prefix=https://dev.xxx.it
> xxx.frontend.prefix.Production=https://prod.xxx.it
> xxx.rsalogin.url=${xxx.frontend.prefix}/#/rsalogin/{rsalogin}
> {code}
>
>
> when reading xxx.rsalogin.url using annontations
> {code:java}
> @Inject
> @ConfigProperty(name = "xxx.rsalogin.url")
> private String url;
> {code}
> In the production environment (noticed that I don't have a
> org.apache.deltaspike.ProjectStage=Production property set because by default
> the stage is Production) it should be evaluated as
> *[https://prod.xxx.it/#/rsalogin/\{rsalogin}|https://prod.xxx.it/#/rsalogin/]*
> but instead I get
> *[https://dev.xxx.it/#/rsalogin/\{rsalogin}|https://dev.xxx.it/#/rsalogin/]*
> When using the declarative API it works correctly
> {code:java}
> ConfigResolver.getProjectStageAwarePropertyValue("xxx.rsalogin.url",
> "");{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1367) JNDI Config Source should support alternate JNDI base names
[ https://issues.apache.org/jira/browse/DELTASPIKE-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1367. --- Resolution: Won't Fix > JNDI Config Source should support alternate JNDI base names > --- > > Key: DELTASPIKE-1367 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1367 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.9.0 >Reporter: John Schneider >Assignee: Mark Struberg >Priority: Major > > JNDI Config is hard-coded to only support "java:comp/env/deltaspike/" as a > base name. This doesn't work for EAR deployments where we must have the > DeltaSpike jars deployed in top-level app lib directory with JNDI resource > reference in application.xml, for which name prefix is java:app/env > Furthermore, it's sometimes desirable to have server-level config, such as > for ProjectStage. For example, a JNDI name > java:global/env/deltaspike/org.apache.deltaspike/ProjectStage might be > defined at the server level configuration. > I understand a custom config source can be created to overcome this. > However, the standard JNDI config source should be more flexible. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1367) JNDI Config Source should support alternate JNDI base names
[
https://issues.apache.org/jira/browse/DELTASPIKE-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971181#comment-16971181
]
Mark Struberg commented on DELTASPIKE-1367:
---
Hi!
The problem is that this is really a chicken-egg issue. If we would make this
configurable, then which mechanism would you use to configure the base name?
In reality it is much simpler to just copy the source of
{{LocalJndiConfigSource}} and tweak it. It's just a few lines of code and the
most complex parts are already extracted into a reusable {{JndiUtils}} class.
> JNDI Config Source should support alternate JNDI base names
> ---
>
> Key: DELTASPIKE-1367
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1367
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: John Schneider
>Assignee: Mark Struberg
>Priority: Major
>
> JNDI Config is hard-coded to only support "java:comp/env/deltaspike/" as a
> base name. This doesn't work for EAR deployments where we must have the
> DeltaSpike jars deployed in top-level app lib directory with JNDI resource
> reference in application.xml, for which name prefix is java:app/env
> Furthermore, it's sometimes desirable to have server-level config, such as
> for ProjectStage. For example, a JNDI name
> java:global/env/deltaspike/org.apache.deltaspike/ProjectStage might be
> defined at the server level configuration.
> I understand a custom config source can be created to overcome this.
> However, the standard JNDI config source should be more flexible.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1395) specialized bean in jsf module are not available to EAR layer in wildfly 18
[
https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1395.
---
Assignee: Mark Struberg
Resolution: Not A Problem
Hi!
I'm sorry, but I have to close this ticket in DS. I think you hit an
unspecified case in CDI. In general the whole EAR scenario is sadly not really
well defined. Thus I understand why the Weld team did mark it as invalid as
well. But from a user point of view it of course should work. Glad you at least
found a workaround it seems.
> specialized bean in jsf module are not available to EAR layer in wildfly 18
> ---
>
> Key: DELTASPIKE-1395
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1395
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 1.9.1
> Environment: jboss EAP 7.2.4 / wildfly 18.0.0.Final
>Reporter: Xavier Mourgues
>Assignee: Mark Struberg
>Priority: Major
>
> Hello,ettings
>
> This is a follow-up of an [issue open to jboss
> weld|https://issues.jboss.org/browse/WELD-2601].
> When using deltaspike-core in an EAR and deltaspike-jsf-module in a WAR,
> there are some unsatisfied dependencies
> {code:java}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type LocaleResolver with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver
> at
> org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver(DefaultMessageContext.java:0)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
> at
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
> This is due to the use of @Specialized bean being in a module (the war) not
> visible/accessible by the injection point being in the EAR.
> On EAP 6.4 or jboss AS 7, after trying some simple use case, it appears that
> the resolved bean was always the @Specialized bean whether or not it was
> injected in the EAR layer or in the WAR layer. => I'm not sure this was the
> correct behavior anyway but it allowed the application to be deployed.
> On EAP 7.2.4 or wildfly 18.0.0.Final, the application doesn't even deploy due
> to the DeploymentException shown above.
>
> As a workaround, one can set-up a dependency from the ear deployment to the
> war subdeployment in the jboss-deployment-structure.xml (see below) but this
> break the EE spec as it gives the visibility of the war module to every other
> module in the application.
> {code:xml}
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> true
>
>
>export="true"/>
>
>
>
> {code}
>
> After some more test, it seems that using an @Alternative (and setting up in
> the beans.xml of the jsf-module web-fragment) in place of @Specialize would
> not cause a deployment problem but have the following behavior
> On EAP 7 / wildfly 18, injections point in the EAR are resolved to the
> "non-alternative" bean and injections point in the WAR are resolved to the
> @Alternative one => This looks like the coherent behavior
> On EAP 6 / AS 7, injections point in the EAR and in the WAR are bot resolved
> to the "non-alternative" bean => This isn't coherent, like with the
> @Specialize issue on this environment but in a different way which would
> probably fail some regression tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1393) POST request from a non-JSF to a JSF page fails with when ds:windowId is used
[
https://issues.apache.org/jira/browse/DELTASPIKE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971130#comment-16971130
]
Mark Struberg commented on DELTASPIKE-1393:
---
Hi Christian!
Do you have a ample already? There are basically 2 ways to deal with it:
a.) probably the WindowContext *should* be open?
b.) It should not and we should make this step optional. Means catching away
the ContxtNotActiveException).
To judge which one is more correct we first need to really understand your use
case!
> POST request from a non-JSF to a JSF page fails with when ds:windowId is used
> -
>
> Key: DELTASPIKE-1393
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1393
> Project: DeltaSpike
> Issue Type: Task
> Security Level: public(Regular issues)
> Components: JSF-Module
>Reporter: Christian Beikov
>Priority: Major
>
> When doing a POST request to a JSF page, I'm getting the following exception.
> This worked before withouth the ds:windowId tag. I will provide a PR showing
> the issue, but I'm not sure how this can be fixed yet. Obviously, one should
> use a GET request, but I have some legacy code that uses POST and it's hard
> to identify all cases. Would be great if we could solve this for other people.
> {noformat}
> org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active
> contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped
> at
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at
> org.apache.deltaspike.jsf.impl.token.PostRequestTokenManager$Proxy$_$$_WeldClientProxy.createNewToken(Unknown
> Source){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
