[jira] [Updated] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.

2019-06-26 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1383:
-
Fix Version/s: 1.9.1

> Authorizer is marked initialized before being fully initialed. 
> NullPointerException follows.
> 
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.9.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A 
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the 
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also 
> initialized in that method, and used elsewhere. Another thread can see the 
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is 
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
>    14:17:14.541  [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler 
> - java.lang.NullPointerException
>     org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at javax.servlet.FilterChain$doFilter.call(Unknown Source)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
>         at 
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
>         at 
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>         at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>         at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at 
> io.

[jira] [Resolved] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.

2019-06-26 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1383.
--
Resolution: Fixed

@[~hidde.wieringa]:
thx for providing the patch

> Authorizer is marked initialized before being fully initialed. 
> NullPointerException follows.
> 
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>    Assignee: Gerhard Petracek
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A 
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the 
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also 
> initialized in that method, and used elsewhere. Another thread can see the 
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is 
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
>    14:17:14.541  [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler 
> - java.lang.NullPointerException
>     org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at javax.servlet.FilterChain$doFilter.call(Unknown Source)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
>         at 
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
>         at 
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>         at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>         at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at 
> io.undert

[jira] [Commented] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.

2019-06-25 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872706#comment-16872706
 ] 

Gerhard Petracek commented on DELTASPIKE-1383:
--

@[~hidde.wieringa]:
thx for creating the pull-request.
(fyi: we currently re-visit the whole init-code)

it would be great if you can reword your commit-message.
our template:
DELTASPIKE-[xyz] [text]

> Authorizer is marked initialized before being fully initialed. 
> NullPointerException follows.
> 
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>    Assignee: Gerhard Petracek
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A 
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the 
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also 
> initialized in that method, and used elsewhere. Another thread can see the 
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is 
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
>    14:17:14.541  [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler 
> - java.lang.NullPointerException
>     org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at javax.servlet.FilterChain$doFilter.call(Unknown Source)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
>         at 
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
>         at 
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>         at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCa

[jira] [Assigned] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.

2019-06-25 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1383:


Assignee: Gerhard Petracek

> Authorizer is marked initialized before being fully initialed. 
> NullPointerException follows.
> 
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>    Assignee: Gerhard Petracek
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A 
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the 
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also 
> initialized in that method, and used elsewhere. Another thread can see the 
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is 
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
>    14:17:14.541  [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler 
> - java.lang.NullPointerException
>     org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
>         at 
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at javax.servlet.FilterChain$doFilter.call(Unknown Source)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
>         at 
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
>         at 
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
>         at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>         at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>         at 
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>         at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>         at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at 
> io.undert

[jira] [Assigned] (DELTASPIKE-1380) Concurrently initialization causes "Argument bean must not be null"

2019-05-22 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1380:


Assignee: Thomas Andraschko

> Concurrently initialization causes "Argument bean must not be null"
> ---
>
> Key: DELTASPIKE-1380
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1380
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Proxy-Module
>Affects Versions: 1.9.0
>Reporter: Jixing Wang
>Assignee: Thomas Andraschko
>Priority: Major
>
> lazyInit() is called concurrently, the first thread should be the only one to 
> initialize it; however, deltaSpikeProxyInvocationHandler has been assigned 
> before all initialization jobs are completed, which sometimes causes issue.
> Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: 
> Argument bean must not be null
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:708)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:87)
>  at 
> deployment.nyx.war//org.apache.deltaspike.proxy.api.DeltaSpikeProxyContextualLifecycle.instantiateDelegateInvocationHandler(DeltaSpikeProxyContextualLifecycle.java:177)
>  at 
> deployment.nyx.war//org.apache.deltaspike.proxy.api.DeltaSpikeProxyContextualLifecycle.create(DeltaSpikeProxyContextualLifecycle.java:94)
>  at 
> deployment.nyx.war//org.apache.deltaspike.core.util.bean.ImmutableBean.create(ImmutableBean.java:72)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:694)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:794)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.util.Beans.injectBoundFields(Beans.java:336)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:347)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.module.ejb.DynamicInjectionPointInjector.inject(DynamicInjectionPointInjector.java:61)
>  at 
> org.jboss.weld.core@3.1.0.Final//org.jboss.weld.module.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:138)
>  at 
> org.jboss.as.weld@16.0.0.Final//org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
>  at 
> org.jboss.as.weld@16.0.0.Final//org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
>  at 
> org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
>  at 
> org.jboss.as.ee@16.0.0.Final//org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
>  at 
> org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
>  at 
> org.jboss.as.weld@16.0.0.Final//org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
>  at 
> org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
>  at 
> org.jboss.as.ee@16.0.0.Final//org.jboss.as.ee.component.ComponentInstantiato

[jira] [Resolved] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1378.
--
Resolution: Fixed

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.9.0
>Reporter: Raymond Domingo
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 1.9.1
>
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839834#comment-16839834
 ] 

Gerhard Petracek commented on DELTASPIKE-1378:
--

[~rdomingonl]:
i've pushed the correct/ed fix (i've skipped the test, because it wasn't 
reproducible)
however, thx for reporting it

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.9.0
>Reporter: Raymond Domingo
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 1.9.1
>
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1378:
-
Flags:   (was: Patch,Important)

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Raymond Domingo
>Priority: Major
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1378:


Assignee: Thomas Andraschko

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.9.0
>Reporter: Raymond Domingo
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 1.9.1
>
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1378:
-
Fix Version/s: 1.9.1

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.9.0
>Reporter: Raymond Domingo
>Priority: Major
> Fix For: 1.9.1
>
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads

2019-05-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1378:
-
Affects Version/s: (was: 1.8.0)

> EntityManagerRefLookup returns null globalEntityManager when 
> lazyInitGlobalEntityManager is called by multiple threads
> --
>
> Key: DELTASPIKE-1378
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.9.0
>Reporter: Raymond Domingo
>Priority: Major
>
> *Situation*
> If multiple threads invoke lazyInitGlobalEntityManager at same time and 
> lazyInitGlobalEntityManager isn't invoked before. Some of these threads might 
> end up with a null entitymanager, because lazyInitGlobalEntityManager isn't 
> synchronized (or this.globalEntityManagerInitialized = true is at wrong 
> place).
> Might be *important* to fix this, because In rare situations this might break 
> your application and even cause inconsistent data.
> *Problem*
> entityManager is null after initialization is concurrently called
> *Expected*
> entityManager won't be null when initialized concurrently
>  
> *PR*
> [https://github.com/apache/deltaspike/pull/89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [VOTE] Move our git repo to Apache gitbox

2019-01-07 Thread Gerhard Petracek
+1

regards,
gerhard



Am Mo., 7. Jan. 2019 um 18:08 Uhr schrieb Mark Struberg
:

> Hi folks!
>
> I've made good experience with gitbox in other ASF projects.
> I'd say we just call it 'deltaspike' as is. We just have one repo, so that
> would be a 1:1 migration.
> As with everything GIT the sha1 doesn'T change anyway...
>
> Can I pull the trigger?
>
> Here is my +1
>
> The VOTE is open for 72h
>
> LieGrue,
> strub
>
> > Am 03.01.2019 um 14:19 schrieb Apache Infrastructure Team <
> infrastruct...@apache.org>:
> >
> > Hello, deltaspike folks.
> > As stated earlier in 2018, all git repositories must be migrated from
> > the git-wip-us.apache.org URL to gitbox.apache.org, as the old service
> > is being decommissioned. Your project is receiving this email because
> > you still have repositories on git-wip-us that needs to be migrated.
> >
> > The following repositories on git-wip-us belong to your project:
> > - deltaspike.git
> >
> >
> > We are now entering the mandated (coordinated) move stage of the roadmap,
> > and you are asked to please coordinate migration with the Apache
> > Infrastructure Team before February 7th. All repositories not migrated
> > on February 7th will be mass migrated without warning, and we'd
> appreciate
> > it if we could work together to avoid a big mess that day :-).
> >
> > Moving to gitbox means you will get full write access on GitHub as well,
> > and be able to close/merge pull requests and much more.
> >
> > To have your repositories moved, please follow these steps:
> >
> > - Ensure consensus on the move (a link to a lists.apache.org thread will
> >  suffice for us as evidence).
> > - Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA
> >
> > Your migration should only take a few minutes. If you wish to migrate
> > at a specific time of day or date, please do let us know in the ticket.
> >
> > As always, we appreciate your understanding and patience as we move
> > things around and work to provide better services and features for
> > the Apache Family.
> >
> > Should you wish to contact us with feedback or questions, please do so
> > at: us...@infra.apache.org.
> >
> >
> > With regards,
> > Apache Infrastructure
> >
>
>


[jira] [Commented] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category

2018-11-09 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682090#comment-16682090
 ] 

Gerhard Petracek commented on DELTASPIKE-1348:
--

[~famod]: thx for the info!

> Deltaspike is unusable with junit's @category
> -
>
> Key: DELTASPIKE-1348
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Lonzak
>Priority: Major
>  Labels: category, cdi, junit, test
> Fix For: 1.9.1
>
>
> A while ago we separated our tests in standard junit- and integration tests 
> using junit's category mechanism: 
> ([https://dzone.com/articles/unit-and-integration-tests)|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html)]
>  
> The goal: When maven 'package' is used, then all tests annotated with 
> @category are skipped. When using 'install' they are executed. If in either 
> build a junit test fails, the build fails.
> So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism 
> doesn't work anymore:
>  # The integration tests are always executed ignoring the build phase 
> (package, install...)
>  # If the integration fails the build doesn't fail.
> We were using the "RunWith" before so I think it is not a junit problem. I 
> did some research but only gradle seemed to had a similar problem 
> ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321])
> Any ideas how to get it to work again?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1361) improved handling per ds-test

2018-10-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1361.
--
Resolution: Fixed

> improved handling per ds-test
> -
>
> Key: DELTASPIKE-1361
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1361
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: TestControl
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.9.1
>
>
> in some cases the RunListener can "leak" to plain junit tests which leads to 
> ds-log-entries (which are mainly useful for cdi-based tests in combination 
> with external containers) also in case of plain junit tests. furthermore, the 
> cleanup of ThreadLocal should be unified.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1361) improved handling per ds-test

2018-10-31 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1361:


 Summary: improved handling per ds-test
 Key: DELTASPIKE-1361
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1361
 Project: DeltaSpike
  Issue Type: Improvement
  Components: TestControl
Affects Versions: 1.9.0
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.9.1


in some cases the RunListener can "leak" to plain junit tests which leads to 
ds-log-entries (which are mainly useful for cdi-based tests in combination with 
external containers) also in case of plain junit tests. furthermore, the 
cleanup of ThreadLocal should be unified.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DELTASPIKE-1360) NPE at resolveEntityManagerBeans during heavy load

2018-10-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1360:


Assignee: Romain Manni-Bucau  (was: John D. Ament)

> 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.Servi

[jira] [Assigned] (DELTASPIKE-1360) NPE at resolveEntityManagerBeans during heavy load

2018-10-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1360:


Assignee: John D. Ament

> 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: John D. Ament
>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.Servi

[jira] [Updated] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7

2018-10-25 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1359:
-
Priority: Minor  (was: Major)

> 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
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7

2018-10-25 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1359:
-
Issue Type: Bug  (was: Improvement)

> 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: Major
>
> 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
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1359) deltaspike-data-module-test-ee7

2018-10-25 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663472#comment-16663472
 ] 

Gerhard Petracek commented on DELTASPIKE-1359:
--

i've updated the pom manually

> deltaspike-data-module-test-ee7
> ---
>
> Key: DELTASPIKE-1359
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
>Priority: Major
>
> 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
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7

