Weld 3.1.5.Final is now released

[Matej Novotny]

New version of Weld (3.1.5.Final) and Weld API (3.1.SP3) has just landed in 
Maven Central.
See release notes for more details - 
http://weld.cdi-spec.org/news/2020/08/12/weld-315Final/

Regards
Matej

Weld 3.1.3.Final released

[Matej Novotny]

Weld 3.1.3.Final is out along with Weld API 3.1.SP2.
More information can be found here - 
http://weld.cdi-spec.org/news/2019/11/28/weld-313Final/

Have a great day!
Matej

Weld 3.1.2.Final is now available

[Matej Novotny]

Hello,

new Weld version is available - Weld 3.1.2.Final and Weld API 3.1.SP1.
It is mainly bug fixing version, you can read more here - 
http://weld.cdi-spec.org/news/2019/08/06/weld-312Final/

Regards
Matej

Weld 3.1.0.Final released

[Matej Novotny]

Weld 3.1.0.Final has been released, part of the release is also new 3.1.Final 
API.

This version brings few new features such as CDI context propagation SPI, 
InterceptionFactory on interfaces and more.
Part of it are SPI changes which affect all integrators, please read our 
announcement post for more information.
Link - http://weld.cdi-spec.org/news/2019/02/06/weld-310Final/

Regards
Matej

Weld 2.4.8.Final released

[Matej Novotny]

Hello,

maintenance release of Weld 2.4 is out.
For more information, please refer to 
http://weld.cdi-spec.org/news/2018/09/26/weld-248Final/

Regards
Matej

[jira] [Commented] (DELTASPIKE-1318) Unsatisfied dependencies for type ApplicationContext (deltaspike-cdictrl-weld) in payara 4.1.2.174

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1318:
---

It should be injectable,  according to 
[docs|http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_managing_the_built_in_contexts]
 it is _unmanaged_ and _unbound_ context.

Can you try injecting {{ApplicationContext}} somewhere else in your app without 
using DS? Having the result of that we could see if the problem is in your 
app(or paraya/osgi) or in DS.

Alternatively, if you can provide a  reproducer?

> Unsatisfied dependencies for type ApplicationContext 
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Assignee: Matej Novotny
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>  
> Maven dependencies
> {code:java}
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
> 
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
> 
> {code}
>  Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
>   @Inject
>   private ContextControl contextControl;
>   ...
> }{code}
>  payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026] 
> [javax.enterprise.system.core] [tid: _ThreadID=47 
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713] 
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment 
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext 
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private 
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at 
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at 
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at 
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at 
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> 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

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

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1338:
---

Well, I am not debating the usefulness of such a rule, just saying that there 
will be failures because Weld works just like spec stated it back there.

> 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] [Commented] (DELTASPIKE-1338) support class-filter per test

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1338:
---

Tests are failing with {{Weld2}} profile because according to CDI 1.2 spec you 
cannot have an enabled alternative declared in {{beans.xml}} which is not 
actually a bean.

This was later on changed for CDI 2.0 (which is why \{{Weld3}} profile works 
just fine), or reverted to what it was prior to 1.2, if you like.

 

The change was covered in https://issues.jboss.org/browse/CDI-627

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

Weld 3.0.5.Final released

[Matej Novotny]

Hello,

Weld 3.0.5.Final was released along with Weld API 3.0.SP4 (and CDI API 2.0.SP1).
For more information, check our release notes -> 
http://weld.cdi-spec.org/news/2018/07/26/weld-305Final/

Matej

Re: CI for Weld2 error

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

Weld 3.0.4.Final + Weld API 3.0.SP3

[Matej Novotny]

Weld 3.0.4.Final is out and so is Weld API 3.0.SP3 which goes along with it.
See also release announcement - 
http://weld.cdi-spec.org/news/2018/04/26/weld-304Final/

Matej

Weld 2.4.7.Final released && maintenance mode

[Matej Novotny]

Hello everyone,

Weld 2.4.7.Final (CDI 1.2) was released -> 
http://weld.cdi-spec.org/news/2018/03/20/weld-247Final

NOTE: With this release, Weld 2 enters maintenance mode; there will be no 
further active development on 2.x branch.

Regards
Matej

Weld 2.4.6.Final released + new API version

[Matej Novotny]

Hello,

Weld 2.4.6.Final was released.
There is also a new API, 2.4.SP2, to go along with it.

You can read more about it here -> 
http://weld.cdi-spec.org/news/2017/12/18/weld-246Final/

Matej

Re: CI for DeltaSpike?

[Matej Novotny]

j
> > You also reopened a issue that i created.
> > I'm currently in brasil, so i dont have time to look at it.
> > I removed this call as its actually not required and the wrapping in
> > PrimeFaces works fine. Not sure why it breaks navigation but we can simple
> > revert it for this release.
> >
> > Am Freitag, 1. Dezember 2017 schrieb Gerhard Petracek :
> >
> > > hi matej,
> > >
> > > imo the main point here is that in the past we received too many wrong
> > > failures and almost no commit really broke the backward compatibility.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2017-12-01 11:49 GMT+01:00 Matej Novotny <manov...@redhat.com
> > > <javascript:;>>:
> > >
> > > > Hi Gerhard,
> > > >
> > > > > i'm not sure if others are still following it. at the time i did the
> > > > > releases, it was a mandatory step.
> > > >
> > > > Yes, I hope nobody releases without actually testing it at all.
> > > > But this check IMO comes too late - there are multiple "fixes" present,
> > > > where the author apparently didn't even execute the tests.
> > > > Checking this before release means you bump into problems with issues
> > > > which were "fixed" six months ago.
> > > > Hence I am suggesting whether we shouldn't look into some more flexible
> > > > approach.
> > > > I know Travis still isn't quite the thing beucase of the structure, I
> > am
> > > > just trying to start a discussion here and see how people view thing -
> > > > maybe I am just weird with my requirements :)
> > > >
> > > > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > > > (it looks like nobody took over that part.)
> > > >
> > > > Would be great if this was still done, every new weld release is
> > > announced
> > > > directly on DS mailing list, so it's just about updating it.
> > > >
> > > >
> > > > Matej
> > > >
> > > > - Original Message -
> > > > > From: "Gerhard Petracek" <gpetra...@apache.org <javascript:;>>
> > > > > To: dev@deltaspike.apache.org <javascript:;>
> > > > > Sent: Thursday, November 30, 2017 3:32:04 PM
> > > > > Subject: Re: CI for DeltaSpike?
> > > > >
> > > > > hi matej,
> > > > >
> > > > > one of the (manual) steps for a release is to check those results
> > > > (before a
> > > > > release gets started at all).
> > > > > i'm not sure if others are still following it. at the time i did the
> > > > > releases, it was a mandatory step.
> > > > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > > > (it looks like nobody took over that part.)
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
> > > <javascript:;>>:
> > > > >
> > > > > > Sorry Matej, I don't get how Travis would help since you can do the
> > > > > > same with jenkins which is already configured.
> > > > > >
> > > > > > Having the default build running on both weld and OWB would be more
> > > > > > beneficial IMHO, but it is just the opinion from my side of the
> > fence
> > > > > > and experience.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > > > >
> > > > > >
> > > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com
> > > <javascript:;>>:
> > > > > > > Thanks, but it was more of a rhetorical question (you saved me
> > some
> > > > > > digging though).
> > > > > > > Still my claim holds true, nobody cares about them much. They
> > must
> > > > have
> > > > > > been failing for quite some time now
> > > > > > > Not to mention they aren't even updated to latest Weld version
> > (or
> > > > > > WildFly version for that matter).
>

[jira] [Reopened] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[Matej Novotny (JIRA)]

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

Matej Novotny reopened DELTASPIKE-940:
--

Commits for this issue break 120 tests in the module (over 2/3 of all tests in 
the module) on both WFLY and Tomee.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



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

Re: CI for DeltaSpike?

[Matej Novotny]

Hi Gerhard,

> i'm not sure if others are still following it. at the time i did the
> releases, it was a mandatory step.

Yes, I hope nobody releases without actually testing it at all.
But this check IMO comes too late - there are multiple "fixes" present, where 
the author apparently didn't even execute the tests.
Checking this before release means you bump into problems with issues which 
were "fixed" six months ago.
Hence I am suggesting whether we shouldn't look into some more flexible 
approach. 
I know Travis still isn't quite the thing beucase of the structure, I am just 
trying to start a discussion here and see how people view thing - maybe I am 
just weird with my requirements :)

> back then i also added ci-jobs for new owb/weld releases immediately.
> (it looks like nobody took over that part.)

