Re: Jakarta EE / DeltaSpike 2.0 Status

[Gerhard Petracek]

@mark: +1

regards,
gerhard



Am Fr., 7. Apr. 2023 um 09:45 Uhr schrieb Mark Struberg
:
>
> a) I'd rather keep the current names. Just because of backward compat and 
> adoption. Maybe the names are not perfect, but they are rather fine. It 
> should really be mostly a package renaming and be done
>
> b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional and 
> javax.transaction.Transactional:
> We have a very clear rule when it comes to Exceptions. In DS, if an Exception 
> appears we will do a rollback, otherwise we will do a commit.
> In javax/jakarta @Transactional only RuntimeExceptions and 
> ApplicationExceptions with rollback=true will create a rollback, all other 
> Exceptions will still cause a commit. This was 1:1 taken from EJB (which is 
> imo also rather broken). Most people don't even don't realise that they might 
> get a FileNotFoundException in the middle of their business code and STILL 
> all the half done changes will be committed.
>
> Otoh if you have a RuntimeException in some nested Services ,A.fn() calls 
> B.fn(), which is not catched when returning from the EJB 'Business Method' 
> B.fn() the whole transaction will get marked as rollbackOnly(). Even if you 
> would have catched this very Exception in A.fn(). That's another major pain.
>
> I wrote a lengthy blog post about it many moons ago:
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> All this was the reason why we introduced the DeltaSpike @Transactional. It 
> has a very clear semantic:
> On the very layer ('business method' invocation) where the transaction got 
> opened we do the check. If there is any Excpetion thrown -> Rollback, 
> otherwise -> Commit.
> Any subsequent nested calls into @Transactional business methods are 
> completely transparent.
>
> You can also mix this with EJB and leverage any platform provided features if 
> you use our TransactionStrategy which uses an injected UserTransaction to get 
> the best of both worlds.
>
> DeltaSpike @Transactional is btw also used in projects which do not use our 
> data module. Thus I'd leave everything in place. Please also think about the 
> poor souls which just want to move from javax to jakarta *without* having 
> such a deep knowledge about DeltaSpike as we do!
>
>
> LieGrue,
> strub
>
>
>
> > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau :
> >
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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>
> >
> >
> > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko 
> > a écrit :
> >
> >> JPA is also about reading the JPA XML descriptors and resolving
> >> EntityManagers, which is both heavily used in the Data module.
> >> So its currently much more than TX. I would rename it to ds-persistence and
> >> ds-faces.
> >>
> >> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> >> gpetra...@apache.org>:
> >>
> >>> hi thomas,
> >>>
> >>> we need to fix the rat-check (see [1]).
> >>>
> >>> @renaming the modules:
> >>> the jpa-module was always mainly about the "entitymanager" +
> >>> "transaction" (see the package-naming)... with th

Re: Jakarta EE / DeltaSpike 2.0 Status

[Gerhard Petracek]

EntityManagerResolver isn't really a feature on its own.
it was mainly about a common contract as well as encapsulation (of the
lookup-code) for re-using it across modules.

@goal (you mentioned):
i mentioned almost the same some time ago, however, there isn't/wasn't
an agreement (for that approach).

regards,
gerhard



Am Di., 4. Apr. 2023 um 10:21 Uhr schrieb Thomas Andraschko

:
>
> In theory we could remove TX (if all cases are handled by JTA) and move the
> EntityManagerResolver + JPA descriptor parsing to Data itself.
>
> In general i think our goal should be to port the DS features, if still not
> existing in EE10, to EE10. Not to remove everything not widely used.
> This allows users to migrate to EE10 with some adjustments.
>
>
> Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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
> > >
> >
> >
> > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > a écrit :
> >
> > > JPA is also about reading the JPA XML descriptors and resolving
> > > EntityManagers, which is both heavily used in the Data module.
> > > So its currently much more than TX. I would rename it to ds-persistence
> > and
> > > ds-faces.
> > >
> > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > gpetra...@apache.org>:
> > >
> > > > hi thomas,
> > > >
> > > > we need to fix the rat-check (see [1]).
> > > >
> > > > @renaming the modules:
> > > > the jpa-module was always mainly about the "entitymanager" +
> > > > "transaction" (see the package-naming)... with the main focus on
> > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > api).
> > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > maybe we should just start a community-poll about it.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1]
> > > >
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > >
> > > >
> > > >
> > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > :
> > > > >
> > > > > Hi,
> > > > >
> > > > > last week i had some time and migrated almost all still existing
> > > modules
> > > > to
> > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > AFAICS servlet, bean-validation has been removed, also other small
> > > pieces
> > > > > of core.
> > > > >
> > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > (persistence and faces).
> > > > > WDYT guys?
> > > > >
> > > > > After that rename and reintroduce the scheduler module, i would be
> > > happy
> > > > > enough to release a RC1.
> > > > >
> > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > Any other topics we need to address?
> > > > >
> > > > > Best regards,
> > > > > Thomas
> > > >
> > >
> >