2018-10-25 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1359:
-
Summary: wrong parent version of deltaspike-data-module-test-ee7  (was: 
deltaspike-data-module-test-ee7)

> 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: Improvement
>  Components: Data-Module
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
>Priority: Major
>
> 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
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1359) deltaspike-data-module-test-ee7

2018-10-25 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1359:


 Summary: deltaspike-data-module-test-ee7
 Key: DELTASPIKE-1359
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.9.0
Reporter: Gerhard Petracek
Assignee: Mark Struberg


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
(v7.6.3#76005)


Re: [VOTE] Release Apache DeltaSpike-1.9.0 (take2)

2018-09-10 Thread Gerhard Petracek
+1

regards,
gerhard



Am Mo., 10. Sep. 2018 um 08:54 Uhr schrieb Mark Struberg
:

> Good morning!
>
> This is the second release attempt for DeltaSpike 1.9.0.
>
> John discovered that we missed a license header in the first run.
> This is fixed now - thanks John for the catch!
> I've also enabled the apache-rat-plugin to run every time and not only in
> a dedicated profile.
>
>
> The staging repo can be found here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/
>
> The source release zip is here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/org/apache/deltaspike/deltaspike/1.9.0/
> sha1
> :
> 18d39411a60b4cc6a5af2ab261b4f7cde8692096
>
> The following tickets got resolved since 1.8.2 (same as in the first take):
>
> Bug
>
> • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> with multiple EntityManagers
> • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> after container shutdown
> • [DELTASPIKE-1324] - @Transactional annotation at method level
> doesn't override the one at class level any more
> • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> scannable?
> • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> depends on weld-api 1.1.Final
> • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> runtime dependency on Shrinkwrap and Arquillian
> • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> Object.class
> • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> ClassReader.
> • [DELTASPIKE-1353] - null values as arguments in messagebundles
> lead to exceptions
> New Feature
>
> • [DELTASPIKE-1280] - Automatic support for count* methods in
> EntityRepository
> • [DELTASPIKE-1315] - EntityRepository should offer an
> findOptionalBy
> • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> minimum version
> • [DELTASPIKE-1335] - allow atomic access to n different
> TypedResolver values
> Improvement
>
> • [DELTASPIKE-1277] - Force refresh of cached config values
> • [DELTASPIKE-1322] - clean up ConfigResolver
> • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> • [DELTASPIKE-1339] - Add support for dynamic interceptor binding,
> added via Extension
> • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> QueryProcessors
> • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> values only if the value changed
> Task
>
> • [DELTASPIKE-1308] - Documentation of user home properties
> mechanism
> • [DELTASPIKE-1325] - actively release ConfigSources and
> ConfigFilters if they implement Autocloseable
>
>
> Please VOTE:
>
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
>
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub


Re: [VOTE] Release Apache DeltaSpike 1.9.0

2018-09-09 Thread Gerhard Petracek
+1

regards,
gerhard



Am Fr., 7. Sep. 2018 um 14:04 Uhr schrieb Mark Struberg
:

> Good afternoon!
>
> I'd like to call a VOTE on releasing Apache DeltaSpike 1.9.0.
> This is the first version which requires Java8 as minimum Java version!
> Apart from that it introduces a new SPI for our configuration system and
> the ability to better deal with dynamic configuration values.
>
> The staging repo can be found here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/
>
> The source release zip is here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/org/apache/deltaspike/deltaspike/1.9.0/
> sha1
> :
> d83b8174b2eaac0071606428dfc9792f8d0c6ff5
>
> The following tickets got resolved since 1.8.2:
>
> Bug
>
> • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> with multiple EntityManagers
> • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> after container shutdown
> • [DELTASPIKE-1324] - @Transactional annotation at method level
> doesn't override the one at class level any more
> • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> scannable?
> • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> depends on weld-api 1.1.Final
> • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> runtime dependency on Shrinkwrap and Arquillian
> • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> Object.class
> • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> ClassReader.
> • [DELTASPIKE-1353] - null values as arguments in messagebundles
> lead to exceptions
> New Feature
>
> • [DELTASPIKE-1280] - Automatic support for count* methods in
> EntityRepository
> • [DELTASPIKE-1315] - EntityRepository should offer an
> findOptionalBy
> • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> minimum version
> • [DELTASPIKE-1335] - allow atomic access to n different
> TypedResolver values
> Improvement
>
> • [DELTASPIKE-1277] - Force refresh of cached config values
> • [DELTASPIKE-1322] - clean up ConfigResolver
> • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> • [DELTASPIKE-1339] - Add support for dynamic interceptor binding,
> added via Extension
> • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> QueryProcessors
> • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> values only if the value changed
> Task
>
> • [DELTASPIKE-1308] - Documentation of user home properties
> mechanism
> • [DELTASPIKE-1325] - actively release ConfigSources and
> ConfigFilters if they implement Autocloseable
>
>
> Please VOTE:
>
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
>
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>
>


[jira] [Comment Edited] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category

2018-08-18 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584920#comment-16584920
 ] 

Gerhard Petracek edited comment on DELTASPIKE-1348 at 8/18/18 8:42 PM:
---

@[~tom_1st]:
i just selected a target-version for that ticket


was (Author: gpetracek):
[~tom_1st]:
i just selected a target-version for that ticket

> Deltaspike is unusable with junit's @category
> -
>
> Key: DELTASPIKE-1348
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Lonzak
>Priority: Major
>  Labels: category, cdi, junit, test
> Fix For: 1.9.1
>
>
> A while ago we separated our tests in standard junit- and integration tests 
> using junit's category mechanism: 
> ([https://dzone.com/articles/unit-and-integration-tests)|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html)]
>  
> The goal: When maven 'package' is used, then all tests annotated with 
> @category are skipped. When using 'install' they are executed. If in either 
> build a junit test fails, the build fails.
> So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism 
> doesn't work anymore:
>  # The integration tests are always executed ignoring the build phase 
> (package, install...)
>  # If the integration fails the build doesn't fail.
> We were using the "RunWith" before so I think it is not a junit problem. I 
> did some research but only gradle seemed to had a similar problem 
> ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321])
> Any ideas how to get it to work again?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category

2018-08-18 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584920#comment-16584920
 ] 

Gerhard Petracek commented on DELTASPIKE-1348:
--

[~tom_1st]:
i just selected a target-version for that ticket

> Deltaspike is unusable with junit's @category
> -
>
> Key: DELTASPIKE-1348
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Lonzak
>Priority: Major
>  Labels: category, cdi, junit, test
> Fix For: 1.9.1
>
>
> A while ago we separated our tests in standard junit- and integration tests 
> using junit's category mechanism: 
> ([https://dzone.com/articles/unit-and-integration-tests)|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html)]
>  
> The goal: When maven 'package' is used, then all tests annotated with 
> @category are skipped. When using 'install' they are executed. If in either 
> build a junit test fails, the build fails.
> So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism 
> doesn't work anymore:
>  # The integration tests are always executed ignoring the build phase 
> (package, install...)
>  # If the integration fails the build doesn't fail.
> We were using the "RunWith" before so I think it is not a junit problem. I 
> did some research but only gradle seemed to had a similar problem 
> ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321])
> Any ideas how to get it to work again?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1338) support class-filter per test

2018-08-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580810#comment-16580810
 ] 

Gerhard Petracek commented on DELTASPIKE-1338:
--

@[~manovotn]:
if you mean that a #veto isn't allowed for alternative beans then i agree with 
[~struberg] (that such a rule is useless).

in any case the "main" use-case uses @Priority, we just can't use it in the 
test-suite currently, because the min. spec. level is still 1.0.

> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per 
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build 
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter 
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter = 
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter 
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to 
> alternative-beans).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: Welcome Alex Falb as new Apache DeltaSpike

2018-08-07 Thread Gerhard Petracek
welcome!

regards,
gerhard



Am Di., 7. Aug. 2018 um 08:09 Uhr schrieb Mark Struberg
:

> Dear fellow Apache DeltaSpike users and devs.
>
> The Apache DeltaSpike PMC has voted on inviting Alex Falb as a new
> committer to our project and he has accepted our invitation.
>
>
> Welcome Alex!
>
>
> the Apache DeltaSpike PMC


[jira] [Assigned] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions

2018-07-16 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1353:


Assignee: Mark Struberg

> null values as arguments in messagebundles lead to exceptions
> -
>
> Key: DELTASPIKE-1353
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Attachments: 
> org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt, 
> org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
>
>
> When using a Deltaspike Messagebundle and feeding {{null}} as argument to 
> some non-String argument, the MessageInterpolators throw Exceptions. 
> Depending if I use the MessageFormatter or the String.format based 
> Interpolater the Exceptions differ, but origin from the same misassumption, 
> that {{null}} can be replaced with {{"'null'"}} 
> (MessageBundleInvocationHandler:179)
> I created 2 unittests to showcase this behaviour, see attached surefire logs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1350) TransactionalInterceptor should use the EntityManagerResolver for lookups

2018-06-29 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528507#comment-16528507
 ] 

Gerhard Petracek commented on DELTASPIKE-1350:
--

please provide further details why you would like to get rid of a std. EM 
producer which just adds ~2-3 lines per EM per application.

@NPE:
for the constellation you described, it's the behavior defined by cdi itself.

> TransactionalInterceptor should use the EntityManagerResolver for lookups
> -
>
> Key: DELTASPIKE-1350
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1350
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JPA-Module
>Affects Versions: 1.8.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I'm trying to use the transaction support from the JPA module with multiple 
> entity managers that are created by a producer defined in a separate/common 
> module.
> That means that any specific qualifiers defined in the client modules (like 
> {{@DbA}} / {{@DbB}}{{ from the examples) are not visible to the producer. To 
> make this work, I've followed the approach from the 
> EntityManagerFactoryProducer}} and I've defined my own qualifier, 
> {{PersistenceContextName}}, duplicated from {{PersistenceUnitName}} (and 
> similar to the {{CustomQualifier}} from the example).
> I've also created an {{EntityManagerResolver}} in one of the client modules 
> and configured it in the DAOs inside it (which are not DeltaSpike 
> repositories), with {{@Transactional}} and 
> {{@EntityManagerConfig(entityManagerResolver = 
> BranchManagementResolver.class, qualifier = PersistenceContextName.class)}}
> As far as I see, only the {{qualifier}} attribute is used, but it invokes my 
> producer with a {{null}} {{InjectionPoint}}:
> {noformat}
> java.lang.NullPointerException: null
>     at 
> EntityManagerProducer.getEntityManagerFactory(EntityManagerProducer.java:109) 
> ~[server-core-impl-1.0.21-SNAPSHOT.jar:?]
>     at 
> EntityManagerProducer.createEntityManager(EntityManagerProducer.java:95) 
> ~[server-core-impl-1.0.21-SNAPSHOT.jar:?]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_172]
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_172]
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_172]
>     at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_172]
>     at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:103)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:180)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:700) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:723) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:86)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManager(QualifierBackedEntityManagerResolver.java:59)
>  ~[deltaspike-jpa-module-api-1.8.2.jar:1.8.2]
>     at 
> org.apache.delta

[jira] [Assigned] (DELTASPIKE-1351) Java 10: IllegalArgumentException in ClassReader.

2018-06-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1351:


Assignee: Thomas Andraschko