Would be great if this was still done, every new weld release is announced 
directly on DS mailing list, so it's just about updating it.


Matej

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

[jira] [Reopened] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE

[Matej Novotny (JIRA)]

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

Matej Novotny reopened DELTASPIKE-1282:
---

The [first commit 
here|https://github.com/apache/deltaspike/commit/a4998790afe24bde62ae3aa37e6a0c5728c81004]
 breaks a bunch of tests. Looks like the navigation in JSF stops working with 
it.

This can be tested/seen on both, WFLY and Tomee.

> DeltaSpikeFacesContextWrapper leaks on TomEE
> 
>
> Key: DELTASPIKE-1282
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1282
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.8.0
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.8.1
>
>




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

Re: CI for DeltaSpike?

[Matej Novotny]

Thanks, but it was more of a rhetorical question (you saved me some digging 
though).
Still my claim holds true, nobody cares about them much. They must have been 
failing for quite some time now
Not to mention they aren't even updated to latest Weld version (or WildFly 
version for that matter).


Matej

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

[jira] [Resolved] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1304.
---
Resolution: Fixed

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>    Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



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

[jira] [Commented] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1304:
---

Oops, excuse the typo in commit message, obviously it should say "CdiTestRunner 
will *now* use..."

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



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

[jira] [Created] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1304:
-

 Summary: Make CdiTestRunner use "flat" deployment on Weld by 
default
 Key: DELTASPIKE-1304
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: Matej Novotny


In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
but is still configurable.

Since DS depends on Weld 1.x API, there is no option to configure this via 
{{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
property.

Flat deployment would eliminate some test problems as, for instance, custom 
{{MockManager}}. Namely 
[{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
 and the test linked to it which breaks all tests in that module for Weld.
The reason is that it uses {{beans.xml}} to enable alternatives, which in Weld 
only works for given bean archive (e.g. this leads to eternal Holy Bean Archive 
War between Weld and OWB interpretations :) ).
Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
is unit test level and the "flatness" doesn't really matter there.



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

[jira] [Updated] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

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

Matej Novotny updated DELTASPIKE-1304:
--
Fix Version/s: 1.8.1

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>    Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



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

[jira] [Assigned] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

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

Matej Novotny reassigned DELTASPIKE-1304:
-

Assignee: Matej Novotny

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>    Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



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

CI for DeltaSpike?

[Matej Novotny]

Hello

I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant 
Integration OFC) and DeltaSpike.
Apparently, there is no such thing now and even while some CI jobs exist (where 
are they, anyway?), nobody really pays attention to them.
I mean those for Weld ones must have been failing for few months and yet the 
JIRAs causing that were happily marked as Resolved.
Meaning whoever fixed that probably only ran smoke tests with OWB.

Today I noticed there is going to be a release soon and so I quikly went to 
check how the build/tests fare with Weld profiles.
Turned out to be a disaster. So I then have to spend considerable time 
backtracking the changes and figuring out the actual problem.
And it's not the first time this happened either.

Therefore I wanted to bring up the topic of CI to avoid this in the future. The 
ideal scenario is sending PRs and having them checked *before* merging - 
obviously not an option here.
The GH repo is but a mirror (something we have to stick to I presume) which 
makes it more complex, but still, it should be possible to set up a Travis 
build on GH master which will execute after every sync.
That way the failures would be readily visible (via the travis status "button").
In order to discover most problems there is no need for a complete test matrix, 
it would do to just have two version of OWB and Weld without EE container (with 
just the Arq. one).


A penny for your thoughts?


Regards
Matej

Re: [DISCUSS] releasing 1.8.1?

[Matej Novotny]

Give it a while please, as you noticed I am going through it now and finding 
troubles running it with some of the latest fixes on Weld.
I only have so much spare time on my hands, but I should have gone over it by 
Fri I think.

Matej


- Original Message -
> From: "Mark Struberg" 
> To: "deltaspike" 
> Sent: Wednesday, November 29, 2017 8:48:14 AM
> Subject: [DISCUSS] releasing 1.8.1?
> 
> hi folks!
> 
> I'd like to release 1.8.1 in my spare cycles over the next days.
> Any objections?
> 
> Would be way cool if people could glimpse through their tickets and
> update/resolve them accordingly.
> 
> txs and LieGrue,
> strub
> 
> 

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

[Matej Novotny (JIRA)]

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

Matej Novotny edited comment on DELTASPIKE-1294 at 11/29/17 2:22 PM:
-

I'll try to explain a tad bit differently then... (sorry if it's too verbose)

Even on new servers (WildFly 11), where 
{{invocationContext.getTarget().getClass()}} will work and will be used but the 
tests will fail. In such case the code assumes that doing 
{{invocationContext.getTarget().getClass().getAnnotations()}} will return all 
the annotations, amongst which there should be {{@Secured}} or the 
{{@Stereotype}} with the Secured one hidden inside.
That is (and always was) untrue in Weld as 
{{invocationContext.getTarget().getClass()}} will give you a proxy of the 
actual bean instance and this proxy only contains annotations which are 
{{@Inherited}}.

Hence *the fallback you mention will never be used on, for instance, WildFly 
11* and the code will fail to find the annotations.
The reason why the previous solution (== current "fallback") worked is because 
{{invocationContext.getMethod().getDeclaringClass()}} returns the actual bean 
class (not proxy class) and that one has the annotation. But obviously, this 
fails for the test with parent class.

Is this understandable?


was (Author: manovotn):
I'll try to explain a tad bit differently then... (sorry if it's too verbose)

Even on new servers (WildFly 11), where 
{{invocationContext.getTarget().getClass()}} will work and will be used but the 
tests will fail. In such case the code assumes that doing 
{{invocationContext.getTarget().getClass().getAnnotations()}} will return all 
the annotations, amongst which there should be {{@Secured}} or the 
{{@Stereotype}} with the Secured one hidden inside.
That is (and always was) untrue in Weld as 
{{invocationContext.getTarget().getClass()}} will give you a proxy of the 
actual bean instance and this proxy only contains annotations which are 
{{@Inherited}}.

Hence *the fallback you mention will never be used on, for instance, WildFly 11 
*and the code will fail to find the annotations.
The reason why the previous solution (== current "fallback") worked is because 
{{invocationContext.getMethod().getDeclaringClass()}} returns the actual bean 
class (not proxy class) and that one has the annotation. But obviously, this 
fails for the test with parent class.

Is this understandable?

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



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

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

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1294:
---

I'll try to explain a tad bit differently then... (sorry if it's too verbose)

Even on new servers (WildFly 11), where 
{{invocationContext.getTarget().getClass()}} will work and will be used but the 
tests will fail. In such case the code assumes that doing 
{{invocationContext.getTarget().getClass().getAnnotations()}} will return all 
the annotations, amongst which there should be {{@Secured}} or the 
{{@Stereotype}} with the Secured one hidden inside.
That is (and always was) untrue in Weld as 
{{invocationContext.getTarget().getClass()}} will give you a proxy of the 
actual bean instance and this proxy only contains annotations which are 
{{@Inherited}}.

Hence *the fallback you mention will never be used on, for instance, WildFly 11 
*and the code will fail to find the annotations.
The reason why the previous solution (== current "fallback") worked is because 
{{invocationContext.getMethod().getDeclaringClass()}} returns the actual bean 
class (not proxy class) and that one has the annotation. But obviously, this 
fails for the test with parent class.

Is this understandable?

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



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

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

[Matej Novotny (JIRA)]

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

Matej Novotny reopened DELTASPIKE-1294:
---

The code change breaks this for Weld as it relies on OWB's internal behavior - 
e.g. copying annotations onto proxy classes.