Re: Jakarta EE / DeltaSpike 2.0 Status

[Gerhard Petracek]

hi thomas,

@entity-manager:
i mentioned that, but it (@PersistenceUnitName) was always more like
an optional benefit (depending on your application-setup).
i guess e.g. mark might disagree with that, however, imo the majority
isn't using it (at least once you are using an ee-server).
the rest in that area is mainly integration-code and documentation
about the proper usage
(and nothing ds provides as a feature for users).

@persistence-xml (utils):
i know and you know it, because you promoted it.
however, it isn't that well known (it's "hidden" in the "spi"-package
and not even mentioned in our documentation).

therefore, the main part for users (also if you have a look at the
documentation) is about transactions (and topics related to it).
(if you skip the options for the entity-manager usages which aren't
provided by ds itself.)

regards,
gerhard



Am Di., 4. Apr. 2023 um 09:57 Uhr schrieb Thomas Andraschko



:
>
> JPA is also about reading the JPA XML descriptors and resolving
> EntityManagers, which is both heavily used in the Data module.
> So its currently much more than TX. I would rename it to ds-persistence and
> ds-faces.
>
> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> gpetra...@apache.org>:
>
> > hi thomas,
> >
> > we need to fix the rat-check (see [1]).
> >
> > @renaming the modules:
> > the jpa-module was always mainly about the "entitymanager" +
> > "transaction" (see the package-naming)... with the main focus on
> > transactions (see @Transactional and @TransactionScoped as the main
> > api).
> > therefore we almost renamed it to ds-tx (in the beginning). we just
> > kept 'jpa', because it wasn't clear what we might add later on.
> > maybe we should just start a community-poll about it.
> >
> > regards,
> > gerhard
> >
> > [1]
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >
> >
> >
> > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > :
> > >
> > > Hi,
> > >
> > > last week i had some time and migrated almost all still existing modules
> > to
> > > Jakarta. Only scheduler is currently not migrated.
> > > AFAICS servlet, bean-validation has been removed, also other small pieces
> > > of core.
> > >
> > > I would also like to rename jpa and jsf to their new jakarta name
> > > (persistence and faces).
> > > WDYT guys?
> > >
> > > After that rename and reintroduce the scheduler module, i would be happy
> > > enough to release a RC1.
> > >
> > > AFAICS a big missing part are the tests on real containers?!
> > > Any other topics we need to address?
> > >
> > > Best regards,
> > > Thomas
> >

Re: Jakarta EE / DeltaSpike 2.0 Status

[Gerhard Petracek]

hi thomas,

we need to fix the rat-check (see [1]).

@renaming the modules:
the jpa-module was always mainly about the "entitymanager" +
"transaction" (see the package-naming)... with the main focus on
transactions (see @Transactional and @TransactionScoped as the main
api).
therefore we almost renamed it to ds-tx (in the beginning). we just
kept 'jpa', because it wasn't clear what we might add later on.
maybe we should just start a community-poll about it.

regards,
gerhard

[1] https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/



Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
:
>
> Hi,
>
> last week i had some time and migrated almost all still existing modules to
> Jakarta. Only scheduler is currently not migrated.
> AFAICS servlet, bean-validation has been removed, also other small pieces
> of core.
>
> I would also like to rename jpa and jsf to their new jakarta name
> (persistence and faces).
> WDYT guys?
>
> After that rename and reintroduce the scheduler module, i would be happy
> enough to release a RC1.
>
> AFAICS a big missing part are the tests on real containers?!
> Any other topics we need to address?
>
> Best regards,
> Thomas

[jira] [Created] (DELTASPIKE-1460) Move outdated APIs

[Gerhard Petracek (Jira)]