> Java 10: IllegalArgumentException in ClassReader.
> ---
>
> Key: DELTASPIKE-1351
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1351
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Proxy-Module
>Affects Versions: 1.8.2
>Reporter: Florian Lieb
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 1.9.0
>
>
> With java10, we get an exception
> {code:java}
> Caused by: java.lang.IllegalArgumentException
> at org.apache.deltaspike.proxy.asm.ClassReader.(ClassReader.java:160)
> at org.apache.deltaspike.proxy.asm.ClassReader.(ClassReader.java:143)
> at org.apache.deltaspike.proxy.asm.ClassReader.(ClassReader.java:418)
> at 
> org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator.generateProxyClassBytes(AsmDeltaSpikeProxyClassGenerator.java:154)
> ... 51 more
> at 
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> at 
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:61)
> at 
> org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:420){code}
>  
> Since ASM is shaded within deltaspike-proxy-asm, it is impossible to update 
> ASM to a more recent version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1350) TransactionalInterceptor should use the EntityManagerResolver for lookups

2018-06-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525983#comment-16525983
 ] 

Gerhard Petracek commented on DELTASPIKE-1350:
--

please have a look at:
http://deltaspike.apache.org/documentation/jpa.html#MultipleEntityManagers

and if you need it in combination with the data-module also:
https://issues.apache.org/jira/browse/DELTASPIKE-1062

> TransactionalInterceptor should use the EntityManagerResolver for lookups
> -
>
> Key: DELTASPIKE-1350
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1350
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JPA-Module
>Affects Versions: 1.8.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I'm trying to use the transaction support from the JPA module with multiple 
> entity managers that are created by a producer defined in a separate/common 
> module.
> That means that any specific qualifiers defined in the client modules (like 
> {{@DbA}} / {{@DbB}}{{}} from the examples) are not visible to the producer. 
> To make this work, I've followed the approach from the 
> {{EntityManagerFactoryProducer}} and I've defined my own qualifier, 
> {{PersistenceContextName}}, duplicated from {{PersistenceUnitName}} (and 
> similar to the {{CustomQualifier}} from the example).
> I've also created an {{EntityManagerResolver}} in one of the client modules 
> and configured it in the DAOs inside it (which are not DeltaSpike 
> repositories), with {{@Transactional}} and 
> {{@EntityManagerConfig(entityManagerResolver = 
> BranchManagementResolver.class, qualifier = PersistenceContextName.class)}}
> As far as I see, only the {{qualifier}} attribute is used, but it invokes my 
> producer with a {{null}} {{InjectionPoint}}:
> {noformat}
> java.lang.NullPointerException: null
>     at 
> EntityManagerProducer.getEntityManagerFactory(EntityManagerProducer.java:109) 
> ~[server-core-impl-1.0.21-SNAPSHOT.jar:?]
>     at 
> EntityManagerProducer.createEntityManager(EntityManagerProducer.java:95) 
> ~[server-core-impl-1.0.21-SNAPSHOT.jar:?]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_172]
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_172]
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_172]
>     at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_172]
>     at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:103)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:180)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:700) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:723) 
> ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:86)
>  ~[weld-core-impl-3.0.4.Final.jar:3.0.4.Final]
>     at 
> org.apache.deltaspike.jpa.spi.entitymanager.QualifierBackedEntityManagerResolver.resolveEntityManager(QualifierBackedEntityManagerResolver.java:59)
>  ~[deltaspike-jpa-module-api-1.8.2.jar:1.8.2]
>     at 
> org.apache.delta

[jira] [Updated] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category

2018-06-23 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1348:
-
Fix Version/s: 1.9.1

> Deltaspike is unusable with junit's @category
> -
>
> Key: DELTASPIKE-1348
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Lonzak
>Priority: Major
>  Labels: category, cdi, junit, test
> Fix For: 1.9.1
>
>
> A while ago we separated our tests in standard junit- and integration tests 
> using junit's category mechanism: 
> ([https://dzone.com/articles/unit-and-integration-tests)|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html)]
>  
> The goal: When maven 'package' is used, then all tests annotated with 
> @category are skipped. When using 'install' they are executed. If in either 
> build a junit test fails, the build fails.
> So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism 
> doesn't work anymore:
>  # The integration tests are always executed ignoring the build phase 
> (package, install...)
>  # If the integration fails the build doesn't fail.
> We were using the "RunWith" before so I think it is not a junit problem. I 
> did some research but only gradle seemed to had a similar problem 
> ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321])
> Any ideas how to get it to work again?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: CI for Weld2 error

2018-06-11 Thread Gerhard Petracek
@mark: +1

we do add @Priority dynamically >if< it is available (in case of global
alternatives).
however, in case of @Exclude we need for sure ProcessAnnotatedType#veto.
there is no way around it (by definition)...

regards,
gerhard



2018-06-08 17:42 GMT+02:00 Mark Struberg :

> Well, Weld2 follows the CDI-1.2 spec wording. Which is actively
> contradicts the CDI-1.0 spec - which is forbidden by the JCP rules.
> So Weld2 _could_ behave correctly. Just apply the changes you did for
> Weld3.
>
> Otoh this is just a test in DeltaSpike.
> The point is that I really have no idea how we can make this test pass :(
> Happy to get hints!
>
> LieGrue,
> strub
>
> > Am 08.06.2018 um 09:43 schrieb Matej Novotny :
> >
> > What tests are you talking about now?
> > Is it those in DS-1338?
> >
> > BTW in regards to CDI-627, I can see the reason for that issue and the
> use case behind it, yet Weld behaves correctly - it follows what the spec
> says.
> > Though if you have such a test in DS, I am not really sure how to fix
> that to make it work on both versions...
> >
> > Matej
> >
> > - Original Message -
> >> From: "Mark Struberg" 
> >> To: "deltaspike" 
> >> Sent: Friday, June 8, 2018 8:33:27 AM
> >> Subject: Re: CI for Weld2 error
> >>
> >> I tried a few Weld2 versions and all are hit by it.
> >>
> >> I now dug into the CDI spec archive and found an old bug from 2016
> >> https://issues.jboss.org/browse/CDI-627
> >>
> >> A backward incompatible (and thus void) change was introduced in the
> >> alternatives in beans.xml handling in CDI-1.2.
> >> We reverted and fixed the wording in CDI-2.0 again.
> >> But it seems that Weld-2 still follows the broken (illegal and void
> regarding
> >> to JCP rules) CDI-1.2 spec wording.
> >>
> >> I'd say we could try to rewrite our tests to avoid this scenario but I
> have
> >> honestly no clue how!
> >> We cannot use @Priority as we could not run on EE6 anymore. And the
> test is
> >> actually correct - it's reallly a Weld bug!
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 08.06.2018 um 02:28 schrieb John D. Ament :
> >>>
> >>> What versions of weld 2 have you tried?
> >>>
> >>> On Thu, Jun 7, 2018, 5:11 PM Mark Struberg 
> >>> wrote:
> >>>
>  Hi!
> 
>  I've tried to fix the CI for Weld2, but it seems that there is nothing
>  wrong with DeltaSpike but a bug in Weld2 regarding alternatives in
>  beans.xml if they get disabled via ProcessAnnotatedType#veto(). Weld
> 1 and
>  Weld3 both work perfectly fine, as does various OWB versions.
> 
>  What to do?
> 
>  LieGrue,
>  strub
> >>
> >>
>
>


Re: Working towards a DeltaSpike-1.9.0 release?

2018-05-28 Thread Gerhard Petracek
+1

regards,
gerhard



2018-05-28 8:48 GMT+02:00 Mark Struberg :

> Hi lords and ladies!
>
> I'd love to start a DeltaSpike-1.9.0 release soon.
> What do we miss for it?
>
> On my personal list I'd love to review/improve the dynamic Config handling
> a bit.
> Everything else is set.
>
> Wdyt about a release?
> What is missing in other areas?
>
> txs and LieGrue,
> strub


[jira] [Resolved] (DELTASPIKE-1346) ProjectStageProducer should log changed values only if the value changed

2018-05-26 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1346.
--
Resolution: Fixed

> ProjectStageProducer should log changed values only if the value changed
> 
>
> Key: DELTASPIKE-1346
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1346
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.2
>Reporter: Jens Berke
>    Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.9.0
>
>
> The change in DELTASPIKE-1329 logs a message every time the project stage is 
> set, even is the new value is the same as the previous one, and it can flood 
> your log with numerous messages "change project-stage from UnitTest to 
> UnitTest" when running unit tests.
> I think it's better if the message is only logged if the new value is 
> actually different from the previous one - which also seems to have been the 
> intention of DELTASPIKE-1329 according to its summary. 
> Example for an implementation:
> {code:java}
> String psNameOld = projectStage == null ? "" : projectStage.toString();
> String psNameNew = ps == null ? "" : ps.toString();
> if (!psNameNew.equals(psNameOld)) {
>     LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}
> For DeltaSpike versions which require at least Java 1.7. and later, and if 
> ProjectStage had a proper equals method, this could be simplified to:
> {code:java}
> if (!Objects.equals(projectStage, ps)) {
> LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1346) ProjectStageProducer should log changed values only if the value changed

2018-05-26 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1346:
-
Fix Version/s: 1.9.0

> ProjectStageProducer should log changed values only if the value changed
> 
>
> Key: DELTASPIKE-1346
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1346
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.2
>Reporter: Jens Berke
>    Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.9.0
>
>
> The change in DELTASPIKE-1329 logs a message every time the project stage is 
> set, even is the new value is the same as the previous one, and it can flood 
> your log with numerous messages "change project-stage from UnitTest to 
> UnitTest" when running unit tests.
> I think it's better if the message is only logged if the new value is 
> actually different from the previous one - which also seems to have been the 
> intention of DELTASPIKE-1329 according to its summary. 
> Example for an implementation:
> {code:java}
> String psNameOld = projectStage == null ? "" : projectStage.toString();
> String psNameNew = ps == null ? "" : ps.toString();
> if (!psNameNew.equals(psNameOld)) {
>     LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}
> For DeltaSpike versions which require at least Java 1.7. and later, and if 
> ProjectStage had a proper equals method, this could be simplified to:
> {code:java}
> if (!Objects.equals(projectStage, ps)) {
> LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-26 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491759#comment-16491759
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

ds supports cdi2 also out-of-the-box (and the bridge as well).

fyi: i pushed some improvements (including additional examples) and published 
http://os890.blogspot.com/2018/05/add-on-javaxannotationsecurity-with.html

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Assignee: Gerhard Petracek
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-25 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490419#comment-16490419
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

[~princemtl]:
i agree that the spec. wording for @RunAs isn't as clear as it should be, but 
all other parts (the only spec. example, all vendor-javadocs i found) clearly 
limit it to a role-value (and not a principal). i guess that's also the reason 
why there is e.g. org.jboss.ejb3.annotation.RunAsPrincipal.
in any case supporting the principal here would be possible (depending on the 
proprietary container-api), but not portable.

@"#1": ... is the cdi 1.1+ api topic (the baseline for ds is 1.0 and 1.1+ is 
supported via 1-2 workarounds using reflection)
@"#2": ... is the javax.annotation-api topic
(both mentioned in the same comment directly before...)

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Assignee: Gerhard Petracek
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DELTASPIKE-1347) DeltaSpike Window Scope doesn't work with IE 11 sometimes

2018-05-24 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1347:


Assignee: Thomas Andraschko

> DeltaSpike Window Scope doesn't work with IE 11 sometimes
> -
>
> Key: DELTASPIKE-1347
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1347
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Udo Schnurpfeil
>Assignee: Thomas Andraschko
>Priority: Minor
>
> I found a problem with the window id and *IE11*, described in TOBAGO-1901.
> I've tested the example of deltaspike current version:
> {code}
> $ cd deltaspike/examples/jsf-playground
> $ mvn clean package tomee:run -Prun-tomee-1.7.2
> {code}
> Browse with IE to:
> {code}
> http://10.211.55.2:8080/ds/views/windowhandling/clientwindow/test.xhtml
> {code}
> Clicking "GET Link", "Postback" or "Postback with outcome" will generate a 
> new window id, every click.
> The bug doesn't happen, when opening the F12 tool, which make it tricky to 
> debug.
> The bug doesn't happen, when adding the URL in the trusted sites 
> configuration of IE. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-24 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489571#comment-16489571
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

[~princemtl]:
i've prototyped a cdi-role-bridge (as ds-addon) at 
https://github.com/os890/ds-role-bridge-addon
it supports @DenyAll, @PermitAll, @RolesAllowed and @RunAs and works without an 
additional api (and without mandatory config).

the demo-app (based on meecrowave) allows to check different 
role-constellations (at runtime).
i also tested it in combination with ejbs (a corresponding demo-app might 
follow).

the addon is based on cdi 1.2 (+ ds 1.x) and for sure it requires 
javax.annotation-api.
for ds we could get over #1 (with the same workarounds we use already to 
support v1.1+).
however, #2 would mean to use a significant amount of reflection or we provide 
a separated authentication-impl-module.


> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Assignee: Gerhard Petracek
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1346) ProjectStageProducer should log changed values only if the value changed

2018-05-23 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1346:
-
Issue Type: Improvement  (was: Bug)

> ProjectStageProducer should log changed values only if the value changed
> 
>
> Key: DELTASPIKE-1346
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1346
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.2
>Reporter: Jens Berke
>Priority: Minor
>
> The change in DELTASPIKE-1329 logs a message every time the project stage is 
> set, even is the new value is the same as the previous one, and it can flood 
> your log with numerous messages "change project-stage from UnitTest to 
> UnitTest" when running unit tests.
> I think it's better if the message is only logged if the new value is 
> actually different from the previous one - which also seems to have been the 
> intention of DELTASPIKE-1329 according to its summary. 
> Example for an implementation:
> {code:java}
> String psNameOld = projectStage == null ? "" : projectStage.toString();
> String psNameNew = ps == null ? "" : ps.toString();
> if (!psNameNew.equals(psNameOld)) {
>     LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}
> For DeltaSpike versions which require at least Java 1.7. and later, and if 
> ProjectStage had a proper equals method, this could be simplified to:
> {code:java}
> if (!Objects.equals(projectStage, ps)) {
> LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DELTASPIKE-1346) ProjectStageProducer should log changed values only if the value changed

2018-05-23 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1346:


Assignee: Gerhard Petracek

> ProjectStageProducer should log changed values only if the value changed
> 
>
> Key: DELTASPIKE-1346
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1346
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.2
>Reporter: Jens Berke
>    Assignee: Gerhard Petracek
>Priority: Minor
>
> The change in DELTASPIKE-1329 logs a message every time the project stage is 
> set, even is the new value is the same as the previous one, and it can flood 
> your log with numerous messages "change project-stage from UnitTest to 
> UnitTest" when running unit tests.
> I think it's better if the message is only logged if the new value is 
> actually different from the previous one - which also seems to have been the 
> intention of DELTASPIKE-1329 according to its summary. 
> Example for an implementation:
> {code:java}
> String psNameOld = projectStage == null ? "" : projectStage.toString();
> String psNameNew = ps == null ? "" : ps.toString();
> if (!psNameNew.equals(psNameOld)) {
>     LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}
> For DeltaSpike versions which require at least Java 1.7. and later, and if 
> ProjectStage had a proper equals method, this could be simplified to:
> {code:java}
> if (!Objects.equals(projectStage, ps)) {
> LOG.info("change project-stage from " + projectStage + " to " + ps);
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-22 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1345:


Assignee: Gerhard Petracek

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Assignee: Gerhard Petracek
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483047#comment-16483047
 ] 

Gerhard Petracek edited comment on DELTASPIKE-1345 at 5/21/18 8:50 PM:
---

[~princemtl]:
that's why i said +HttpServletRequest (and/or EjbContext), because i just 
pointed to something which is out there already...
i never used it in a project (only @Secured), one of the ds-committers (rafael) 
did the example, but it should be possible (at least i'm not aware of an 
intended limitation).
"more code": if you count type-safe annotations representing your own roles - 
then: yes (but at the same time it's more flexible) than a predefined 
interceptor


was (Author: gpetracek):
[~princemtl]:
i never used it in a project (only @Secured), one of the ds-committers (rafael) 
did the example, but it should be possible (at least i'm not aware of an 
intended limitation).
"more code": if you count type-safe annotations representing your own roles - 
then: yes (but at the same time it's more flexible) than a predefined 
interceptor

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483047#comment-16483047
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

[~princemtl]:
i never used it in a project (only @Secured), one of the ds-committers (rafael) 
did the example, but it should be possible (at least i'm not aware of an 
intended limitation).
"more code": if you count type-safe annotations representing your own roles - 
then: yes (but at the same time it's more flexible) than a predefined 
interceptor

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482996#comment-16482996
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

[~princemtl]:
yes i know, i was also surprised that "nobody" published such an integration.
however, the main question is if 
https://github.com/wildfly/quickstart/blob/master/deltaspike-authorization/src/main/java/org/jboss/as/quickstarts/deltaspike/authorization/CustomAuthorizer.java
 (+ e.g. HttpServletRequest), isn't just better than those (outdated) 
annotations (since you still use the HttpServletRequest#isUserInRole and/or 
EjbContext#isCallerInRole).

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482902#comment-16482902
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

the consensus we had back then was that we only provide logic which allows to 
implement adapters. that was also the reason for dropping a lot again (which 
was moved to picketlink afterwards).

the approach shown by 
https://github.com/wildfly/quickstart/blob/master/deltaspike-authorization/src/main/java/org/jboss/as/quickstarts/deltaspike/authorization/CustomAuthorizer.java
 is more cdi-like. with an useful documentation it's really simple, well 
integrated and even better than @RolesAllowed.

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482836#comment-16482836
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

it would mean the usage of quite a bit reflection - the lookup order would be:
# dyn. lookup of HttpServletRequest
# dyn lookup of HttpServletRequest + @DeltaSpike (if the servlet-module is 
available)
# dyn lookup of the ejb-helper

techn. we could even add the interceptor dyn., however, i haven't started with 
it because there is a quite simple alternative to it - see e.g.: 
https://github.com/wildfly/quickstart/blob/master/deltaspike-authorization/src/main/java/org/jboss/as/quickstarts/deltaspike/authorization/CustomAuthorizer.java

instead of FacesContext, you can use the HttpServletRequest or the helper-ejb 
easily.

so maybe we should just promote it to our documentation.

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482812#comment-16482812
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

the point is that we don't have access to an injected HttpServletRequest with 
our baseline (without the servlet-module).
we can use both for the evaluation (if one of them isn't available. in an 
ee-server the approach via an ejb is compatible with our baseline).

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

2018-05-21 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482771#comment-16482771
 ] 

Gerhard Petracek commented on DELTASPIKE-1345:
--

i thought about almost the same last week.
however, we would need to add it to the servlet-module.
the alternative would be the injection of an ejb to delegate the evaluation to 
EjbContext#isCallerInRole

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [VOTE] Release Apache DeltaSpike-1.8.2

2018-05-15 Thread Gerhard Petracek
+1

regards,
gerhard



2018-05-15 23:26 GMT+02:00 Mark Struberg :

> Hi lords and ladies!
>
> I would like to call a VOTE on releasing Apache DeltaSpike-1.8.2.
> This is a maintenance release with java6 compatibility.
>
> The following tickets got resolved:
>
> Bug
>
> [DELTASPIKE-1276] - Multiple license headers
> [DELTASPIKE-1299] - Order by items are applied in alphabetic order
> [DELTASPIKE-1310] - Please use https (SSL) for links to KEYS, hashes,
> sigs
> [DELTASPIKE-1313] - DeltaSpikeProxyInterceptorLookup fails on WAS
> [DELTASPIKE-1316] - add dynamic annotations feature, configurable via
> config
> [DELTASPIKE-1317] - AnnotatedCallableImpl blows up with
> ArrayOutofBounds when parsing enums
> [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient runtime
> dependency on Shrinkwrap and Arquillian
>
> New Feature
>
> [DELTASPIKE-1319] - labeled alternatives
> [DELTASPIKE-1320] - global alternative spi to support custom
> (type-safe) mechanisms
> [DELTASPIKE-1337] - optional ClassFilter spi
> [DELTASPIKE-1338] - support class-filter per test
>
> Improvement
>
> [DELTASPIKE-1309] - Upgrade ASM
> [DELTASPIKE-1311] - Allow Excluded Repositories
> [DELTASPIKE-1329] - ProjectStageProducer should log changed values
> [DELTASPIKE-1331] - minor type improvement of the ViewConfigNode spi
> [DELTASPIKE-1332] - support further cases for custom view-meta-data
> [DELTASPIKE-1334] - javadoc for ConfigPreProcessor#beforeAddToConfig
> [DELTASPIKE-1339] - Add support for dynamic interceptor binding, added
> via Extension
>
> Task
>
> [DELTASPIKE-1257] - Research why BOM isn't working right in a release
> [DELTASPIKE-1312] - Upgrade to quartz-2.3.0
>
>
> Here is the staging repo:
> https://repository.apache.org/content/repositories/
> orgapachedeltaspike-1047/
>
> The source zip can be found at
> https://repository.apache.org/content/repositories/
> orgapachedeltaspike-1047/org/apache/deltaspike/deltaspike/1.8.2/
> sha1 is add349e89314d9384dc9dc08772af275048343ba
>
> Please VOTE:
>
> [+1] yes, ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>


Re: just started with a DeltaSpike-1.8.2 release (java6 target)

2018-05-15 Thread Gerhard Petracek
+1 & thx!

regards,
gerhard



2018-05-15 22:51 GMT+02:00 Mark Struberg :

> just started with a DeltaSpike-1.8.2 release (java6 target)
> LieGrue,strub
>


[jira] [Assigned] (DELTASPIKE-1344) deltaspike-cdictrl-owb has a transient runtime dependency on Shrinkwrap and Arquillian

2018-05-14 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1344:


Assignee: Mark Struberg

> deltaspike-cdictrl-owb has a transient runtime dependency on Shrinkwrap and 
> Arquillian
> --
>
> Key: DELTASPIKE-1344
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1344
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.8.1
>Reporter: Robert Panzer
>Assignee: Mark Struberg
>Priority: Minor
>
> deltaspike-cdictrl-impl-owb contains a compile dependency on deltaspike 
> test-utils, which in turn has dependencies on pretty old versions of 
> Shrinkwrap, Arquillian and maven-artifact:
> [https://github.com/apache/deltaspike/blob/3ed354b373c574442d0e75c4b576010bce42efb8/deltaspike/cdictrl/impl-owb/pom.xml#L41-L45]
> Is this necessary?
> It can be annoying to find out why dependencies are suddenly wrong if you're 
> not aware of it. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1343) Upgrade Geronimo to 3.0 and MyFaces Test to 2.3

2018-05-11 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1343.
--
Resolution: Not A Problem

those dependencies are scoped "provided" (and some "test").
-> if needed please re-open the ticket and provide concrete details if you have 
a concrete issue (otherwise we won't change them since they define our current 
baseline - also see our CI-builds for ee6 and ee7 servers)

> Upgrade Geronimo to 3.0 and MyFaces Test to 2.3
> ---
>
> Key: DELTASPIKE-1343
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1343
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF-Module, Servlet-Module
>Affects Versions: 1.8.1
>Reporter: Sven Haag
>Priority: Major
>
> Still using geronimo 2.5 and myfaces-test20. Please upgrade to the latest 
> versions. See: 
> [https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jsf/api/pom.xml]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: InterceptorStrategy?

2018-04-25 Thread Gerhard Petracek
imo we can re-visit the topic once we have cdi 1.1+ as our baseline,
because with cdi 1.0 it's def. needed.

regards,
gerhard



2018-04-26 7:16 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> there are 2 issues:
>
> 1. we reinvent the wheel and do a competitive API compared to CDI
> 2. most of them - except maybe tx one - will never be implemented by any
> user
>
> So we kind of encourage users to do it wrong.
>
> Always thought it was technical workarounds so now we are in 2018 I think
> we can slowly hide it or even drop it when not relevant (all core
> interceptors pby)
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > the concrete interceptor-strategies (like TransactionStrategy) are part
> of
> > our spi. your suggestion would mean that we would need to move them as
> well
> > (= remove them from the spi).
> > def. -1 for that because i know several users who are using them.
> > i really don't get the issue you have with a simple marker interface
> (after
> > we have it for 7 years - including codi).
> >
> > btw. there are users out there who re-use InterceptorStrategy for their
> > internal interceptor-strategies (of their own libs).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Still means it doesnt have to be in the API right?
> > >
> > > Le 26 avr. 2018 00:44, "Gerhard Petracek" <gpetra...@apache.org> a
> > écrit :
> > >
> > > > #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't
> get
> > > rid
> > > > of pre-configured interceptors (that's why we introduced the
> > > > interceptor-strategy concept initially).
> > > > #2 e.g. TransactionStrategy has benefits beyond that (a public
> example
> > is
> > > > the usage in the ds-data-module)
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > I get it but it means we add a layer on top of interceptor for
> > > > > pluggability. This is actually built in in CDI so not really
> needed.
> > > > >
> > > > > Also the hierarchy point is fine but should be per type of strategy
> > and
> > > > > therefore we dont need a generic one in the api.
> > > > >
> > > > > As a user if i use DS and an interceptor, do i need to impl this
> > public
> > > > > api? Never normally so this sounds more misleading or reinventing
> the
> > > > wheel
> > > > > than anything else for me.
> > > > >
> > > > > That said we can move it in our impl modules to keep the feature
> but
> > > > still
> > > > > a clean api.
> > > > >
> > > > > Le 24 avr. 2018 23:21, "Gerhard Petracek" <gpetra...@apache.org> a
> > > > écrit :
> > > > >
> > > > > > a concrete example:
> > > > > > @Transactional
> > > > > >
> > > > > > ->
> > > > > > @Interceptor is on TransactionalInterceptor whereas
> > > InterceptorStrategy
> > > > > is
> > > > > > the marker interface for the strategies (and not the
> interceptor) -
> > > in
> > > > > this
> > > > > > case TransactionStrategy.
> > > > > >
> > > > > > (to quickly get an overview of all interceptor-strategies you
> just
> > > need
> > > > > to
> > > > > > open the hierarchy-view for InterceptorStrategy and you have
> > > everything
> > > > > you
> > > > > > need with one step...)
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > &g

Re: InterceptorStrategy?

2018-04-25 Thread Gerhard Petracek
the concrete interceptor-strategies (like TransactionStrategy) are part of
our spi. your suggestion would mean that we would need to move them as well
(= remove them from the spi).
def. -1 for that because i know several users who are using them.
i really don't get the issue you have with a simple marker interface (after
we have it for 7 years - including codi).

btw. there are users out there who re-use InterceptorStrategy for their
internal interceptor-strategies (of their own libs).

regards,
gerhard



2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Still means it doesnt have to be in the API right?
>
> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gpetra...@apache.org> a écrit :
>
> > #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't get
> rid
> > of pre-configured interceptors (that's why we introduced the
> > interceptor-strategy concept initially).
> > #2 e.g. TransactionStrategy has benefits beyond that (a public example is
> > the usage in the ds-data-module)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > I get it but it means we add a layer on top of interceptor for
> > > pluggability. This is actually built in in CDI so not really needed.
> > >
> > > Also the hierarchy point is fine but should be per type of strategy and
> > > therefore we dont need a generic one in the api.
> > >
> > > As a user if i use DS and an interceptor, do i need to impl this public
> > > api? Never normally so this sounds more misleading or reinventing the
> > wheel
> > > than anything else for me.
> > >
> > > That said we can move it in our impl modules to keep the feature but
> > still
> > > a clean api.
> > >
> > > Le 24 avr. 2018 23:21, "Gerhard Petracek" <gpetra...@apache.org> a
> > écrit :
> > >
> > > > a concrete example:
> > > > @Transactional
> > > >
> > > > ->
> > > > @Interceptor is on TransactionalInterceptor whereas
> InterceptorStrategy
> > > is
> > > > the marker interface for the strategies (and not the interceptor) -
> in
> > > this
> > > > case TransactionStrategy.
> > > >
> > > > (to quickly get an overview of all interceptor-strategies you just
> need
> > > to
> > > > open the hierarchy-view for InterceptorStrategy and you have
> everything
> > > you
> > > > need with one step...)
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Hmm not sure i get it, annotations are hard to browse in IDE? Is it
> > > what
> > > > it
> > > > > addresses?
> > > > >
> > > > > Le 24 avr. 2018 21:10, "Gerhard Petracek" <gpetra...@apache.org> a
> > > > écrit :
> > > > >
> > > > > > hi romain,
> > > > > >
> > > > > > not really. 1 interceptor could have n strategies as candidates
> > (e.g.
> > > > see
> > > > > > TransactionStrategy for which we provide multiple implementations
> > > > > > out-of-the-box).
> > > > > > that's the whole concept. the marker interfaces is just to find
> all
> > > > > > strategies in a project easily.
> > > > > > we have it since 02/2011 (back then it was  codi) and a lot of
> > users
> > > > are
> > > > > > using it (during the dev. process) and i haven't heard about any
> > > > concern
> > > > > > (from users).
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > > > >
> > > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> gpetra...@apache.org>
> > a
> > > > > > écrit :
> > > > > > >
> > > > > > >  it was always just a marker-interface to list all
> > > > > interceptor-strategies
> > > > > > > e