Namely on {{invocationContext.getTarget().getClass()}} (which will return 
proxy) having the {{@Secured}} annotation present. See the 
[code|https://github.com/apache/deltaspike/commit/b1903c2b3463dfa368d0fe973c72f2055c838bf6#diff-b97fd89797e4c626bf91e494fd981192R90].

With Weld, the annotations are only there if they are {{@Inherited}}. Therefore 
making {{@Secured}} inherited would *partly* fix this issue, but it would be 
still broken for stereotypes (which aren't inherited). Hence the only 
full-blown fix would be to get the target class (via 
{{invocationContext.getTarget().getClass()}}) and then inspect the hierarchy of 
classes?

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



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

[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1296:
---

[~struberg] The commit/fix is against 
[specification|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#beanmanager] as 
you are not allowed to invoke {{BeanManager.getReference()}} before 
{{AfterDeploymentValidation}}. I just run the build with Weld 3 and it crashes 
there (as expected) on DefinitionException.

> PropertyFileConfig doesn't work with internal extensions
> 
>
> Key: DELTASPIKE-1296
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>
> We register PropertyFileConfig in AfterDeploymentValidation hook but 
> extensions potentially already read the config entries. Technically there is 
> probably no blocker to do it earlier and we should probably ensure all our 
> extensions read keys in AfterDeploymentValidation.
> My use case was a configured cron expression in the scheduler usage.



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

Weld 3.0.2.Final released

[Matej Novotny]

Weld 3.0.2.Final is out!
Check out release post for more information - 
http://weld.cdi-spec.org/news/2017/11/23/weld-302Final/

Matej

Weld 2.4.5.Final released

[Matej Novotny]

Bugfix release of Weld 2 branch, CDI 1.2, is out.
Check the news post for 2.4.5.Final to learn details - 
http://weld.cdi-spec.org/news/2017/09/11/weld-245Final/

Re: [weld-dev] Weld 3.0.1.Final released

[Matej Novotny]

Yep, my bad. It should indeed be "will now implement" :)

Matej

- Original Message -
> From: "arjan tijms" <arjan.ti...@gmail.com>
> To: "Matej Novotny" <manov...@redhat.com>
> Cc: "Weld" <weld-...@lists.jboss.org>, dev@deltaspike.apache.org
> Sent: Thursday, August 24, 2017 11:38:13 PM
> Subject: Re: [weld-dev] Weld 3.0.1.Final released
> 
> >Every Weld-enhanced object (subclass/proxy) will not implement
> 
> Should that be "will now implement"?
> 
> On Thu, Aug 24, 2017 at 6:36 PM, Matej Novotny <manov...@redhat.com> wrote:
> 
> > Hey, folks!
> >
> > Weld 3.0.1.Final is released.
> > Feel free to check Weld website for further information -
> > http://weld.cdi-spec.org/news/2017/08/25/weld-301Final/
> >
> > --
> > Novotny Matej
> > Red Hat Czech
> > ___
> > weld-dev mailing list
> > weld-...@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> 

Weld 3.0.1.Final released

[Matej Novotny]

Hey, folks!

Weld 3.0.1.Final is released.
Feel free to check Weld website for further information - 
http://weld.cdi-spec.org/news/2017/08/25/weld-301Final/

--
Novotny Matej
Red Hat Czech

Weld 2.4.4.Final released!

[Matej Novotny]

Weld 2.4.4.Final is now released!

For more information, see the new post on Weld website:
http://weld.cdi-spec.org/news/2017/06/14/weld-244Final/


Matej Novotny

Re: jbossas 7.1.1.Final build

[Matej Novotny]

Well, best would be to use EAP 6.4+, since there you got J8 support.
But I am not really sure how this stands from legal point of view - e.g. if you 
can simply download and use it.

As for fail fast - my quick guess would be to modify the profile and try maven 
enforcer with JDK version?

Matej

- Original Message -
> From: "Mark Struberg" <strub...@yahoo.de.INVALID>
> To: "deltaspike" <dev@deltaspike.apache.org>
> Sent: Monday, May 22, 2017 11:23:28 AM
> Subject: Re: jbossas 7.1.1.Final build
> 
> ouch, yes, that might have been the issue.
> I was definitely using Java8.
> 
> Will try later with j7.
> 
> Can we do anything to fail fast?
> 
> As John pointed out I fell over it a month ago myself - seems I'm an old
> senile guy already ;)
> 
> txs and LieGrue,
> strub
> 
> > Am 22.05.2017 um 10:05 schrieb Matej Novotny <manov...@redhat.com>:
> > 
> > Hi Mark,
> > 
> > I took a glance at this and 'mvn clean install -Pjbossas-build-managed-7'
> > works fine for me on current master.
> > Are you using Java 7? Because JBoss AS 7 requires that.
> > 
> > Matej
> > 
> > - Original Message -
> >> From: "Mark Struberg" <strub...@yahoo.de.INVALID>
> >> To: "Deltaspike" <dev@deltaspike.apache.org>
> >> Sent: Sunday, May 21, 2017 5:49:08 PM
> >> Subject: jbossas 7.1.1.Final build
> >> 
> >> Hi folks!
> >> 
> >> Could someone from JBoss take a quick look at the 7.1.1.Final build?
> >> 
> >> mvn clean install -Pjbossas-build-managed-7
> >> 
> >> This stops at core-impl. I literally mean 'stops'.
> >> 
> >> 
> >> txs and LieGrue,
> >> strub
> >> 
> 
> 

Re: jbossas 7.1.1.Final build

[Matej Novotny]

Hi Mark,

I took a glance at this and 'mvn clean install -Pjbossas-build-managed-7' works 
fine for me on current master.
Are you using Java 7? Because JBoss AS 7 requires that.

Matej

- Original Message -
> From: "Mark Struberg" 
> To: "Deltaspike" 
> Sent: Sunday, May 21, 2017 5:49:08 PM
> Subject: jbossas 7.1.1.Final build
> 
> Hi folks!
> 
> Could someone from JBoss take a quick look at the 7.1.1.Final build?
> 
> mvn clean install -Pjbossas-build-managed-7
> 
> This stops at core-impl. I literally mean 'stops'.
> 
> 
> txs and LieGrue,
> strub
> 

[jira] [Commented] (DELTASPIKE-1232) Weld 3.0.0.CR1 package changes causing build failures

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1232:
---

Can you point me to a doc which would stat this? I couldn't find it there. 
Also, I recall my conversation with Gerhard where he said its 1.1.9 that is 
minimum.

> Weld 3.0.0.CR1 package changes causing build failures
> -
>
> Key: DELTASPIKE-1232
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1232
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.2
>    Reporter: Matej Novotny
>    Assignee: Matej Novotny
> Fix For: 1.8.0
>
>
> Using Weld 3.0.0.CR1, Weld-container control module fails to build.
> The reason is the package change introduced as a part of Weld's JDK 9 early 
> adaptation (see [WELD-2305|https://issues.jboss.org/browse/WELD-2305]). This 
> was done to eliminate future package-clash problems.
> It should be investigated whether DS can depend on Weld API instead of 
> internals to handle container control as depending on internals is a bad 
> practice anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1232) Weld 3.0.0.CR1 package changes causing build failures

[Matej Novotny (JIRA)]

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

Matej Novotny updated DELTASPIKE-1232:
--
Fix Version/s: 1.8.0

> Weld 3.0.0.CR1 package changes causing build failures
> -
>
> Key: DELTASPIKE-1232
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1232
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.2
>    Reporter: Matej Novotny
>    Assignee: Matej Novotny
> Fix For: 1.8.0
>
>
> Using Weld 3.0.0.CR1, Weld-container control module fails to build.
> The reason is the package change introduced as a part of Weld's JDK 9 early 
> adaptation (see [WELD-2305|https://issues.jboss.org/browse/WELD-2305]). This 
> was done to eliminate future package-clash problems.
> It should be investigated whether DS can depend on Weld API instead of 
> internals to handle container control as depending on internals is a bad 
> practice anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1232) Weld 3.0.0.CR1 package changes causing build failures

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1232.
---
Resolution: Resolved

Should be addressed by [this 
commit|https://github.com/apache/deltaspike/commit/b4126f708c8d163c660bac23230ca670a17e26c6].
I also removed one if block which was meant for really old version of Weld 
(<1.1.9). It caused dependency on Weld internals and I believe the version 
isn't even supported any more.

> Weld 3.0.0.CR1 package changes causing build failures
> -
>
> Key: DELTASPIKE-1232
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1232
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.2
>    Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.0
>
>
> Using Weld 3.0.0.CR1, Weld-container control module fails to build.
> The reason is the package change introduced as a part of Weld's JDK 9 early 
> adaptation (see [WELD-2305|https://issues.jboss.org/browse/WELD-2305]). This 
> was done to eliminate future package-clash problems.
> It should be investigated whether DS can depend on Weld API instead of 
> internals to handle container control as depending on internals is a bad 
> practice anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: DS and CDI 2.0?

[Matej Novotny]

Not sure I am following you - how would you fix this then?

If you now take DS (master), and upgrade the CDI to 2.0.Beta1. Then have your 
JAVA_HOME point at 1.8 JDK.
Try to compile (I ran Weld build ofc, so "mvn clean install -PWeld3 
-Dweld.version=3.0.0.Beta1" but anything will do).
This gives you a bunch of compilation errors in `deltaspike-core-api` such as:

[ERROR] 
/home/manovotn/GitRepo/deltaspike/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/builder/AnnotatedParameterImpl.java:[29,0]
 error: AnnotatedParameterImpl is not abstract and does not override abstract 
method getAnnotations(Class) in Annotated
[ERROR] where T is a type-variable:
[ERROR] T extends Annotation declared in method getAnnotations(Class)

This is because CDI added default methods to interfaces which you implement.
Unless I set -source and -target to 1.8 both, there is no way it sees the 
default method.

Matej

- Original Message -
> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> To: dev@deltaspike.apache.org
> Cc: "Martin Kouba" <mko...@redhat.com>
> Sent: Tuesday, December 20, 2016 9:36:26 AM
> Subject: Re: DS and CDI 2.0?
> 
> Hi Matej,
> 
> about running DS it should be fine with a jdk 8 (or maven toolchain using
> java 6 to compile and 8 to run for weld 3 tests)
> 
> About CDI 2.0 I think it is a bit early and discussions - IIRC - didnt lead
> to any feature yet, just a "if we are blocked on 1 we can do a 2" but
> nothing yet motivating it. That said time is the only blocker if we find
> any feature deeply requiring CDI 2.
> 
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
> 
> 2016-12-20 9:33 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> 
> > Hello
> >
> > Since we got CDI 2.0 knocking on the door, I wanted to ask what are the
> > plans for DS in this regard?
> >
> > ATM CDI 2.0.Beta1 is out and Weld 3.0.0.Beta1 will follow shortly.
> > I tried building DS and running tests (with the above^) just out of habit,
> > but I realized that won't work.
> > Currently, DS has compilation source/target set to 1.6 and CDI 2.0 uses
> > default methods hence requiring 1.8.
> >
> > So before rushing into any duck tape fixing, I would like to know, what
> > are the plans?
> > I recall there was some mail discussion about new branch, but I don't
> > think there was any outcome.
> >
> >
> > Regards
> > Matej
> >
> 

DS and CDI 2.0?

[Matej Novotny]

Hello

Since we got CDI 2.0 knocking on the door, I wanted to ask what are the plans 
for DS in this regard?

ATM CDI 2.0.Beta1 is out and Weld 3.0.0.Beta1 will follow shortly.
I tried building DS and running tests (with the above^) just out of habit, but 
I realized that won't work.
Currently, DS has compilation source/target set to 1.6 and CDI 2.0 uses default 
methods hence requiring 1.8.

So before rushing into any duck tape fixing, I would like to know, what are the 
plans?
I recall there was some mail discussion about new branch, but I don't think 
there was any outcome.


Regards
Matej

[jira] [Resolved] (DELTASPIKE-1215) Java8Test failing with EAP 6.4

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1215.
---
Resolution: Fixed

Should be resolved with [this commit| 
https://github.com/apache/deltaspike/commit/ce6c9f4acc99fe13da5414373d7cdee94f51f474].

> Java8Test failing with EAP 6.4
> --
>
> Key: DELTASPIKE-1215
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1215
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Tests
>Affects Versions: 1.7.1
> Environment: EAP 6.4 (yes, it support Java 8)
> Weld 1.1.33.Final
>Reporter: Matej Novotny
>Assignee: Matej Novotny
>Priority: Minor
> Fix For: 1.7.2
>
>
> EAP 6.4 is executed with {{jbossas-managed-7}} profile which is missing 
> {{persistence.xml}} for this to work.
> Furthermore the test needs to explicitly {{flush()}} the EM, otherwise there 
> is a failure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1215) Java8Test failing with EAP 6.4

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1215:
-

 Summary: Java8Test failing with EAP 6.4
 Key: DELTASPIKE-1215
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1215
 Project: DeltaSpike
  Issue Type: Task
  Components: Tests
Affects Versions: 1.7.1
 Environment: EAP 6.4 (yes, it support Java 8)
Weld 1.1.33.Final
Reporter: Matej Novotny
Assignee: Matej Novotny
Priority: Minor
 Fix For: 1.7.2


EAP 6.4 is executed with {{jbossas-managed-7}} profile which is missing 
{{persistence.xml}} for this to work.

Furthermore the test needs to explicitly {{flush()}} the EM, otherwise there is 
a failure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1204) Wildfly managed profiles blow up

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1204.
---
   Resolution: Resolved
Fix Version/s: 1.7.2

Since there were no comments/objections I [pushed my 
solution|https://github.com/apache/deltaspike/commit/3fed4bfb910abf3e58b8e12fd6cead76aaddad9a].
 Marking this issue as resolved.

> Wildfly managed profiles blow up
> 
>
> Key: DELTASPIKE-1204
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1204
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.7.1
> Environment: Wildfly managed (or build managed)
> Weld 2/3
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.7.2
>
>
> Using a Wildfly profile with Weld causes things to blow up when executed with 
> the following command {{mvn clean verify -Pwildfly-managed 
> -Dweld.version=3.0.0.Alpha17 
> -Dmaven.repo.local=/home/manovotn/anotherMvnRepo}}.
> There are two problems I detected so far:
>  # Compilation error (with clean Mvn repo)
>  * CDI control module - weld impl - is based on Weld version passed as 
> parameter
>  * However, currently there is hardcoded cdi-api version in the [wildfly 
> profile|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L1074]
>  * Granted, it is {{provided}}, therefore the tests run fine on the Wildfly 
> server, but the compilation of CDI control module will blow up as it now uses 
> Weld 3.x and CDI 1.1 API
>  # At the moment, the CDI control module uses maven dependency plugin to 
> unpack tck tests as test classes no matter the profile
>  * as can be seen 
> [here|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/pom.xml#L83]
>  * this makes no sense when running wildfly profile
>  * not to mention you do not have dependency on arq-weld-container so you 
> cannot even execute it
> Proposed solution:
> # A dependency on cdi-api needs to be added to this profile
>  * it cannot be hardcoded (weld 2 used CDI 1.2, but weld 3 keeps up with 
> latest CDI 2 EDR releases)
>  * We can either add a new build property like {{cdi.version}}
>  ** this is all the more error prone
>  ** if you don't pass this in, things get really weird
>  * We can fetch it in by declaring a dep. on a weld artifact, which has it
>  ** e.g. adding a dependency on {{weld-core-impl}} which uses already defined 
> {{weld.version}} will fetch in the required cdi-api as well
>  # Simply extend the Weld1/2/3 profiles and copy the build step into them
>  * it makes no sense to add these sources when running different profiles
> Current draft of what I have in mind can be seen [on top of my 
> branch|https://github.com/manovotn/deltaspike/tree/wflyManagedFix].
> **Comments are welcome as I am not sure what I suggested above is a good 
> way.**
> Note that this should effect builds with Weld 2 and Weld 3 as they both use 
> the very same profile for wildfly. Even  though I currently tested this with 
> Weld 3 only (getting to Weld 2 atm).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1199.
---
Resolution: Fixed

[~Seto] I pushed the 
[commit|https://github.com/apache/deltaspike/commit/552891f58e4359c884d4b67def72cbc68430d224]
 to DS repo - feel free to try it.
It should avoid the duplicit instantiation of AppScoped stuff.

>  Problems with ContextControl and Weld ContainerInitialized, 
> ContainerShutdown event.
> -
>
> Key: DELTASPIKE-1199
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1199
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.1
>Reporter: Seto
>Assignee: Matej Novotny
>
> No replies in user mail list. So I submit an issue here. And I think it's a 
> bug as well.
> I have an @ApplicationScoped bean. It observes ContainerInitialized and 
> ContainerShutdown event. 
> {code:title=Kernel.java|borderStyle=solid}
> public Kernel(){
> System.out.println("Kernel constructed");
> }
> public void onContainerInitialized(@Observes ContainerInitialized event, 
> @Parameters List parameters) {
> System.out.println("container initialized");
> }
> public void onContainerShutdown(@Observes ContainerShutdown event){
> System.out.println("container shutdown");
> }
> {code}
> Then the kernel is constructed twice with the code below, one after boot, one 
> after shutdown.
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String[] args) {
> CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
> cdiContainer.boot();
> // Starting the application-context enables use of @ApplicationScoped 
> beans
> ContextControl contextControl = cdiContainer.getContextControl();
> contextControl.startContext(ApplicationScoped.class);
> // You can use CDI here
> contextControl.stopContext(ApplicationScoped.class);
> cdiContainer.shutdown();
> }
> }
> {code}
> If I remove the ContextControl related code. Then it is constructed only once 
> after boot.
> If I keep the ContextControl related code and remove the observation of 
> ContainerInitialized. Then it is constructed only after shutdown.
> If I keep the ContextControl related code and remove the observation of 
> ContainerShutdown. Then it is constructed only after boot.
> What I expect is it is constructed only once after boot even I keep the 
> ContextControl related code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.

[Matej Novotny (JIRA)]

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

Matej Novotny updated DELTASPIKE-1199:
--
Fix Version/s: 1.7.2

>  Problems with ContextControl and Weld ContainerInitialized, 
> ContainerShutdown event.
> -
>
> Key: DELTASPIKE-1199
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1199
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.1
>Reporter: Seto
>Assignee: Matej Novotny
> Fix For: 1.7.2
>
>
> No replies in user mail list. So I submit an issue here. And I think it's a 
> bug as well.
> I have an @ApplicationScoped bean. It observes ContainerInitialized and 
> ContainerShutdown event. 
> {code:title=Kernel.java|borderStyle=solid}
> public Kernel(){
> System.out.println("Kernel constructed");
> }
> public void onContainerInitialized(@Observes ContainerInitialized event, 
> @Parameters List parameters) {
> System.out.println("container initialized");
> }
> public void onContainerShutdown(@Observes ContainerShutdown event){
> System.out.println("container shutdown");
> }
> {code}
> Then the kernel is constructed twice with the code below, one after boot, one 
> after shutdown.
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String[] args) {
> CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
> cdiContainer.boot();
> // Starting the application-context enables use of @ApplicationScoped 
> beans
> ContextControl contextControl = cdiContainer.getContextControl();
> contextControl.startContext(ApplicationScoped.class);
> // You can use CDI here
> contextControl.stopContext(ApplicationScoped.class);
> cdiContainer.shutdown();
> }
> }
> {code}
> If I remove the ContextControl related code. Then it is constructed only once 
> after boot.
> If I keep the ContextControl related code and remove the observation of 
> ContainerInitialized. Then it is constructed only after shutdown.
> If I keep the ContextControl related code and remove the observation of 
> ContainerShutdown. Then it is constructed only after boot.
> What I expect is it is constructed only once after boot even I keep the 
> ContextControl related code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1199:
---

[This 
commit|https://github.com/manovotn/deltaspike/commit/552891f58e4359c884d4b67def72cbc68430d224]
 should do the trick (not, it's on my fork).
I'push it into DS repo later today.

>  Problems with ContextControl and Weld ContainerInitialized, 
> ContainerShutdown event.
> -
>
> Key: DELTASPIKE-1199
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1199
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.1
>Reporter: Seto
>
> No replies in user mail list. So I submit an issue here. And I think it's a 
> bug as well.
> I have an @ApplicationScoped bean. It observes ContainerInitialized and 
> ContainerShutdown event. 
> {code:title=Kernel.java|borderStyle=solid}
> public Kernel(){
> System.out.println("Kernel constructed");
> }
> public void onContainerInitialized(@Observes ContainerInitialized event, 
> @Parameters List parameters) {
> System.out.println("container initialized");
> }
> public void onContainerShutdown(@Observes ContainerShutdown event){
> System.out.println("container shutdown");
> }
> {code}
> Then the kernel is constructed twice with the code below, one after boot, one 
> after shutdown.
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String[] args) {
> CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
> cdiContainer.boot();
> // Starting the application-context enables use of @ApplicationScoped 
> beans
> ContextControl contextControl = cdiContainer.getContextControl();
> contextControl.startContext(ApplicationScoped.class);
> // You can use CDI here
> contextControl.stopContext(ApplicationScoped.class);
> cdiContainer.shutdown();
> }
> }
> {code}
> If I remove the ContextControl related code. Then it is constructed only once 
> after boot.
> If I keep the ContextControl related code and remove the observation of 
> ContainerInitialized. Then it is constructed only after shutdown.
> If I keep the ContextControl related code and remove the observation of 
> ContainerShutdown. Then it is constructed only after boot.
> What I expect is it is constructed only once after boot even I keep the 
> ContextControl related code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1175) Weld(1|2|3) profiles do not activate Weld profile in cdictrl

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1175:
---

It cannot even detect Weld profiles because the parent of {{cdictrl}} is 
{{parent}} ({{../parent/pom.xml}}) and Weld profiles are defined in 
{{parent-code}} ({{../parent/code/pom.xml}}).
Besides {{cdictrl}} defines its own profile named {{Weld}}.

I suppose altering the parent to {{parent-code}} would give access to those 
profiles and then you could extend those profiles by adding adequate 
{{}} subsections?

> Weld(1|2|3) profiles do not activate Weld profile in cdictrl
> 
>
> Key: DELTASPIKE-1175
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1175
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>
> If you run the build with {{mvn clean install -PWeld1 
> -Dweld.version=1.1.28.Final}} you'll see the OWB container control module get 
> built.  It should build the Weld module.  To get it to activate properly you 
> need to do {{mvn clean install -PWeld -PWeld1 -Dweld.version=1.1.28.Final}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release of Apache DeltaSpike 1.7.0

[Matej Novotny]

@struberg, if you are talking about master branch build, than it works for me 
with Weld 1.x (tried 1.1.28 && 1.1.10).

Just tried it with: mvn clean install -PWeld1 -Dweld.version=1.1.28.Final

Matej

- Original Message -
> From: "Mark Struberg" 
> To: "deltaspike" 
> Sent: Wednesday, June 15, 2016 2:52:59 PM
> Subject: Re: [VOTE] Release of Apache DeltaSpike 1.7.0
> 
> Can someone plz check this version with Weld?
> 
> [ERROR]   mvn  -rf :deltaspike-scheduler-module-impl
> 
> Did blow up both with  weld1_1_28 and 1_1_10
> 
> LieGrue,
> strub
> 
> > Am 13.06.2016 um 14:09 schrieb Antoine Sabot-Durand
> > :
> > 
> > +1
> > 
> > Le lun. 13 juin 2016 à 13:21, John D. Ament  a
> > écrit :
> > 
> >> I guess I'll be the first to vote?  Obviously I'm +1 since I ran the
> >> release twice to make sure no issues...
> >> 
> >> John
> >> 
> >> 
> >> On Thu, Jun 9, 2016 at 8:10 PM John D. Ament 
> >> wrote:
> >> 
> >>> All,
> >>> 
> >>> I was running the needed tasks to get the 1.7.0 release of Apache
> >>> DeltaSpike out.
> >>> The artifacts are deployed to Nexus [1], the source release available at
> >>> [2].
> >>> 
> >>> The tag is available at [3] and will get pushed to the ASF repository
> >> once
> >>> the vote passed.
> >>> 
> >>> The release notes can be found at [4].
> >>> 
> >>> Please take a look at the 1.7.0 artifacts and vote!
> >>> 
> >>> Please note:
> >>> This vote is "majority approval" with a minimum of three binding +1 votes
> >>> (see [5]).
> >>> 
> >>> 
> >>> [ ] +1 for community members who have reviewed the bits
> >>> [ ] +0
> >>> [ ] -1 for fatal flaws that should cause these bits not to be released,
> >>> and why..
> >>> 
> >>> 
> >>> Thanks,
> >>> John
> >>> 
> >>> PS - I found a few issues with the release steps, which I will update
> >>> after the release is complete.
> >>> 
> >>> [1]
> >>> 
> >> https://repository.apache.org/content/repositories/orgapachedeltaspike-1038/
> >>> [2]
> >>> 
> >> https://repository.apache.org/content/repositories/orgapachedeltaspike-1038/org/apache/deltaspike/deltaspike/1.7.0/
> >>> [3] https://github.com/johnament/deltaspike/tree/deltaspike-1.7.0
> >>> [4] https://s.apache.org/DeltaSpike-1.7.0
> >>> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >>> 
> >> 
> 
> 

Re: [COMMUNITY] DeltaSpike += Matej Novotny

[Matej Novotny]

Thanks for warm welcoming! :)

Matej

- Original Message -
> From: "Thomas Andraschko" <andraschko.tho...@gmail.com>
> To: dev@deltaspike.apache.org
> Cc: us...@deltaspike.apache.org
> Sent: Friday, June 3, 2016 10:39:54 AM
> Subject: Re: [COMMUNITY] DeltaSpike += Matej Novotny
> 
> Welcome! :)
> 
> 2016-06-03 10:37 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> 
> > Welcome Matej!
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-06-03 10:34 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
> >
> > > The DeltaSpike PMC is proud to announce a new addition to our community.
> > >
> > > Please welcome Matej Novotny as the newest DeltaSpike committer!
> > >
> > > @Matej:
> > > Please add yourself to the developers section (in
> > > deltaspike/parent/pom.xml).
> > >
> > > Welcome & regards,
> > > Gerhard
> > >
> >
> 

[jira] [Resolved] (DELTASPIKE-1141) @Futureable @Locked and @EnableInterceptor cannot work with CDI 1.0/Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1141.
---
   Resolution: Fixed
Fix Version/s: 1.6.2

Resolving issue, Weld [test 
job|https://hudson.jboss.org/hudson/job/DeltaSpike-jbossas-7-daily/] turned 
blue once again.

> @Futureable @Locked and @EnableInterceptor cannot work with CDI 1.0/Weld 1.x
> 
>
> Key: DELTASPIKE-1141
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1141
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.6.1
> Environment: CDI 1.x/Weld 1.x
> EAP 6/JBoss AS 7
>    Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.6.2
>
>
> Follow-up on DELTASPIKE-1138.
> There is still a problem which affects at least two DS features - @Futureable 
> and @Locked.
> Both of them have an interceptor enabled in DS core jar file (via beans.xml). 
> However this will not work with CDI 1.0/Weld 1.x! 
> The reason is the eternal holy war for what exactly is a 'bean archive' :-). 
> Weld will consider the interceptor enabled only for the core jar itself hence 
> it will not kick in.
> How to reproduce:
> * Run DS on JBoss AS 7 (JDK 1.7 or lower) or EAP 6 (all JDKs)
> ** {{mvn clean verify -Pjbossas-build-managed-7 -Dweld.version=1.1.33.Final 
> -Dtest=FutureableTest}}
> * To make the test pass, you can add {{beans.xml}} containing the interceptor 
> [here|https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/test/java/org/apache/deltaspike/test/core/impl/future/FutureableTest.java#L45]
>  (same works for LockedTest)
> ** *The above trick is not a fix though!* Merely a workaround allowing Weld 
> to enable the interceptor within test archive
> ** I think any user aiming to use these features with Weld 1.x would need to 
> use this workaround in his/her deployments which is ugly
> Notes:
> * {{@Priority}} cannot be used here (for CDI 1.0)
> * GlobalInterceptorExtension won't help either as it is working since CDI 1.1+
> * This is not a problem for embedded container (e.g. running via {{-PWeld1}})
> ** This is probably because of different structure of embedded deployments



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Cutting down on jenkins email

[Matej Novotny]

> IMHO we can do a lot to clean up these jobs.  Do we need all of them in
> your opinion? Key weld versions to test with?

That is really your call, although I think it is good to have it properly 
tested if you want to ensure your features work with all those versions.

You might not need every version but it won't hurt to have jobs for at least 
the lowest supported versions (of all branches - 1.x, 2.2, 2.3
, 3.x) and latest releases. Those can run with the new -PWeldX profiles.
Plus keep at least one job per Weld major version for managed containers. This 
will ensure you detect problems such as those I was fixing recently.

Or, if you want to alleviate the load on Jenkins machines, you might only keep 
regular jobs with latest releases and make a "release" job which will trigger 
all version testing.
Whichever works for you, really :)

In any case I would keep more than just latest versions.

Matej

- Original Message -
> From: "John D. Ament" <johndam...@apache.org>
> To: dev@deltaspike.apache.org
> Sent: Friday, May 6, 2016 2:20:35 PM
> Subject: Re: Cutting down on jenkins email
> 
> On Fri, May 6, 2016 at 7:55 AM Matej Novotny <manov...@redhat.com> wrote:
> 
> > Hey there
> >
> > Sorry to spam you guys, totally didn't mean to flood you with email like
> > that[1].
> >
> 
> Not your fault, you fixed the build not broke it.
> 
> 
> >
> > You had all the weld 1.x jobs turned off so I suppose this is the main
> > source of problems.
> > Besides one job sending 50 emails... not a great idea imo.
> >
> >
> > But what I wanted to point out is that you need to review the settings of
> > those jobs.
> > My commits introduced new profiles for Weld (Weld1, Weld2, Weld3). The old
> > '-PWeld' will not trigger a correct build (not sure what will happen).
> > And the first failed job I saw had this misconfigured ->
> > https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%201.1.33/12/consoleFull
> > It was running with '
> > https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%201.1.33/12/consoleFull
> > '
> >
> > So reviewing and correcting the job settings will probably keep the spam
> > at bay :)
> >
> 
> IMHO we can do a lot to clean up these jobs.  Do we need all of them in
> your opinion? Key weld versions to test with?
> 
> 
> >
> > Regards
> > Matej
> >
> > [1] https://dropmyemail.files.wordpress.com/2012/07/9-email.jpg
> >
> > - Original Message -
> > > From: "John D. Ament" <johndam...@apache.org>
> > > To: "deltaspike" <dev@deltaspike.apache.org>
> > > Sent: Friday, May 6, 2016 1:30:13 PM
> > > Subject: Cutting down on jenkins email
> > >
> > > All,
> > >
> > > If you're subscribed to commits@ you'll have seen that there was an
> > influx
> > > of about 700 emails last night.  While its good that Matej's changes
> > fixed
> > > a lot of broken builds, that's a lot of emails to get through.  Right now
> > > our jenkins jobs send email for each failing module.  IMHO it should just
> > > be at a job level (since we have a lot of modules).
> > >
> > > Anyone opposed to only sending an email per job instead of per module?
> > >
> > > John
> > >
> >
> 

Re: Cutting down on jenkins email

[Matej Novotny]

Hey there

Sorry to spam you guys, totally didn't mean to flood you with email like 
that[1].

You had all the weld 1.x jobs turned off so I suppose this is the main source 
of problems.
Besides one job sending 50 emails... not a great idea imo.


But what I wanted to point out is that you need to review the settings of those 
jobs.
My commits introduced new profiles for Weld (Weld1, Weld2, Weld3). The old 
'-PWeld' will not trigger a correct build (not sure what will happen).
And the first failed job I saw had this misconfigured -> 
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%201.1.33/12/consoleFull
It was running with 
'https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20Weld%201.1.33/12/consoleFull'

So reviewing and correcting the job settings will probably keep the spam at bay 
:)

Regards
Matej

[1] https://dropmyemail.files.wordpress.com/2012/07/9-email.jpg

- Original Message -
> From: "John D. Ament" 
> To: "deltaspike" 
> Sent: Friday, May 6, 2016 1:30:13 PM
> Subject: Cutting down on jenkins email
> 
> All,
> 
> If you're subscribed to commits@ you'll have seen that there was an influx
> of about 700 emails last night.  While its good that Matej's changes fixed
> a lot of broken builds, that's a lot of emails to get through.  Right now
> our jenkins jobs send email for each failing module.  IMHO it should just
> be at a job level (since we have a lot of modules).
> 
> Anyone opposed to only sending an email per job instead of per module?
> 
> John
> 

[jira] [Updated] (DELTASPIKE-1141) @Futureable @Locked and @EnableInterceptor cannot work with CDI 1.0/Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny updated DELTASPIKE-1141:
--
Summary: @Futureable @Locked and @EnableInterceptor cannot work with CDI 
1.0/Weld 1.x  (was: @Futureable and @Locked cannot work with CDI 1.0/Weld 1.x)

> @Futureable @Locked and @EnableInterceptor cannot work with CDI 1.0/Weld 1.x
> 
>
> Key: DELTASPIKE-1141
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1141
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.6.1
> Environment: CDI 1.x/Weld 1.x
> EAP 6/JBoss AS 7
>    Reporter: Matej Novotny
>
> Follow-up on DELTASPIKE-1138.
> There is still a problem which affects at least two DS features - @Futureable 
> and @Locked.
> Both of them have an interceptor enabled in DS core jar file (via beans.xml). 
> However this will not work with CDI 1.0/Weld 1.x! 
> The reason is the eternal holy war for what exactly is a 'bean archive' :-). 
> Weld will consider the interceptor enabled only for the core jar itself hence 
> it will not kick in.
> How to reproduce:
> * Run DS on JBoss AS 7 (JDK 1.7 or lower) or EAP 6 (all JDKs)
> ** {{mvn clean verify -Pjbossas-build-managed-7 -Dweld.version=1.1.33.Final 
> -Dtest=FutureableTest}}
> * To make the test pass, you can add {{beans.xml}} containing the interceptor 
> [here|https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/test/java/org/apache/deltaspike/test/core/impl/future/FutureableTest.java#L45]
>  (same works for LockedTest)
> ** *The above trick is not a fix though!* Merely a workaround allowing Weld 
> to enable the interceptor within test archive
> ** I think any user aiming to use these features with Weld 1.x would need to 
> use this workaround in his/her deployments which is ugly
> Notes:
> * {{@Priority}} cannot be used here (for CDI 1.0)
> * GlobalInterceptorExtension won't help either as it is working since CDI 1.1+
> * This is not a problem for embedded container (e.g. running via {{-PWeld1}})
> ** This is probably because of different structure of embedded deployments



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny resolved DELTASPIKE-1137.
---
Resolution: Fixed

Issue was resolved, the tests now do not freeze, however they fail in certain 
setup - see DELTASPIKE-1141.

> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1141) @Futureable and @Locked cannot work with CDI 1.0/Weld 1.x

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1141:
-

 Summary: @Futureable and @Locked cannot work with CDI 1.0/Weld 1.x
 Key: DELTASPIKE-1141
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1141
 Project: DeltaSpike
  Issue Type: Bug
Affects Versions: 1.6.1
 Environment: CDI 1.x/Weld 1.x
EAP 6/JBoss AS 7
Reporter: Matej Novotny


Follow-up on DELTASPIKE-1138.
There is still a problem which affects at least two DS features - @Futureable 
and @Locked.
Both of them have an interceptor enabled in DS core jar file (via beans.xml). 
However this will not work with CDI 1.0/Weld 1.x! 

The reason is the eternal holy war for what exactly is a 'bean archive' :-). 
Weld will consider the interceptor enabled only for the core jar itself hence 
it will not kick in.

How to reproduce:
* Run DS on JBoss AS 7 (JDK 1.7 or lower) or EAP 6 (all JDKs)
** {{mvn clean verify -Pjbossas-build-managed-7 -Dweld.version=1.1.33.Final 
-Dtest=FutureableTest}}
* To make the test pass, you can add {{beans.xml}} containing the interceptor 
[here|https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/test/java/org/apache/deltaspike/test/core/impl/future/FutureableTest.java#L45]
 (same works for LockedTest)
** *The above trick is not a fix though!* Merely a workaround allowing Weld to 
enable the interceptor within test archive
** I think any user aiming to use these features with Weld 1.x would need to 
use this workaround in his/her deployments which is ugly

Notes:
* {{@Priority}} cannot be used here (for CDI 1.0)
* GlobalInterceptorExtension won't help either as it is working since CDI 1.1+
* This is not a problem for embedded container (e.g. running via {{-PWeld1}})
** This is probably because of different structure of embedded deployments



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1138) FutureableTest not compatible with weld v1.x

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1138:
---

I do not have the rights to re-open this issue, though we are not yet done with 
this one. There is still a problem which affects at least two DS features - 
@Futureable and @Locked.
Both of them have an interceptor enabled in DS core jar file (via beans.xml). 
However this will not work with CDI 1.0/Weld 1.x! 
The reason is the eternal holy war for what exactly is a 'bean archive' :-). 
Weld will consider the interceptor enabled only for the core jar itself hence 
it will not kick in.