Gerhard Petracek created DELTASPIKE-1460:


 Summary: Move outdated APIs
 Key: DELTASPIKE-1460
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1460
 Project: DeltaSpike
  Issue Type: Sub-task
  Security Level: public (Regular issues)
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek


some parts of the api aren't needed with cdi 2.0+

therefore that parts should be moved until they get removed completely.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: JSF/Selenium Question for Wildfly 14

[Gerhard Petracek]

hi mark,

if it still works with wf13 (and therefore jsf 2.2), our approach is
just not compatible with jsf/mojarra 2.3+ (it ships such an
injection-support out-of-the-box).
in that case we would need an auto-detection for
JsfModuleConfig#isContainerManagedConvertersEnabled and
#isContainerManagedValidatorsEnabled.

regards,
gerhard

Am Di., 25. Aug. 2020 um 22:17 Uhr schrieb Mark Struberg
:
>
> hi folks!
>
> I've fixed quite a few failing tests on Wildfly.
> Seems that CDI.current() doesn't work well with wildfly on EARs. Funnily they 
> work perfectly fine in pure WAR scenarios.
> As a workaround we switched off using CDI.current() and fall back to the 
> Extension BeanManager for the EAR tests.
>
> There is still a random failing behaviour in Wildfly-13.0.0.Final for those 
> tests.
>
> In Wildfly-14.0.1.Final those tests *most times* do succeed!
> But there is another problem in WF14: the JSF tests do fail because injection 
> of CDI Beans into FacesValidators seems to not work properly.
>
>
>   javax.servlet.ServletException
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
> at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at 
> io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> 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.ServletChain$1.handleRequest(ServletChain.java:68)
> at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at 
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at 
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at 
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at 
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at 
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at 
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at 
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at 
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at 
> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at 
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at 
> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at 
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at 
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at 
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at 
> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at 
> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at 
> 

Re: [VOTE] Release Apache DeltaSpike-1.9.4

[Gerhard Petracek]

+1

regards,
gerhard



Am Mi., 3. Juni 2020 um 09:44 Uhr schrieb Mark Struberg
:
>
> Hi!
>
> I've rolled the release for Apache DeltaSpike-1.9.4
>
> The following tickets got resolved:
>
> Bug
>
> [DELTASPIKE-1403 ] - 
> Site has no reference to the release of version 1.9.3
> [DELTASPIKE-1408 ] - 
> Some Weld versions fail on CDI.current() depending on the ClassLoader setup
> [DELTASPIKE-1409 ] - 
> ProjectStageTestControlTest doesn't work on Weld2
> Improvement
>
> [DELTASPIKE-1358 ] - 
> Move shaded ASM classes from proxy-impl into a separate JAR or update ASM
> [DELTASPIKE-1402 ] - 
> ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during 
> runtime
> [DELTASPIKE-1405 ] - 
> upgrade to apache-parent 23 and fix distribution
> Wish
>
> [DELTASPIKE-1397 ] - 
> Detect the cycled variable references
> Task
>
> [DELTASPIKE-1404 ] - 
> News links to post and examples.
>
> The staging repo can be found here:
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/ 
> 
>
> commit in our git repo is 370c0136ec5f597aee0c49b443a200ef0e3590e3
>
> The source zip is:
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/org/apache/deltaspike/deltaspike/1.9.4/
>  
> 
> sha1 is 49238449e9d37de1108cd353b6e4b2c476cfaf46
>
>
> 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: Deltaspike 1.8.2 -> 1.9.3

[Gerhard Petracek]

@thomas (a.)
i'm a bit concerned about the handling of weld in that area (since i
know quite a lot home-grown helpers in libs and projects, which beak
as well).
however, at least the fallback to #resolveBeanManagerViaJndi should
fix the issue for weld based ee-servers.

in any case, we should continue this thread on the dev-list.

regards,
gerhard