Re: InterceptorStrategy?

2018-04-25 Thread Gerhard Petracek
#1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't get rid
of pre-configured interceptors (that's why we introduced the
interceptor-strategy concept initially).
#2 e.g. TransactionStrategy has benefits beyond that (a public example is
the usage in the ds-data-module)

regards,
gerhard



2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> I get it but it means we add a layer on top of interceptor for
> pluggability. This is actually built in in CDI so not really needed.
>
> Also the hierarchy point is fine but should be per type of strategy and
> therefore we dont need a generic one in the api.
>
> As a user if i use DS and an interceptor, do i need to impl this public
> api? Never normally so this sounds more misleading or reinventing the wheel
> than anything else for me.
>
> That said we can move it in our impl modules to keep the feature but still
> a clean api.
>
> Le 24 avr. 2018 23:21, "Gerhard Petracek" <gpetra...@apache.org> a écrit :
>
> > a concrete example:
> > @Transactional
> >
> > ->
> > @Interceptor is on TransactionalInterceptor whereas InterceptorStrategy
> is
> > the marker interface for the strategies (and not the interceptor) - in
> this
> > case TransactionStrategy.
> >
> > (to quickly get an overview of all interceptor-strategies you just need
> to
> > open the hierarchy-view for InterceptorStrategy and you have everything
> you
> > need with one step...)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Hmm not sure i get it, annotations are hard to browse in IDE? Is it
> what
> > it
> > > addresses?
> > >
> > > Le 24 avr. 2018 21:10, "Gerhard Petracek" <gpetra...@apache.org> a
> > écrit :
> > >
> > > > hi romain,
> > > >
> > > > not really. 1 interceptor could have n strategies as candidates (e.g.
> > see
> > > > TransactionStrategy for which we provide multiple implementations
> > > > out-of-the-box).
> > > > that's the whole concept. the marker interfaces is just to find all
> > > > strategies in a project easily.
> > > > we have it since 02/2011 (back then it was  codi) and a lot of users
> > are
> > > > using it (during the dev. process) and i haven't heard about any
> > concern
> > > > (from users).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gpetra...@apache.org> a
> > > > écrit :
> > > > >
> > > > >  it was always just a marker-interface to list all
> > > interceptor-strategies
> > > > > easily.
> > > > >
> > > > >
> > > > > But if it is just interceptors, doesnt @Interceptor fulfills that
> > > > already?
> > > > >
> > > > > My only concern is exposing it in api to user where it is actually
> a
> > > dead
> > > > > interface.
> > > > >
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <
> > > > andraschko.tho...@gmail.com
> > > > > >:
> > > > >
> > > > > > basically +1
> > > > > > but its still used currently
> > > > > >
> > > > > >
> > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > Do we still need InterceptorStrategy?
> > > > > > >
> > > > > > > If not, can we deprecate it and remove it from our built-in
> > > > > interceptors?
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/
> > > > > > > rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <https://www.packtpub.com/application-development/java-
> > > > > > > ee-8-high-performance>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: InterceptorStrategy?

2018-04-24 Thread Gerhard Petracek
a concrete example:
@Transactional

->
@Interceptor is on TransactionalInterceptor whereas InterceptorStrategy is
the marker interface for the strategies (and not the interceptor) - in this
case TransactionStrategy.

(to quickly get an overview of all interceptor-strategies you just need to
open the hierarchy-view for InterceptorStrategy and you have everything you
need with one step...)

regards,
gerhard



2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Hmm not sure i get it, annotations are hard to browse in IDE? Is it what it
> addresses?
>
> Le 24 avr. 2018 21:10, "Gerhard Petracek" <gpetra...@apache.org> a écrit :
>
> > hi romain,
> >
> > not really. 1 interceptor could have n strategies as candidates (e.g. see
> > TransactionStrategy for which we provide multiple implementations
> > out-of-the-box).
> > that's the whole concept. the marker interfaces is just to find all
> > strategies in a project easily.
> > we have it since 02/2011 (back then it was  codi) and a lot of users are
> > using it (during the dev. process) and i haven't heard about any concern
> > (from users).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gpetra...@apache.org> a
> > écrit :
> > >
> > >  it was always just a marker-interface to list all
> interceptor-strategies
> > > easily.
> > >
> > >
> > > But if it is just interceptors, doesnt @Interceptor fulfills that
> > already?
> > >
> > > My only concern is exposing it in api to user where it is actually a
> dead
> > > interface.
> > >
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <
> > andraschko.tho...@gmail.com
> > > >:
> > >
> > > > basically +1
> > > > but its still used currently
> > > >
> > > >
> > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Hi guys,
> > > > >
> > > > > Do we still need InterceptorStrategy?
> > > > >
> > > > > If not, can we deprecate it and remove it from our built-in
> > > interceptors?
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <https://www.packtpub.com/application-development/java-
> > > > > ee-8-high-performance>
> > > > >
> > > >
> > >
> >
>


Re: InterceptorStrategy?

2018-04-24 Thread Gerhard Petracek
hi romain,

not really. 1 interceptor could have n strategies as candidates (e.g. see
TransactionStrategy for which we provide multiple implementations
out-of-the-box).
that's the whole concept. the marker interfaces is just to find all
strategies in a project easily.
we have it since 02/2011 (back then it was  codi) and a lot of users are
using it (during the dev. process) and i haven't heard about any concern
(from users).

regards,
gerhard



2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Le 24 avr. 2018 19:18, "Gerhard Petracek" <gpetra...@apache.org> a écrit :
>
>  it was always just a marker-interface to list all interceptor-strategies
> easily.
>
>
> But if it is just interceptors, doesnt @Interceptor fulfills that already?
>
> My only concern is exposing it in api to user where it is actually a dead
> interface.
>
>
> regards,
> gerhard
>
>
>
> 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com
> >:
>
> > basically +1
> > but its still used currently
> >
> >
> > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Hi guys,
> > >
> > > Do we still need InterceptorStrategy?
> > >
> > > If not, can we deprecate it and remove it from our built-in
> interceptors?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <https://www.packtpub.com/application-development/java-
> > > ee-8-high-performance>
> > >
> >
>