How to reproduce:
* Run DS on JBoss AS 7 (JDK 1.7 or lower) or EAP 6 (all JDKs)
** {{mvn clean verify -Pjbossas-build-managed-7 -Dweld.version=1.1.33.Final 
-Dtest=FutureableTest}}
* To make the test pass, you can add {{beans.xml}} containing the interceptor 
[here|https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/test/java/org/apache/deltaspike/test/core/impl/future/FutureableTest.java#L45]
 (same work for LockedTest)
** *The above trick is not a fix though!* Merely a workaround allowing Weld to 
enable the interceptor within test archive
** I think any user aiming to use these features with Weld 1.x would need to 
use this workaround in his/her deployments which is ugly

Notes:
* {{@Priority}} cannot be used here (for CDI 1.0)
* GlobalInterceptorExtension won't help either as it is working since CDI 1.1+
* This is not a problem for embedded container (e.g. running via {{-PWeld1}})
** This is probably because of different structure of embedded deployments

> FutureableTest not compatible with weld v1.x
> 
>
> Key: DELTASPIKE-1138
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1138
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
>Reporter: Gerhard Petracek
>Assignee: Romain Manni-Bucau
> Fix For: 1.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1137:
---

For the record, the cause of the freeze is likely the following test - 
{{org.apache.deltaspike.test.core.impl.futureFutureableTest}} 
([link|https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/test/java/org/apache/deltaspike/test/core/impl/future/FutureableTest.java]).
It is now tracked in a separate JIRA - DELTASPIKE-1138 -> linking issues.

> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1091:
---

[~gpetracek] I created a PR for this - 
https://github.com/apache/deltaspike/pull/47
A more in-depth explanation of my solution can be found in the PR comment.

BTW at first I accidentaly created the PR as "DELTAPIKE-1137", hence your bot 
didnt link it here. I already edited that.

Comments to the PR are welcome :)