Am Mo., 13. Apr. 2020 um 00:03 Uhr schrieb Gerhard Petracek
:
>
> @thomas (k.):
> you couldn't see it due to the log-level.
>
> the cause is:
> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001328:
> Unable to identify the correct BeanManager. The calling class
> sun.reflect.GeneratedMethodAccessor159 is not placed in bean archive
> at org.jboss.weld.SimpleCDI.unsatisfiedBeanManager(SimpleCDI.java:89)
> ...
>
> regards,
> gerhard
>
>
>
> Am So., 12. Apr. 2020 um 20:59 Uhr schrieb Thomas Kernstock
> :
> >
> > Servus Gerhard,
> >
> > I recently mailed with mark regarding that problem and created a small 
> > testproject. Pls find it under 
> > https://drive.google.com/drive/folders/1NgywZX73QViiM39DTaghigN7hKBxyfsj?usp=sharing.
> >  When I deploy it on Payara 5.201 the error occurs after accessing the main 
> > URL.
> >
> > I also checked the log file (see attachment) and couldn't find the 
> > mentioned message.
> >
> > Lg
> > Thomas
> >
> > -Ursprüngliche Nachricht-
> > Von: Gerhard Petracek 
> > Gesendet: Sonntag, 12. April 2020 11:08
> > An: us...@deltaspike.apache.org
> > Betreff: Re: Deltaspike 1.8.2 -> 1.9.3
> >
> > @thomas (k.):
> > please check if you can find
> >  "failed to delegate bean-manager lookup"
> > in your log/s...
> >
> >
> > @thomas (a.):
> > with the refactoring the fallback handling was dropped (which can cause a 
> > NPE).
> >
> > regards,
> > gerhard
> >
> >
> >
> > Am So., 12. Apr. 2020 um 10:52 Uhr schrieb Gerhard Petracek
> > :
> > >
> > > @mark:
> > > yes - it looks like the refactoring to the typed config mixed it up...
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > > Am Do., 9. Apr. 2020 um 14:15 Uhr schrieb Thomas Kernstock
> > > :
> > > >
> > > > Servus Mark,
> > > >
> > > > I replaced the deltaspike modules with version 1.9.3 again, to include 
> > > > the CDI check in. What I didn't see on the first try was the warning in 
> > > > eclipse, "No bean is eligible for injection to the injection point 
> > > > [JSR-365 §5.2.2]" for the Logger and the ApplicationConfig Bean which 
> > > > is located in another project. I don't know why this has to do with 
> > > > deltaspike, but this warning isn't there when I use 1.8.2. Furthermore 
> > > > the JBoss Tools CDI Builder produces a Nullpointer Exception while 
> > > > building the projects. This is very weird.
> > > >
> > > > Anyway - the following bean is called right after deployment. I 
> > > > debugged the CDI.current() and it seems to be fine. I can see the 
> > > > Beanmanager etc. So there are no null values.
> > > >
> > > > @Eager
> > > > @ApplicationScoped
> > > > public class ConfigureApplication {
> > > > @Inject ApplicationConfig appConfig;
> > > > @Inject Logger logger;
> > > > @Inject private ProjectStage projectStage;
> > > >
> > > > @PostConstruct
> > > > public void init(){
> > > > CDI cdi= CDI.current();
> > > >
> > > > if (ProjectStage.Production.equals(projectStage)) {
> > > > appConfig.setBetriebsmodusTest(false);
> > > > appConfig.setSendEmail(true);
> > > > } else {
> > > > appConfig.setSendEmail(false);
> > > > appConfig.setBetriebsmodusTest(true);
> > > > }
> > > > logger.info("=== StartupConfig was called. Serverinfo: 
> > > > " + ((ServletContext) 
> > > > FacesContext.getCurrentInstance().getExternalContext().getContext()).getServerInfo());
> > > > logger.info("=== JSF Stage: {} ", 
> > > > FacesContext.getCurrentInstance().getApplication().getProjectStage().toString());
> > > > logger.info("=

[jira] [Closed] (DELTASPIKE-1394) Injecting Data Repository in javafx controller causes connection pool reaching max size

[Gerhard Petracek (Jira)]

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

Gerhard Petracek closed DELTASPIKE-1394.


> Injecting Data Repository in javafx controller causes connection pool 
> reaching max size
> ---
>
> Key: DELTASPIKE-1394
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1394
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: abderrahim khaled
>Priority: Major
>
> injecting Data Repository in regular POJO doesn't cause the problem



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (DELTASPIKE-1394) Injecting Data Repository in javafx controller causes connection pool reaching max size

[Gerhard Petracek (Jira)]

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

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

> Injecting Data Repository in javafx controller causes connection pool 
> reaching max size
> ---
>
> Key: DELTASPIKE-1394
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1394
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: abderrahim khaled
>Priority: Major
>
> injecting Data Repository in regular POJO doesn't cause the problem



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (DELTASPIKE-1397) Detect the cycled variable references

[Gerhard Petracek (Jira)]

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

Gerhard Petracek reassigned DELTASPIKE-1397:


Assignee: Mark Struberg

> Detect the cycled variable references
> -
>
> Key: DELTASPIKE-1397
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1397
> Project: DeltaSpike
>  Issue Type: Wish
>  Security Level: public(Regular issues) 
>  Components: Configuration
>Affects Versions: 1.9.1
> Environment: JDK 1.8
>Reporter: Andrew Marinchuk
>Assignee: Mark Struberg
>Priority: Major
>
> Due to mistake in config file, we encountered the 
> java.lang.StackOverflowError.
> {code:title=properties}fs.docs.path=/opt/docsFolder
> fs.docs.path.IntegrationTest=/mnt/targetDocs
> fs.docs.path.Staging=${fs.docs.path.IntegrationTest}
> fs.docs.path.IntegrationTest=${fs.docs.path.IntegrationTest} <--- here is 
> invalid copy-pasted string
> fs.docs.path.Production=${fs.docs.path.IntegrationTest}{code}{code:title=stack
>  trace}
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(TypedResolverImpl.java:556)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.getPropertyValue(TypedResolverImpl.java:590)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveStringValue(TypedResolverImpl.java:436)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(TypedResolverImpl.java:556)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.getPropertyValue(TypedResolverImpl.java:590)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveStringValue(TypedResolverImpl.java:436)
>  
> at 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
>  {code}
> It's very hard to find the configuration variable with a self-referencing 
> problem because StackOverflowError's message does not contain information 
> about variable with problem.
> Wrapping each TypedResolver.getValue()'s call into try-catch is not the best 
> practice in app code, but it's possible to detect the simplest 
> self-referencing issues in 
> org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(String).
> The better (but much expensive) way is to track the reference chain during 
> resolving variables or catching the StackOverflowError in library's code 
> (it's not a good practice and will not help to find the core of reference 
> loop because try-catch should be done at the first TypedResolver.getValue()'s 
> call).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (DELTASPIKE-1399) Md5 and SHA1 are deprecated

[Gerhard Petracek (Jira)]

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

Gerhard Petracek reassigned DELTASPIKE-1399:


Assignee: Mark Struberg

> Md5 and SHA1 are deprecated
> ---
>
> Key: DELTASPIKE-1399
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1399
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Sebb
>Assignee: Mark Struberg
>Priority: Major
>
> MD5 and SHA1 were deprecated as hash methods quite some time ago.
> They should no longer be used.
> Please update your releases to use SHA256 or SHA512 and remove/update any 
> references to MD5 and SHA1 in download documentation.
> https://www.apache.org/dev/release-distribution#sigs-and-sums



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (DELTASPIKE-1400) Updating from 1.8.X to 1.9.X breaks

[Gerhard Petracek (Jira)]

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

Gerhard Petracek reassigned DELTASPIKE-1400:


Assignee: (was: Thomas Andraschko)

> Updating from 1.8.X to 1.9.X breaks
> ---
>
> Key: DELTASPIKE-1400
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1400
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade Apache DeltaSpike from 1.8.x to version 1.9.x. The 
> following code breaks.
> {code:java}
> import javax.inject.Inject;
> import org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(CdiTestRunner.class)
> public class Testdeltaspike
> {
> @Inject
> private ApplicationScopedBean applicationScopedBean;
> @Test
> public void injectionTest()
> {
> Assert.assertEquals(14, applicationScopedBean.getValue());
> }
> }
> {code}
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> public class ApplicationScopedBean
> {
> public int getValue()
> {
> return 14;
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> org.apache.webbeans.exception.WebBeansDeploymentException: 
> java.lang.IllegalArgumentException
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:121)
>   at 
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:122)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:68)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:75)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:472)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:371)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:393)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:144)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1108)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:129)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:142)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:95)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:117)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (DELTASPIKE-1400) Updating from 1.8.X to 1.9.X breaks