Re: InterceptorStrategy?

2018-04-24 Thread Gerhard Petracek
 it was always just a marker-interface to list all interceptor-strategies
easily.

regards,
gerhard



2018-04-24 13:47 GMT+02:00 Thomas Andraschko :

> basically +1
> but its still used currently
>
>
> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau :
>
> > Hi guys,
> >
> > Do we still need InterceptorStrategy?
> >
> > If not, can we deprecate it and remove it from our built-in interceptors?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | Book
> >  > ee-8-high-performance>
> >
>


[jira] [Updated] (DELTASPIKE-1337) optional ClassFilter spi

2018-04-20 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1337:
-
Issue Type: New Feature  (was: Improvement)

> optional ClassFilter spi
> 
>
> Key: DELTASPIKE-1337
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> in several cases it's needed to get rid of beans and/or pre-defined beans.
>  that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and 
> ProcessAnnotatedType#veto.
>  only #veto supports really dynamic cases - esp. in cases you don't have the 
> class/es in question under your control (or diff. teams have diff. 
> requirements).
> a simple (but optional) ClassFilter spi allows:
>  * full control (like with #veto - just simpler)
>  * the concept of overruling based on config-ordinals
>  * to get rid of special behaviors defined for alternative-beans (see e.g. 
> observers in alternative-beans)
>  * to use the concept itself for different features/use-cases
> (e.g. a class-filter per test-class via @TestControl to support more isolated 
> tests)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1337) optional ClassFilter spi

2018-04-20 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1337.
--
Resolution: Fixed

> optional ClassFilter spi
> 
>
> Key: DELTASPIKE-1337
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> in several cases it's needed to get rid of beans and/or pre-defined beans.
>  that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and 
> ProcessAnnotatedType#veto.
>  only #veto supports really dynamic cases - esp. in cases you don't have the 
> class/es in question under your control (or diff. teams have diff. 
> requirements).
> a simple (but optional) ClassFilter spi allows:
>  * full control (like with #veto - just simpler)
>  * the concept of overruling based on config-ordinals
>  * to get rid of special behaviors defined for alternative-beans (see e.g. 
> observers in alternative-beans)
>  * to use the concept itself for different features/use-cases
> (e.g. a class-filter per test-class via @TestControl to support more isolated 
> tests)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1338) support class-filter per test

2018-04-20 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1338.
--
Resolution: Fixed

> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per 
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build 
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter 
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter = 
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter 
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to 
> alternative-beans).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1338) support class-filter per test

2018-04-20 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1338:
-
Issue Type: New Feature  (was: Improvement)

> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per 
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build 
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter 
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter = 
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter 
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to 
> alternative-beans).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1338) support class-filter per test

2018-04-20 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1338:


 Summary: support class-filter per test
 Key: DELTASPIKE-1338
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
 Project: DeltaSpike
  Issue Type: Improvement
  Components: TestControl
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


based on DELTASPIKE-1337 it should be possible to define a class-filter per 
test.

it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build 
labeled-alternatives without text-based config.

a possible approach looks like:

{code:java}
@Retention(RUNTIME)
@Target(TYPE)
public @interface Labeled {
Class value();
}

public abstract class AbstractLabeledAlternativeFilter implements ClassFilter {
private final Class activeLabel;

protected AbstractLabeledAlternativeFilter(Class activeLabel) {
this.activeLabel = activeLabel;
}

@Override
public boolean isFiltered(Class targetClass) {
if (!targetClass.isAnnotationPresent(Alternative.class)) {
return false;
}

Labeled labeled = targetClass.getAnnotation(Labeled.class);

if (labeled == null) {
return false;
}

if (labeled.value().equals(activeLabel)) {
return false;
}
return true;
}
}
{code}

{code:java}
@Labeled(Label1Test.Label1.class)
@Alternative
@Priority(1)
public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }

@RunWith(CdiTestRunner.class)
@TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter = 
Label1Test.Label1Filter.class)
public class Label1Test {
@Inject
private MyBean myBean;

//tests

public static class Label1 implements TestControl.Label {
}

public static class Label1Filter extends AbstractLabeledAlternativeFilter {
public Label1Filter() {
super(Label1.class);
}
}
}
{code}

besides that other custom concepts are possible as well (not even bound to 
alternative-beans).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1337) optional ClassFilter spi

2018-04-20 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1337:


 Summary: optional ClassFilter spi
 Key: DELTASPIKE-1337
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


in several cases it's needed to get rid of beans and/or pre-defined beans.
 that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and 
ProcessAnnotatedType#veto.
 only #veto supports really dynamic cases - esp. in cases you don't have the 
class/es in question under your control (or diff. teams have diff. 
requirements).

a simple (but optional) ClassFilter spi allows:
 * full control (like with #veto - just simpler)
 * the concept of overruling based on config-ordinals
 * to get rid of special behaviors defined for alternative-beans (see e.g. 
observers in alternative-beans)
 * to use the concept itself for different features/use-cases
(e.g. a class-filter per test-class via @TestControl to support more isolated 
tests)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [DISCUSS] ds for cdi 1.2+ only

2018-04-03 Thread Gerhard Petracek
the workarounds aren't that bad. it's just that we could drop more
reflection calls (similar to what we discussed for jdk8 and
java.util.Optional).

ok - i'll document details about the warnings during the bootstrapping
process (and if needed how to get rid of some of them).

regards,
gerhard



2018-04-04 6:13 GMT+02:00 Rudy De Busscher <rdebussc...@gmail.com>:

> I have not a clear view of the workarounds which are made and how
> 'bad'/hacky they are. But when we don't have major complaints about it (now
> or in the past) I would not invest too much time in a temporary version for
> CDI 1.2.
>
> so #3.
>
> Rudy
>
> On 3 April 2018 at 22:34, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > All work for me and the apps i work on since a few years.
> >
> > Le 3 avr. 2018 22:17, "Thomas Andraschko" <andraschko.tho...@gmail.com>
> a
> > écrit :
> >
> > > +1 for 3)
> > > the workarounds are really not that big...
> > >
> > > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only)
> > the
> > > next months.
> > >
> > > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
> > >
> > > > hi @ all,
> > > >
> > > > since we will need to maintain v1.8.x for a while and it's too early
> > for
> > > > using cdi 2.0 (for a while), we should discuss if we should have one
> > > branch
> > > > using cdi 1.2+.
> > > > it would allow to get rid of several workarounds (and the
> corresponding
> > > > warnings during the bootstrapping process).
> > > >
> > > > we had a short discussion in the irc-channel about the following
> > options:
> > > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+
> > > >
> > > > vs
> > > >
> > > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with
> cdi
> > > > v1.2+; ds v2: jdk8 with cdi 2.0+
> > > >
> > > > vs
> > > >
> > > > #3) we don't care about v1.2 as a min. requirement at all
> > > > (the workarounds are minimal anyway and users can continue to ignore
> > the
> > > > warnings during the bootstrapping process)
> > > >
> > > > or for sure
> > > > #4) [any other nice suggestion]
> > > >
> > > > -> please send your preferred approach
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > >
> >
>


[DISCUSS] ds for cdi 1.2+ only

2018-04-03 Thread Gerhard Petracek
hi @ all,

since we will need to maintain v1.8.x for a while and it's too early for
using cdi 2.0 (for a while), we should discuss if we should have one branch
using cdi 1.2+.
it would allow to get rid of several workarounds (and the corresponding
warnings during the bootstrapping process).

we had a short discussion in the irc-channel about the following options:
#1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+

vs

#2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi
v1.2+; ds v2: jdk8 with cdi 2.0+

vs

#3) we don't care about v1.2 as a min. requirement at all
(the workarounds are minimal anyway and users can continue to ignore the
warnings during the bootstrapping process)

or for sure
#4) [any other nice suggestion]

-> please send your preferred approach

regards,
gerhard


[jira] [Resolved] (DELTASPIKE-1334) javadoc for ConfigPreProcessor#beforeAddToConfig

2018-03-29 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1334.
--
Resolution: Fixed

> javadoc for ConfigPreProcessor#beforeAddToConfig
> 
>
> Key: DELTASPIKE-1334
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1334
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.8.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1334) javadoc for ConfigPreProcessor#beforeAddToConfig

2018-03-29 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1334:


 Summary: javadoc for ConfigPreProcessor#beforeAddToConfig
 Key: DELTASPIKE-1334
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1334
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1332) support further cases for custom view-meta-data

2018-03-23 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1332.
--
Resolution: Fixed

> support further cases for custom view-meta-data
> ---
>
> Key: DELTASPIKE-1332
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> if meta-data gets merged (and not aggregated), merging with primitive types 
> is currently only supported if there is a default-value. otherwise 
> annotation-proxies throw a NPE.
> use-case e.g.:
> @WizardStep(1) shouldn't require a default-value 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1331) minor type improvement of the ViewConfigNode spi

2018-03-23 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1331.
--
Resolution: Fixed

> minor type improvement of the ViewConfigNode spi
> 
>
> Key: DELTASPIKE-1331
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1331
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Trivial
> Fix For: 1.8.2
>
>
> usually #getMetaData is enough, however, to get the +physical+ annotations 
> via #getSource a cast from Class to Class is needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1332) support further cases for custom view-meta-data

2018-03-23 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1332:


 Summary: support further cases for custom view-meta-data
 Key: DELTASPIKE-1332
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


if meta-data gets merged (and not aggregated), merging with primitive types is 
currently only supported if there is a default-value. otherwise 
annotation-proxies throw a NPE.

use-case e.g.:
@WizardStep(1) shouldn't require a default-value 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1331) minor type improvement of the ViewConfigNode spi

2018-03-23 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1331:


 Summary: minor type improvement of the ViewConfigNode spi
 Key: DELTASPIKE-1331
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1331
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


usually #getMetaData is enough, however, to get the +physical+ annotations via 
#getSource a cast from Class to Class is needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1329) ProjectStageProducer should log changed values

2018-03-17 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1329.
--
Resolution: Fixed

> ProjectStageProducer should log changed values
> --
>
> Key: DELTASPIKE-1329
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1329
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1329) ProjectStageProducer should log changed values

2018-03-17 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1329:


 Summary: ProjectStageProducer should log changed values
 Key: DELTASPIKE-1329
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1329
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1319:
-
Attachment: (was: DELTASPIKE_1319_first_draft__without_spi_.patch)

> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378260#comment-16378260
 ] 

Gerhard Petracek edited comment on DELTASPIKE-1319 at 2/27/18 10:55 PM:


the commit contains 2 uc-tests based on @TestControl.

with meecrowave it would look like e.g.:

{code}
@ClassRule
public static final MeecrowaveRule RULE = new MeecrowaveRule() {
@Override
protected AutoCloseable onStart() {
System.setProperty("activeAlternativeLabel", "myLabel");
return super.onStart();
}
};
{code}


was (Author: gpetracek):
the patch contains 2 uc-tests based on @TestControl.

with meecrowave it would look like e.g.:

{code}
@ClassRule
public static final MeecrowaveRule RULE = new MeecrowaveRule() {
@Override
protected AutoCloseable onStart() {
System.setProperty("activeAlternativeLabel", "myLabel");
return super.onStart();
}
};
{code}

> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1320:
-
Attachment: (was: DELTASPIKE_1320_first_draft.patch)

> global alternative spi to support custom (type-safe) mechanisms
> ---
>
> Key: DELTASPIKE-1320
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> in combination with DELTASPIKE-1319 it should be possible to implement e.g. 
> type-safe labels based on binding-annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1320.
--
Resolution: Fixed