> Weld core BOM update in next 2.3/3.x release
> 
>
> Key: DELTASPIKE-1091
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1091
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Reporter: Matej Novotny
>Assignee: Rafael Benevides
>
> The next release of Weld 2.3 (2.3.4.Final) and 3.x (3.0.Alpha16) will also 
> contain a refactored weld-core BOM files.
> This is per request in [WELD-2115|https://issues.jboss.org/browse/WELD-2115].
> BOM will no longer provide direct dependencies, but only 
> {{dependencyManagement}} section. Looking at deltaspike dependencies, this 
> will affect 
> [{{parent/code/pom.xml}}|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L355]
>  and will require changes.
> The PRs for BOM changes are:
> * 2.3 branch -> https://github.com/weld/core/pull/1295
> * master -> https://github.com/weld/core/pull/1296



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1137:
---

Ignore the above PR please, it is for DELTASPIKE-1091, but I typed in wrong 
issue number - already corrected that...

> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[Matej Novotny (JIRA)]

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

Matej Novotny updated DELTASPIKE-1137:
--
Description: 
According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.

NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.

  was:
According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.


> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1137:
-

 Summary: core/impl test suite freezes in embedded container with 
Weld 1.x
 Key: DELTASPIKE-1137
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
 Project: DeltaSpike
  Issue Type: Bug
  Components: Tests
Affects Versions: 1.6.1
 Environment: Embedded container
Weld 1.x
Reporter: Matej Novotny


According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1091:
---

We have just incorporated this change into master and 2.3 branches.
ATM we are working on the 2.3.4.release and 3.0.0.Alpha16 will follow shortly 
afterwards (within 2 weeks).

Obviously, DS test suite now fails with {{ClassNotFound}} as the dependencies 
do not get pulled in.
You can try that yourself, if you build Weld from [2.3.4.Final 
tag|https://github.com/weld/core/tree/2.3.4.Final] and then run your test suit 
with {{mvn clean verify -PWeld -Dweld.version=2.3.4.Final}}.

DS needs to adjust to this. The simplest way would probably be to introduce 
profiles for different Weld versions?

> Weld core BOM update in next 2.3/3.x release
> 
>
> Key: DELTASPIKE-1091
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1091
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>    Reporter: Matej Novotny
>Assignee: Rafael Benevides
>
> The next release of Weld 2.3 (2.3.4.Final) and 3.x (3.0.Alpha16) will also 
> contain a refactored weld-core BOM files.
> This is per request in [WELD-2115|https://issues.jboss.org/browse/WELD-2115].
> BOM will no longer provide direct dependencies, but only 
> {{dependencyManagement}} section. Looking at deltaspike dependencies, this 
> will affect 
> [{{parent/code/pom.xml}}|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L355]
>  and will require changes.
> The PRs for BOM changes are:
> * 2.3 branch -> https://github.com/weld/core/pull/1295
> * master -> https://github.com/weld/core/pull/1296



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1108) Tests in 'deltaspike-data-module-test-ee7' fail with Weld and should be ignored

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1108:
-

 Summary: Tests in 'deltaspike-data-module-test-ee7' fail with Weld 
and should be ignored
 Key: DELTASPIKE-1108
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1108
 Project: DeltaSpike
  Issue Type: Bug
  Components: Tests
Affects Versions: 1.5.4
 Environment: Weld 2.x / Weld 3.x
Wildfly 10.0.0.Final (has Weld 2.3.3.Final)
Reporter: Matej Novotny
Priority: Minor


Running the tests under _deltaspike/modules/data/test-ee7_ will lead to 12 
errors.
The exception and the reason of failure behind that is the same as was 
discussed in DELTASPIKE-1060 (see the issue for more info).

Since DELTASPIKE-1060 was not resolved, I believe these tests should be ignored.

The list of failing tests:
* 
should_run_modifying_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryInterfaceTest)
* 
should_save_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryInterfaceTest)
* 
should_find_with_lockmode_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryInterfaceTest)
* 
should_find_no_lock_without_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryInterfaceTest)
* 
should_cleanup(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryInterfaceTest)
* 
should_run_modifying_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_save_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_find_with_lockmode_in_transaction(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_save_when_tx_scoped_bean_is_found(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_save_when_app_scoped_bean_is_found(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_save_when_dep_scoped_bean_is_found(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)
* 
should_cleanup(org.apache.deltaspike.data.test.ee7.tx.JtaTransactionalRepositoryAbstractTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1031) Update profiles for Wildfly

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1031:
---

PR can be found at -> https://github.com/apache/deltaspike/pull/46

> Update profiles for Wildfly
> ---
>
> Key: DELTASPIKE-1031
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1031
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Configuration, Tests
>Affects Versions: 1.5.1
>    Reporter: Matej Novotny
>
> Taking a closer look at how test structure looks like, I saw that running 
> tests against Wildfly:
> {{mvn clean verify -Pwildfly-managed}}
> will launch Arquillian profile named {{jbossas-managed-7}}.
> Similar situation is with remote profile (and maybe other tiny bits).
> This naming seems inappropriate and highly confusing when (for instance) you 
> need to temper with Arq. settings in order to debug code.
> I would suggest adding separate profiles to {{arquillian-jboss.xml}}.
> Apart from this, what do you think about updating the default WFLY from 8 to 
> 9 (or even 10, there is CR4 already)?
> Will send a PR with these tiny changes soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1031) Update profiles for Wildfly

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1031:
-

 Summary: Update profiles for Wildfly
 Key: DELTASPIKE-1031
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1031
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration, Tests
Affects Versions: 1.5.1
Reporter: Matej Novotny


Taking a closer look at how test structure looks like, I saw that running tests 
against Wildfly:
{{mvn clean verify -Pwildfly-managed}}
will launch Arquillian profile named {{jbossas-managed-7}}.
Similar situation is with remote profile (and maybe other tiny bits).

This naming seems inappropriate and highly confusing when (for instance) you 
need to temper with Arq. settings in order to debug code.

I would suggest adding separate profiles to {{arquillian-jboss.xml}}.

Apart from this, what do you think about updating the default WFLY from 8 to 9 
(or even 10, there is CR4 already)?

Will send a PR with these tiny changes soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1010) Test failures with IBM Java

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1010:
---

They dont. I tried {{mvn clean install}} and it passed.

> Test failures with IBM Java
> ---
>
> Key: DELTASPIKE-1010
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1010
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: IBM Java 1.8
> Weld 2.3.0.Final
> Wildfly 9/10 (latest)
>Reporter: Matej Novotny
>Assignee: Romain Manni-Bucau
> Fix For: 1.6.0
>
> Attachments: DELTASPIKE-1010.patch
>
>
> Hello,
> I came across a problem when running a test suite with Weld 2.3.0.Final, 
> Wildfly 9/10 and with IBM java 1.8.
> The errors come from Core-Implementation module.
> Here is an exception from one of the tests (SimpleRegistrationWarFileTest):
> {code}
> java.lang.ClassCastException: 
> org.apache.deltaspike.core.impl.jmx.MBeanExtension incompatible with 
> org.apache.deltaspike.core.api.jmx.JmxBroadcaster
>   at 
> org.apache.deltaspike.core.impl.jmx.MBeanExtension$Proxy$_$$_WeldClientProxy.getBroadcasterFor(Unknown
>  Source)
>   at 
> org.apache.deltaspike.core.impl.jmx.BroadcasterProducer.jmxBroadcaster(BroadcasterProducer.java:41)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
>   at 
> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
>   at 
> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
>   at 
> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
>   at 
> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
>   at 
> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
>   at 
> org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
>   at 
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
>   at 
> org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
>   at 
> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
>   at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
>   at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
>   at 
> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
>   at 
> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
>   at 
> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
>   at 
> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
>   at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
>   at 
> org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
>   at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
>   at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   at 
> org.apache.deltaspike.test.core.impl.jmx.MyMBean$Proxy$_$$_WeldClientProxy.getCounter(Unknown
>  Source)
>   at 
> org.apache.deltaspike.test.core.impl.jmx.SimpleRegistrationTest.checkMBean(SimpleRegistrationTest.java:40)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA

[jira] [Created] (DELTASPIKE-1010) Test failures with IBM Java

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1010:
-

 Summary: Test failures with IBM Java
 Key: DELTASPIKE-1010
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1010
 Project: DeltaSpike
  Issue Type: Bug
Affects Versions: 1.5.0
 Environment: IBM Java 1.8
Weld 2.3.0.Final
Wildfly 9/10 (latest)
Reporter: Matej Novotny


Hello,

I came across a problem when running a test suite with Weld 2.3.0.Final, 
Wildfly 9/10 and with IBM java 1.8.

The errors come from Core-Implementation module.
Here is an exception from one of the tests (SimpleRegistrationWarFileTest):
{code}
java.lang.ClassCastException: 
org.apache.deltaspike.core.impl.jmx.MBeanExtension incompatible with 
org.apache.deltaspike.core.api.jmx.JmxBroadcaster
at 
org.apache.deltaspike.core.impl.jmx.MBeanExtension$Proxy$_$$_WeldClientProxy.getBroadcasterFor(Unknown
 Source)
at 
org.apache.deltaspike.core.impl.jmx.BroadcasterProducer.jmxBroadcaster(BroadcasterProducer.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at 
org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
at 
org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
at 
org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
at 
org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
at 
org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
at 
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
at 
org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at 
org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at 
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
at 
org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
at 
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
at 
org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
at 
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at 
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
at 
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at 
org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at 
org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
at 
org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
at 
org.apache.deltaspike.test.core.impl.jmx.MyMBean$Proxy$_$$_WeldClientProxy.getCounter(Unknown
 Source)
at 
org.apache.deltaspike.test.core.impl.jmx.SimpleRegistrationTest.checkMBean(SimpleRegistrationTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
at 
org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95

[jira] [Commented] (DELTASPIKE-1010) Test failures with IBM Java

[Matej Novotny (JIRA)]

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

Matej Novotny commented on DELTASPIKE-1010:
---

Hi [~gpetracek]! Thanks for quick response.
The patch only solves the problem for that one particular test I listed as an 
example (or in fact its -2 errors in the test run). There are many other errors 
when executing with this setup. Here is a summary of such test run for 
core-impl module:
{code}
<-- clipped -->
Results :

Failed tests:   
testInjectConfig(org.apache.deltaspike.test.core.api.config.propertyconfigsource.ConfigPropertyWARTest):
 expected: but was:
  
testInjectConfig(org.apache.deltaspike.test.core.api.config.propertyconfigsource.ConfigPropertyEARTest):
 expected: but was:

Tests in error: 
  
testTraversalPathOrder(org.apache.deltaspike.test.core.impl.exception.control.traversal.TraversalPathTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertNoOtherHandlersCalledAfterAbort(org.apache.deltaspike.test.core.impl.exception.control.flow.DepthAbortControlTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOrderIsCorrectDepthFirst(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOrderIsCorrectWithQualifiers(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOrderIsCorrectBreadthFirst(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOutboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.RethrowTest):
 Unexpected exception, expected but 
was
  
assertInboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.RethrowTest):
 Unexpected exception, expected but 
was
  
assertOutboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.ThrowingNewExceptionTest):
 Unexpected exception, expected but 
was
  
assertInboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.ThrowingNewExceptionTest):
 Unexpected exception, expected but 
was
  
assertNoHandlersAfterHandledAreCalled(org.apache.deltaspike.test.core.impl.exception.control.flow.HandledExceptionHandlerTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertNoHandlersAfterHandledAreCalledDesc(org.apache.deltaspike.test.core.impl.exception.control.flow.HandledExceptionHandlerTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertCorrectNumberOfHandlerCallsForProceedCause(org.apache.deltaspike.test.core.impl.exception.control.flow.ProceedCauseHandlerTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertNoOtherHandlersCalledAfterAbort(org.apache.deltaspike.test.core.impl.exception.control.flow.BreadthFirstAbortControlTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOutboundHanldersAreCalled(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertOutboundHanldersAreCalledOnce(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertInboundHanldersAreCalledOnce(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertAdditionalParamsAreInjected(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
assertProtectedHandlersAreCalled(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl 
incompatible with java.util.Collection
  
testMinimalMessage(org.apache.deltaspike.test.core.api.message.MinimalMessagesTest):
 com.sun.proxy.$Proxy129 incompatible with java.lang.