[Gerhard Petracek (Jira)]

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

Gerhard Petracek closed DELTASPIKE-1400.


> Updating from 1.8.X to 1.9.X breaks
> ---
>
> Key: DELTASPIKE-1400
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1400
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade Apache DeltaSpike from 1.8.x to version 1.9.x. The 
> following code breaks.
> {code:java}
> import javax.inject.Inject;
> import org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(CdiTestRunner.class)
> public class Testdeltaspike
> {
> @Inject
> private ApplicationScopedBean applicationScopedBean;
> @Test
> public void injectionTest()
> {
> Assert.assertEquals(14, applicationScopedBean.getValue());
> }
> }
> {code}
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> public class ApplicationScopedBean
> {
> public int getValue()
> {
> return 14;
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> org.apache.webbeans.exception.WebBeansDeploymentException: 
> java.lang.IllegalArgumentException
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:121)
>   at 
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:122)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:68)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:75)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:472)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:371)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:393)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:144)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1108)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:129)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:142)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:95)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:117)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (DELTASPIKE-1400) Updating from 1.8.X to 1.9.X breaks

[Gerhard Petracek (Jira)]

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

Gerhard Petracek resolved DELTASPIKE-1400.
--
Resolution: Invalid

@[~lingchao]:
it looks like you are using an old version of owb which isn't compatible with 
java 8 bytecode.
see DELTASPIKE-1321