> global alternative spi to support custom (type-safe) mechanisms
> ---
>
> Key: DELTASPIKE-1320
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
> Attachments: DELTASPIKE_1320_first_draft.patch
>
>
> in combination with DELTASPIKE-1319 it should be possible to implement e.g. 
> type-safe labels based on binding-annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1319.
--
Resolution: Fixed

> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
> Attachments: DELTASPIKE_1319_first_draft__without_spi_.patch
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1320:
-
Attachment: DELTASPIKE_1320_first_draft.patch

> global alternative spi to support custom (type-safe) mechanisms
> ---
>
> Key: DELTASPIKE-1320
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
> Attachments: DELTASPIKE_1320_first_draft.patch
>
>
> in combination with DELTASPIKE-1319 it should be possible to implement e.g. 
> type-safe labels based on binding-annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms

2018-02-27 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1320:


 Summary: global alternative spi to support custom (type-safe) 
mechanisms
 Key: DELTASPIKE-1320
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


in combination with DELTASPIKE-1319 it should be possible to implement e.g. 
type-safe labels based on binding-annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378260#comment-16378260
 ] 

Gerhard Petracek commented on DELTASPIKE-1319:
--

the patch contains 2 uc-tests based on @TestControl.

with meecrowave it would look like e.g.:

{code}
@ClassRule
public static final MeecrowaveRule RULE = new MeecrowaveRule() {
@Override
protected AutoCloseable onStart() {
System.setProperty("activeAlternativeLabel", "myLabel");
return super.onStart();
}
};
{code}

> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
> Attachments: DELTASPIKE_1319_first_draft__without_spi_.patch
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1319:
-
Attachment: DELTASPIKE_1319_first_draft__without_spi_.patch

> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
> Attachments: DELTASPIKE_1319_first_draft__without_spi_.patch
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DELTASPIKE-1319) labeled alternatives

2018-02-27 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-1319:


 Summary: labeled alternatives
 Key: DELTASPIKE-1319
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core, TestControl
Affects Versions: 1.8.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.8.2


target setup: ds-testcontrol as well as containers like meecrowave which 
support one instance per test-class, but deploy the whole application.

in several cases it's essential to bind alternative beans only to a subset of 
all tests.
currently we just support that partially via the mock-support (which is very 
limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: bringing interdyn and invomon to DeltaSpike?

2018-02-09 Thread Gerhard Petracek
imo the config should be based on the ds-config-api -> with that the
config-format isn't limited.

regards,
gerhard



2018-02-09 11:48 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Also suggested dynamic interceptors some years ago - so +1. Just not sure
> if properties is the best way.
> Maybe we should think about if we should someday introduce something like a
> deltaspike xml config. Not sure.
>
> 2018-02-09 11:34 GMT+01:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > basically +1 for adding such modules (independent of the details, since
> we
> > can improve parts once it's needed).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-02-09 10:51 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Hi Mark
> > >
> > > I like interdync and it is a generic fit but invomon is a bit limited
> in
> > > current flavor and I would be tempted to say we can just inherit from
> the
> > > related sirona part of code if we want to go this way.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <https://www.packtpub.com/application-development/java-
> > > ee-8-high-performance>
> > >
> > > 2018-02-09 10:49 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
> > >
> > > > Hi folks!
> > > >
> > > > Some of you might know my interdyn + invomon projects [1].
> > > >
> > > > For the others, what are they about?
> > > >
> > > > interdyn is a dynamic interceptor binding Extension.
> > > > It allows to declare a regexp pattern and a class name of an
> > Interceptor
> > > > annotation.
> > > > It then applies this annotation to all the classes which map the
> > regexp.
> > > > Of course you can define multiple rules.
> > > >
> > > > rule.1.match=.*ServiceImpl
> > > > rule.1.interceptor=net.struberg.devtools.cdi.invomon.
> > InvocationMonitored
> > > >
> > > > The other part is exactly that @InvocationMonitored interceptor.
> > > >
> > > > It logs the most expensive methods and classes after each request.
> > > > The output looks like the following:
> > > >
> > > > 2011-03-19 12:36:27,291 [2046767960@qtp-1243908618-9]  INFO
> > > > invomon.InvocationResultLogger Top Class Invocations:
> > > >   count: 51 net.struberg.myproject.core.be.semester.
> > > > SemesterRemoteServiceImpl
> > > >   count: 21 net.struberg.myproject.core.be.security.service.
> > > > SecurityServiceImpl
> > > >   count: 5  net.struberg.myproject.util.
> > be.config.ConfigServiceImpl
> > > >   count: 2  net.struberg.myproject.course.be.CourseServiceImpl
> > > >   count: 1  net.struberg.myproject.events.be.EventServiceImpl
> > > >   count: 1  net.struberg.myproject.core.be.persons.
> > > > PersonRemoteServiceImpl
> > > >   count: 1  net.struberg.myproject.course.be.LecturerServiceImpl
> > > >   count: 1  net.struberg.myproject.events.
> > be.EventRemoteServiceImpl
> > > >
> > > > 2011-03-19 12:36:27,292 [2046767960@qtp-1243908618-9]  INFO
> > > > invomon.InvocationResultLogger Top Method Invocations:
> > > >   dur[ms]: 442.48096count: 1
> net.struberg.myproject.course.
> > > > be.CourseServiceImpl#deleteCourse
> > > >   dur[ms]: 349.34717count: 1
> net.struberg.myproject.course.
> > > > be.CourseServiceImpl#getByFilter
> > > >   dur[ms]: 104.53423count: 1
> net.struberg.myproject.events.
> > > > be.EventRemoteServiceImpl#getEvent
> > > >   dur[ms]: 100.43162count: 1
> net.struberg.myproject.events.
> > > > be.EventServiceImpl#getEvent
> > > >   dur[ms]: 24.677048count: 1
> net.struberg.myproject.course.
> > > > be.LecturerServiceImpl#getEmployeeIdsInvolvedInOrgUnitCourses
> > > >   dur[ms]: 1.596834 count: 1net.struberg.myproject.core.
> > > > be.persons.PersonRemoteServiceImpl#getByEmployeeIdList
> > > >   dur[ms]: 0.892522 count: 51   net.struberg.myproject.core.
> > > > be.semester.SemesterRemoteServiceImpl#getCorrespondingSemesterCode
> > > >   dur[ms]: 0.288455 count: 5net.struberg.myproject.util.
> > > > be.config.ConfigServiceImpl#getStringProperty
> > > >   dur[ms]: 0.248038 count: 3net.struberg.myproject.core.
> > > > be.security.service.SecurityServiceImpl#isGranted
> > > >   dur[ms]: 0.203102 count: 18   net.struberg.myproject.core.
> > > > be.security.service.SecurityServiceImpl#isAuthenticated
> > > >
> > > >
> > > > The initial version requires an own property file. But of course all
> > this
> > > > configuration could also be provided via DS-config.
> > > >
> > > > wdyt?
> > > > Worth moving over to DeltaSpike?
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > >
> > > > [1] https://github.com/struberg/interdyn
> > > >
> > > >
> > >
> >
>


Re: bringing interdyn and invomon to DeltaSpike?

2018-02-09 Thread Gerhard Petracek
basically +1 for adding such modules (independent of the details, since we
can improve parts once it's needed).

regards,
gerhard



2018-02-09 10:51 GMT+01:00 Romain Manni-Bucau :

> Hi Mark
>
> I like interdync and it is a generic fit but invomon is a bit limited in
> current flavor and I would be tempted to say we can just inherit from the
> related sirona part of code if we want to go this way.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-02-09 10:49 GMT+01:00 Mark Struberg :
>
> > Hi folks!
> >
> > Some of you might know my interdyn + invomon projects [1].
> >
> > For the others, what are they about?
> >
> > interdyn is a dynamic interceptor binding Extension.
> > It allows to declare a regexp pattern and a class name of an Interceptor
> > annotation.
> > It then applies this annotation to all the classes which map the regexp.
> > Of course you can define multiple rules.
> >
> > rule.1.match=.*ServiceImpl
> > rule.1.interceptor=net.struberg.devtools.cdi.invomon.InvocationMonitored
> >
> > The other part is exactly that @InvocationMonitored interceptor.
> >
> > It logs the most expensive methods and classes after each request.
> > The output looks like the following:
> >
> > 2011-03-19 12:36:27,291 [2046767960@qtp-1243908618-9]  INFO
> > invomon.InvocationResultLogger Top Class Invocations:
> >   count: 51 net.struberg.myproject.core.be.semester.
> > SemesterRemoteServiceImpl
> >   count: 21 net.struberg.myproject.core.be.security.service.
> > SecurityServiceImpl
> >   count: 5  net.struberg.myproject.util.be.config.ConfigServiceImpl
> >   count: 2  net.struberg.myproject.course.be.CourseServiceImpl
> >   count: 1  net.struberg.myproject.events.be.EventServiceImpl
> >   count: 1  net.struberg.myproject.core.be.persons.
> > PersonRemoteServiceImpl
> >   count: 1  net.struberg.myproject.course.be.LecturerServiceImpl
> >   count: 1  net.struberg.myproject.events.be.EventRemoteServiceImpl
> >
> > 2011-03-19 12:36:27,292 [2046767960@qtp-1243908618-9]  INFO
> > invomon.InvocationResultLogger Top Method Invocations:
> >   dur[ms]: 442.48096count: 1net.struberg.myproject.course.
> > be.CourseServiceImpl#deleteCourse
> >   dur[ms]: 349.34717count: 1net.struberg.myproject.course.
> > be.CourseServiceImpl#getByFilter
> >   dur[ms]: 104.53423count: 1net.struberg.myproject.events.
> > be.EventRemoteServiceImpl#getEvent
> >   dur[ms]: 100.43162count: 1net.struberg.myproject.events.
> > be.EventServiceImpl#getEvent
> >   dur[ms]: 24.677048count: 1net.struberg.myproject.course.
> > be.LecturerServiceImpl#getEmployeeIdsInvolvedInOrgUnitCourses
> >   dur[ms]: 1.596834 count: 1net.struberg.myproject.core.
> > be.persons.PersonRemoteServiceImpl#getByEmployeeIdList
> >   dur[ms]: 0.892522 count: 51   net.struberg.myproject.core.
> > be.semester.SemesterRemoteServiceImpl#getCorrespondingSemesterCode
> >   dur[ms]: 0.288455 count: 5net.struberg.myproject.util.
> > be.config.ConfigServiceImpl#getStringProperty
> >   dur[ms]: 0.248038 count: 3net.struberg.myproject.core.
> > be.security.service.SecurityServiceImpl#isGranted
> >   dur[ms]: 0.203102 count: 18   net.struberg.myproject.core.
> > be.security.service.SecurityServiceImpl#isAuthenticated
> >
> >
> > The initial version requires an own property file. But of course all this
> > configuration could also be provided via DS-config.
> >
> > wdyt?
> > Worth moving over to DeltaSpike?
> >
> > LieGrue,
> > strub
> >
> >
> >
> > [1] https://github.com/struberg/interdyn
> >
> >
>


[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

2018-01-05 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313267#comment-16313267
 ] 

Gerhard Petracek commented on DELTASPIKE-1311:
--

@john:
as i just mentioned we have Deactivatable for that purpose already (we just 
need to add the check to RepositoryExtension)

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

2018-01-05 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313224#comment-16313224
 ] 

Gerhard Petracek commented on DELTASPIKE-1311:
--

+1 for @Vetoed, but not for @Exclude (at least until we know which version of 
cdi the initial reporter is using).
we would introduce something special, which is part of cdi since almost 5 years.

+ maybe we should improve the extensibility of RepositoryExtension (several 
other extension-classes are extensible/replaceable already).

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

2018-01-05 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313171#comment-16313171
 ] 

Gerhard Petracek commented on DELTASPIKE-1311:
--

imo it doesn't make sense to just support a small part of @Exclude here.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DELTASPIKE-1307) Deltaspike JSF: XSS WindowIdHtmlRenderer.java

2017-12-31 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307209#comment-16307209
 ] 