therefore please upgrade the version of openwebbeans you are using.

> Updating from 1.8.X to 1.9.X breaks
> ---
>
> Key: DELTASPIKE-1400
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1400
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: xia0c
>Assignee: Thomas Andraschko
>Priority: Major
>
> When I try to upgrade Apache DeltaSpike from 1.8.x to version 1.9.x. The 
> following code breaks.
> {code:java}
> import javax.inject.Inject;
> import org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(CdiTestRunner.class)
> public class Testdeltaspike
> {
> @Inject
> private ApplicationScopedBean applicationScopedBean;
> @Test
> public void injectionTest()
> {
> Assert.assertEquals(14, applicationScopedBean.getValue());
> }
> }
> {code}
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> public class ApplicationScopedBean
> {
> public int getValue()
> {
> return 14;
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> org.apache.webbeans.exception.WebBeansDeploymentException: 
> java.lang.IllegalArgumentException
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:121)
>   at 
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:122)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:68)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:75)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:472)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:371)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:393)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:144)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1108)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:129)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:142)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:95)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:117)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (DELTASPIKE-1400) Updating from 1.8.X to 1.9.X breaks

[Gerhard Petracek (Jira)]

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

Gerhard Petracek reassigned DELTASPIKE-1400:


Assignee: Thomas Andraschko

> Updating from 1.8.X to 1.9.X breaks
> ---
>
> Key: DELTASPIKE-1400
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1400
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: xia0c
>Assignee: Thomas Andraschko
>Priority: Major
>
> When I try to upgrade Apache DeltaSpike from 1.8.x to version 1.9.x. The 
> following code breaks.
> {code:java}
> import javax.inject.Inject;
> import org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(CdiTestRunner.class)
> public class Testdeltaspike
> {
> @Inject
> private ApplicationScopedBean applicationScopedBean;
> @Test
> public void injectionTest()
> {
> Assert.assertEquals(14, applicationScopedBean.getValue());
> }
> }
> {code}
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> public class ApplicationScopedBean
> {
> public int getValue()
> {
> return 14;
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> org.apache.webbeans.exception.WebBeansDeploymentException: 
> java.lang.IllegalArgumentException
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:121)
>   at 
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:122)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:68)
>   at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:75)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:472)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:371)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:393)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:144)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at org.apache.xbean.asm4.ClassReader.(Unknown Source)
>   at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1108)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:129)
>   at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:142)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:95)
>   at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:117)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release of Apache DeltaSpike 1.9.2

[Gerhard Petracek]

+1

regards,
gerhard



Am Fr., 13. Dez. 2019 um 13:42 Uhr schrieb Thomas Andraschko
:
>
> Hi,
>
> I was running the needed tasks to get the 1.9.2 release of Apache
> DeltaSpike out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and will get pushed to the ASF repository
> once the vote passed.
>
> Please take a look at the 1.9.2 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see [4]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released, and why..
> 
>
> Thanks,
> [name]
>
> [1] 
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1053/
> [2] 
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1053/org/apache/deltaspike/deltaspike/1.9.2/deltaspike-1.9.2-source-release.zip
> [3] https://github.com/tandraschko/deltaspike-vote/tree/deltaspike-1.9.2
> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: DeltaSpike 1.9.2?

[Gerhard Petracek]

+1

regards,
gerhard



Am Do., 12. Dez. 2019 um 13:30 Uhr schrieb Thomas Andraschko
:
>
> Hi,
>
> i would like to trigger the release process today.
> Everyone ok with it?
>
> Best regards,
> Thomas

Re: [DISUSS] do a 1.9.2 release?

[Gerhard Petracek]

+1

regards,
gerhard



Am Fr., 15. Nov. 2019 um 11:13 Uhr schrieb Mark Struberg
:
>
> Hi folks!
>
> What do you think about running a DeltaSpike-1.9.2 release?
>
> LieGrue,
> strub
>

Re: DeltaspikeData not initialized in UnitTest?

[Gerhard Petracek]

hi thomas,

since your repository works basically and the NPE occurs in hibernate,
it sounds like a hibernate init-bug.
if your setup requires some kind of init-logic (for whatever reason),
you can provide a custom implementation of the ExternalContainer spi
[1].

regards,
gerhard

[1] 
http://deltaspike.apache.org/documentation/test-control.html#ExternalContainer



Am So., 10. Nov. 2019 um 20:15 Uhr schrieb Thomas Frühbeck
:
>
> Hi,
> I just found a phenomenon which I would like to discuss before posting a
> bug.
>
> I have a UnitTest using CDITestRunner which accesses JPA persistence via
> Repositories.
> The _first_ test accessing the Repository gets an NPE from JPA - see below.
>
> Debugging shows, that at first access the SetAttribute in this case is
> NULL!!
>
> public JoinBuilder(Criteria criteria, JoinType joinType,
> SetAttribute set)
> {
> this(criteria, joinType);
> this.set = set; <-- is NULL at first run!!
> }
>
> So the JoinBuilder cannot create a correct Predicate and returns null.
>
> Solution was: run some unnecessary query @Before, so that everything is
> initialized
>
> Is this something known to the informed user, that I missed until now?
>
> Many thanks and best regards,
> Thomas
>
>
> java.lang.NullPointerException
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.constructJoin(AbstractFromImpl.java:385)
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:373)
> at
> org.hibernate.jpa.criteria.path.AbstractFromImpl.join(AbstractFromImpl.java:364)
> at
> org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.joinMap(JoinBuilder.java:153)
> at
> org.apache.deltaspike.data.impl.criteria.predicate.JoinBuilder.build(JoinBuilder.java:108)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:291)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:155)
> at
> org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:109)
> at at.tfr.pfad.dao.SquadRepository.findByAssistant(SquadRepository.java:46)
> at at.tfr.pfad.processing.MemberValidator.validate(MemberValidator.java:133)
> at
> at.tfr.pfad.view.TestDownloadBean.testValidationTruppVerein(TestDownloadBean.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:359)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:331)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:190)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:78)

Re: [COMMUNITY] DeltaSpike += Christian Beikov

[Gerhard Petracek]

welcome!

regards,
gerhard



Am Mo., 21. Okt. 2019 um 10:16 Uhr schrieb Thomas Andraschko
:
>
>  The DeltaSpike PMC is proud to announce a new addition to our community.
>
> Please welcome Christian Beikov as the newest DeltaSpike committer!
>
> @Christian:
> Please add yourself to the developers section (in
> deltaspike/parent/pom.xml).
>
> Welcome & Best regards,
> Thomas

[jira] [Updated] (DELTASPIKE-1385) support init under high load

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek updated DELTASPIKE-1385:
-
Description: init under high load might fail in rare cases currently

> support init under high load
> 
>
> Key: DELTASPIKE-1385
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: BeanValidation-Module, Core, JSF-Module
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.9.1
>
>
> init under high load might fail in rare cases currently



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (DELTASPIKE-1385) support init under high load

[Gerhard Petracek (JIRA)]

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

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

> support init under high load
> 
>
> Key: DELTASPIKE-1385
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: BeanValidation-Module, Core, JSF-Module
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.9.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (DELTASPIKE-1385) support init under high load

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek updated DELTASPIKE-1385:
-
Affects Version/s: 1.9.0

> support init under high load
> 
>
> Key: DELTASPIKE-1385
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: BeanValidation-Module, Core, JSF-Module
>Affects Versions: 1.9.0
>Reporter: Gerhard Petracek
>    Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.9.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

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

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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

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

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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