Gerhard Petracek commented on DELTASPIKE-1307:
--

@md:
fyi: if you think 10 chars are enough (to do more than useless calls), you can 
change the max-length via 
JsfBaseConfig.ScopeCustomization.WindowRestriction.ID_MAX_LENGTH (since the 
beginning...).
the default-value is 10 because in the discussion back than it was excepted as 
secure enough (in case you don't ship harmful scripts in your own app), 
however, it's great to have the addition from mark!

> Deltaspike JSF: XSS WindowIdHtmlRenderer.java
> -
>
> Key: DELTASPIKE-1307
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1307
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.8.0
> Environment: any
>Reporter: md
>Assignee: Mark Struberg
>Priority: Blocker
>  Labels: security
> Fix For: 1.8.1
>
>
> 10 chars ough to be enough for XSS.
> Try escaping your variables.
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jsf/impl/src/main/java/org/apache/deltaspike/jsf/impl/component/window/WindowIdHtmlRenderer.java
> Line 80
> PoC
> dswid='-open()-'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


Re: [VOTE] release Apache DeltaSpike-1.8.1

2017-12-30 Thread Gerhard Petracek
+1

regards,
gerhard



2017-12-30 17:39 GMT+01:00 Mark Struberg :

> Hi folks!
>
> I did run the necessary steps for releasing DeltaSpike-1.8.1
>
> The following bugs and improvements got implemented:
>
> Bug
>
> • [DELTASPIKE-1252] - data-documentation missing Optional return
> value
> • [DELTASPIKE-1271] - [perf] cache Transactional
> • [DELTASPIKE-1272] - ConfigResolver asList breaks if no value is
> found
> • [DELTASPIKE-1275] - Build fails on Linux because Testclass
> filenames are to long
> • [DELTASPIKE-1278] - PropertyFileConfig does not respect optional
> on external resources
> • [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to
> persistenf factory config using "javax.persistence.bean.manager"
> • [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no
> configured value exists
> • [DELTASPIKE-1288] - Default values are not interpolated
> • [DELTASPIKE-1294] - Secured Stereotypes are not applied to
> inherited methods
> • [DELTASPIKE-1296] - PropertyFileConfig doesn't work with
> internal extensions
> • [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is
> always empty
> • [DELTASPIKE-1303] - @Configuration proxies should support List
> without converters
> • [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple
> redirects
> • [DELTASPIKE-1306] - IE sometimes doesn't set window.name
> correctly
> • [DELTASPIKE-1307] - Deltaspike JSF: XSS WindowIdHtmlRenderer.java
> Improvement
>
> • [DELTASPIKE-940] - @Transactional and @EntityManagerConfig each
> use a different method to resolve EntityManagers
> • [DELTASPIKE-1070] - Refactor RepositoryComponent/s
> • [DELTASPIKE-1258] - skip flush with one EntityManager
> • [DELTASPIKE-1267] - Remove second factory mechanism of
> QueryBuilder's
> • [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
> • [DELTASPIKE-1269] - [perf] Cache singleResultType per method
> • [DELTASPIKE-1270] - [perf] cache requiresTransaction per method
> • [DELTASPIKE-1274] - Refactor proxy-module / improve performance
> • [DELTASPIKE-1279] - SimpleSecurityViolation needs equals/hashcode
> • [DELTASPIKE-1283] - Placeholders not supported for defaults
> • [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse
> BeanManager
> • [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
> • [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment on
> Weld by default
> Task
>
> • [DELTASPIKE-1259] - upgraded version numbers
> • [DELTASPIKE-1297] - add test with a customized DynamicMockManager
> • [DELTASPIKE-1298] - document customization of a
> DynamicMockManager
> Test
>
> • [DELTASPIKE-1273] - Test against OWB 2
>
>
>
> The staging repo is
> https://repository.apache.org/content/repositories/
> orgapachedeltaspike-1046/
>
> The source release can be found at
> https://repository.apache.org/content/repositories/
> orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/
> sha1 is 4d7db712629261a92e6dcddfdcb7a446015bf432
>
>
> Please VOTE:
>
> [+1] yea, let's ship it
> [+0] meh, don't care
> [-1] yikes, stop because ${showstopper}
>
> The VOTE is open for 72h.
>
>
> Here is my own +1
>
> txs and LieGrue,
> strub


Re: CI for DeltaSpike?

2017-12-01 Thread Gerhard Petracek
hi matej,

imo the main point here is that in the past we received too many wrong
failures and almost no commit really broke the backward compatibility.

regards,
gerhard



2017-12-01 11:49 GMT+01:00 Matej Novotny <manov...@redhat.com>:

> Hi Gerhard,
>
> > i'm not sure if others are still following it. at the time i did the
> > releases, it was a mandatory step.
>
> Yes, I hope nobody releases without actually testing it at all.
> But this check IMO comes too late - there are multiple "fixes" present,
> where the author apparently didn't even execute the tests.
> Checking this before release means you bump into problems with issues
> which were "fixed" six months ago.
> Hence I am suggesting whether we shouldn't look into some more flexible
> approach.
> I know Travis still isn't quite the thing beucase of the structure, I am
> just trying to start a discussion here and see how people view thing -
> maybe I am just weird with my requirements :)
>
> > back then i also added ci-jobs for new owb/weld releases immediately.
> > (it looks like nobody took over that part.)
>
> Would be great if this was still done, every new weld release is announced
> directly on DS mailing list, so it's just about updating it.
>
>
> Matej
>
> - Original Message -
> > From: "Gerhard Petracek" <gpetra...@apache.org>
> > To: dev@deltaspike.apache.org
> > Sent: Thursday, November 30, 2017 3:32:04 PM
> > Subject: Re: CI for DeltaSpike?
> >
> > hi matej,
> >
> > one of the (manual) steps for a release is to check those results
> (before a
> > release gets started at all).
> > i'm not sure if others are still following it. at the time i did the
> > releases, it was a mandatory step.
> > back then i also added ci-jobs for new owb/weld releases immediately.
> > (it looks like nobody took over that part.)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Sorry Matej, I don't get how Travis would help since you can do the
> > > same with jenkins which is already configured.
> > >
> > > Having the default build running on both weld and OWB would be more
> > > beneficial IMHO, but it is just the opinion from my side of the fence
> > > and experience.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > >
> > >
> > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > > > Thanks, but it was more of a rhetorical question (you saved me some
> > > digging though).
> > > > Still my claim holds true, nobody cares about them much. They must
> have
> > > been failing for quite some time now
> > > > Not to mention they aren't even updated to latest Weld version (or
> > > WildFly version for that matter).
> > > >
> > > >
> > > > Matej
> > > >
> > > > - Original Message -
> > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > > >> To: dev@deltaspike.apache.org
> > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> > > >> Subject: Re: CI for DeltaSpike?
> > > >>
> > > >> Hi Matej,
> > > >>
> > > >> they are all on the ASF jenkins:
> > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > >>
> > > >>
> > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > > >> > Hello
> > > >> >
> > > >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> > > meant
> > > >> > Integration OFC) and DeltaSpike.
> > > >> > Apparently, there is no such thing now and even while some CI jobs
> > > exist
> > > >> > (where are they, anyway?), nobody really pays attention to them.
> > > >> > I mean those for Weld ones must have been failing for few months
> and
> > > yet
> > > >> > the JIRAs causing that were happily marked as Resolved.
> > > >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> > > >> >
> > > >> > Today I noticed there is going to be a release soon and so I
> quikly

Re: CI for DeltaSpike?

2017-11-30 Thread Gerhard Petracek
hi matej,

one of the (manual) steps for a release is to check those results (before a
release gets started at all).
i'm not sure if others are still following it. at the time i did the
releases, it was a mandatory step.
back then i also added ci-jobs for new owb/weld releases immediately.
(it looks like nobody took over that part.)

regards,
gerhard



2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau :

> Sorry Matej, I don't get how Travis would help since you can do the
> same with jenkins which is already configured.
>
> Having the default build running on both weld and OWB would be more
> beneficial IMHO, but it is just the opinion from my side of the fence
> and experience.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-30 14:57 GMT+01:00 Matej Novotny :
> > Thanks, but it was more of a rhetorical question (you saved me some
> digging though).
> > Still my claim holds true, nobody cares about them much. They must have
> been failing for quite some time now
> > Not to mention they aren't even updated to latest Weld version (or
> WildFly version for that matter).
> >
> >
> > Matej
> >
> > - Original Message -
> >> From: "Romain Manni-Bucau" 
> >> To: dev@deltaspike.apache.org
> >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> >> Subject: Re: CI for DeltaSpike?
> >>
> >> Hi Matej,
> >>
> >> they are all on the ASF jenkins:
> >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >>
> >>
> >> 2017-11-29 16:47 GMT+01:00 Matej Novotny :
> >> > Hello
> >> >
> >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> meant
> >> > Integration OFC) and DeltaSpike.
> >> > Apparently, there is no such thing now and even while some CI jobs
> exist
> >> > (where are they, anyway?), nobody really pays attention to them.
> >> > I mean those for Weld ones must have been failing for few months and
> yet
> >> > the JIRAs causing that were happily marked as Resolved.
> >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> >> >
> >> > Today I noticed there is going to be a release soon and so I quikly
> went to
> >> > check how the build/tests fare with Weld profiles.
> >> > Turned out to be a disaster. So I then have to spend considerable time
> >> > backtracking the changes and figuring out the actual problem.
> >> > And it's not the first time this happened either.
> >> >
> >> > Therefore I wanted to bring up the topic of CI to avoid this in the
> future.
> >> > The ideal scenario is sending PRs and having them checked *before*
> merging
> >> > - obviously not an option here.
> >> > The GH repo is but a mirror (something we have to stick to I presume)
> which
> >> > makes it more complex, but still, it should be possible to set up a
> Travis
> >> > build on GH master which will execute after every sync.
> >> > That way the failures would be readily visible (via the travis status
> >> > "button").
> >> > In order to discover most problems there is no need for a complete
> test
> >> > matrix, it would do to just have two version of OWB and Weld without
> EE
> >> > container (with just the Arq. one).
> >> >
> >> >
> >> > A penny for your thoughts?
> >> >
> >> >
> >> > Regards
> >> > Matej
> >>
>


[jira] [Commented] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

2017-11-29 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270896#comment-16270896
 ] 

Gerhard Petracek commented on DELTASPIKE-1294:
--

ic - i hope it's enough to use ProxyUtils#getUnproxiedClass additionally

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

2017-11-29 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270752#comment-16270752
 ] 

Gerhard Petracek commented on DELTASPIKE-1294:
--

@matej:
that's what mark pushed. it isn't 100% portable in view of some versions of old 
ee6 servers, however, the previous behavior is still in place as a fallback.

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

2017-11-27 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266687#comment-16266687
 ] 

Gerhard Petracek edited comment on DELTASPIKE-1294 at 11/27/17 11:54 AM:
-

we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.
as always both approaches have advantages and disadvantages.
i guess the reason for the inconsistency is caused by the origin of both 
annotations.
(@Secures came from seam3 whereas @Secured came from codi)

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).


was (Author: gpetracek):
we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

2017-11-27 Thread Gerhard Petracek (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266687#comment-16266687
 ] 

Gerhard Petracek commented on DELTASPIKE-1294:
--

we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


  1   2   3   4   5   6   7   8   9   10   >