Weld 3.1.5.Final is now released
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
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
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.1.Final is now live
Hello, new maintenance release of Weld is now available - Weld 3.1.1.Final. Take a look at release notes for more details - http://weld.cdi-spec.org/news/2019/05/07/weld-311Final/ Regards Matej
Weld 3.1.0.Final released
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
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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
[jira] [Commented] (DELTASPIKE-1338) support class-filter per test
[ https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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
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
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
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?
lso 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 > > >: > > > > > > > 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" > > > > > > 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 > > >: > > > > > > > > > > > Sorry Matej, I don't get how Travis would help since you can do the > > > > > > same with jenkins which is already configured. > > > > > > > > > > > > Having the default build running on both weld and OWB would be more > > > > > > beneficial IMHO, but it is just the opinion from my side of the > > fence > > > > > > and experience. > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > > > > > > > > > > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny > > >: > > > > > > > Thanks, but it was more of a rhetorical question (you saved me > > some > > > > > > digging though). > > > > > > > Still my claim holds true, nobody cares about them much. They > > must > > > > have > > > > > > been failing for quite some time now > > > > > > > Not to mention they aren't even updated to latest Weld version > > (or > > > > > > WildFly version for that matter). > > > > > > > > > > > > > > > > > > > > > Matej > > > > > > > > > > > > >
[jira] [Reopened] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
[ 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?
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" > 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 : > > > Sorry Matej, I don't get how Travis would help since you can do the > > same with jenkins which is already configured. > > > > Having the default build running on both weld and OWB would be more > > beneficial IMHO, but it is just the opinion from my side of the fence > > and experience. > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny : > > > Thanks, but it was more of a rhetorical question (you saved me some > > digging though). > > > Still my claim holds true, nobody cares about them much. They must have > > been failing for quite some time now > > > Not to mention they aren't even updated to latest Weld version (or > > WildFly version for that matter). > > > > > > > > > Matej > > > > > > - Original Message - > > >> From: "Romain Manni-Bucau" > > >> To: dev@deltaspike.apache.org > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM > > >> Subject: Re: CI for DeltaSpike? > > >> > > >> Hi Matej, > > >> > > >> they are all on the ASF jenkins: > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/ > > >> > > >> Romain Manni-Bucau > > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn > > >> > > >> > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny : > > >> > Hello > > >> > > > >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I > > meant > > >> > Integration OFC) and DeltaSpike. > > >> > Apparently, there is no such thing now and even while some CI jobs > > exist > > >> > (where are they, anyway?), nobody really pays attention to them. > > >> > I mean those for Weld ones must have been failing for few months and > > yet > > >> > the JIRAs causing that were happily marked as Resolved. > > >> > Meaning whoever fixed that probably only ran smoke tests with OWB. > > >> > > > >> > Today I noticed there is going to be a release soon and so I quikly > > went to > > >> > check how the build/tests fare with Weld profiles. > > >> > Turned out to be a disaster. So I then have to spend considerable time > > >> > backtracking the changes and figuring out the actual problem. > > >> > And it's not the first time this happened either. > > >> > > > >> > Therefore I wanted to bring up the topic of CI to avoid this in the > > future. > > >> > The ideal scenario is sending PRs and having them checked *before* > > merging > > >> > - obviously not an option here. > > >> > The GH repo is but a mirror (something we have to stick to I presume) > > which > > >> > makes it more complex, but still, it should be possible to set up a > > Travis > > >> > build on GH master which will execute after every sync. > > >> > That way the failures would be readily visible (via the travis status > > >> > "button"). > > >> > In order to discover most problems there is no need for a complete > > test > > >> > matrix, it would do to just have two version of OWB and Weld without > > EE > > >> > container (with just the Arq. one). > > >> > > > >> > > > >> > A penny for your thoughts? > > >> > > > >> > > > >> > Regards > > >> > Matej > > >> > > >
[jira] [Reopened] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE
[ 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?
Thanks, but it was more of a rhetorical question (you saved me some digging though). Still my claim holds true, nobody cares about them much. They must have been failing for quite some time now Not to mention they aren't even updated to latest Weld version (or WildFly version for that matter). Matej - Original Message - > From: "Romain Manni-Bucau" > To: dev@deltaspike.apache.org > Sent: Wednesday, November 29, 2017 5:03:02 PM > Subject: Re: CI for DeltaSpike? > > Hi Matej, > > they are all on the ASF jenkins: > https://builds.apache.org/view/A-D/view/DeltaSpike/ > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > 2017-11-29 16:47 GMT+01:00 Matej Novotny : > > Hello > > > > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant > > Integration OFC) and DeltaSpike. > > Apparently, there is no such thing now and even while some CI jobs exist > > (where are they, anyway?), nobody really pays attention to them. > > I mean those for Weld ones must have been failing for few months and yet > > the JIRAs causing that were happily marked as Resolved. > > Meaning whoever fixed that probably only ran smoke tests with OWB. > > > > Today I noticed there is going to be a release soon and so I quikly went to > > check how the build/tests fare with Weld profiles. > > Turned out to be a disaster. So I then have to spend considerable time > > backtracking the changes and figuring out the actual problem. > > And it's not the first time this happened either. > > > > Therefore I wanted to bring up the topic of CI to avoid this in the future. > > The ideal scenario is sending PRs and having them checked *before* merging > > - obviously not an option here. > > The GH repo is but a mirror (something we have to stick to I presume) which > > makes it more complex, but still, it should be possible to set up a Travis > > build on GH master which will execute after every sync. > > That way the failures would be readily visible (via the travis status > > "button"). > > In order to discover most problems there is no need for a complete test > > matrix, it would do to just have two version of OWB and Weld without EE > > container (with just the Arq. one). > > > > > > A penny for your thoughts? > > > > > > Regards > > Matej >
[jira] [Resolved] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ 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?
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?
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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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
Yep, my bad. It should indeed be "will now implement" :) Matej - Original Message - > From: "arjan tijms" > To: "Matej Novotny" > Cc: "Weld" , 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 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
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!
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
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" > To: "deltaspike" > 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 : > > > > 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 > >> > >
Re: jbossas 7.1.1.Final build
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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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)
[jira] [Created] (DELTASPIKE-1232) Weld 3.0.0.CR1 package changes causing build failures
Matej Novotny created DELTASPIKE-1232: - Summary: 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 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?
You just CANNOT compile DS with Java 6 and CDI 2.0 on classpath. You'll get errors like this: [ERROR] deltaspike/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/view/navigation/NavigationParameter.java:[24,-1] cannot access javax.enterprise.util.Nonbinding [ERROR] bad class file: javax/enterprise/util/Nonbinding.class(javax/enterprise/util:Nonbinding.class) [ERROR] class file has wrong version 52.0, should be 50.0 And Weld depends on CDI (suprisingly) and therefore brings in this version. Both, CDI 2.0 and Weld 3 require Java 8. So as long as you use Weld3 (from Beta1 version above) profile in DS, it will blow up. If you are suggesting to separate compilation (against prehistoric CDI version) and then run tests against different, then I am about -50 for that. It's a nasty workaround and a nice way to bloat POMs. Not to mention there might be other hindrances especially in Weld-only modules (where you will need that CDI 2.0) like Weld container control. In such case^, I will rather run our jobs with `-Djava.version=1.8` (effectively setting source and target to Java 8) and be done with it. Matej - Original Message - > From: "Romain Manni-Bucau" > To: dev@deltaspike.apache.org > Cc: "Martin Kouba" > Sent: Tuesday, December 20, 2016 10:44:11 AM > Subject: Re: DS and CDI 2.0? > > 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 10:26 GMT+01:00 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. > > > > > this way, adding a variable for source and target and > -Djava.compilation.version=xxx > > Or simply compiling with java 6 and running with java 8 tests - this > supposes weld is able to handle it but if not compatibility is broken which > is not an option for an EE spec. > > > > Matej > > > > - Original Message - > > > From: "Romain Manni-Bucau" > > > To: dev@deltaspike.apache.org > > > Cc: "Martin Kouba" > > > 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 : > > > > > > > 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 > > > > > > > > > >
Re: DS and CDI 2.0?
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" > To: dev@deltaspike.apache.org > Cc: "Martin Kouba" > 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 : > > > 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?
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
Re: [jira] [Resolved] (DELTASPIKE-1215) Java8Test failing with EAP 6.4
No, there is no need to push this into current release. I guess I just wasn't paying much attention to mailing list and so I missed the vote in progress. I just found this minor issue and thought I will fix it right away. Feel free to postpone this fix for later version and sorry if it caused trouble/confusion :-/ Matej - Original Message - > From: "John D. Ament" > To: dev@deltaspike.apache.org > Sent: Wednesday, November 2, 2016 1:48:12 PM > Subject: Re: [jira] [Resolved] (DELTASPIKE-1215) Java8Test failing with EAP > 6.4 > > Matej, > > Did you want me to cancel the vote and reroll to include this fix? > > John > > On Wed, Nov 2, 2016 at 8:23 AM Matej Novotny (JIRA) wrote: > > > > > [ > > 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] [Resolved] (DELTASPIKE-1215) Java8Test failing with EAP 6.4
[ 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 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
[ 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] [Created] (DELTASPIKE-1204) Wildfly managed profiles blow up
Matej Novotny created DELTASPIKE-1204: - Summary: 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 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.
[ 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.
[ 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] [Assigned] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.
[ https://issues.apache.org/jira/browse/DELTASPIKE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reassigned DELTASPIKE-1199: - Assignee: Matej Novotny > 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] [Commented] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.
[ https://issues.apache.org/jira/browse/DELTASPIKE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
@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
Thanks for warm welcoming! :) Matej - Original Message - > From: "Thomas Andraschko" > 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 : > > > 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 : > > > > > 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
[ 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
> 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" > 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 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" > > > 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 > > > > > >
Re: Cutting down on jenkins email
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
[ 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] [Commented] (DELTASPIKE-1141) @Futureable and @Locked cannot work with CDI 1.0/Weld 1.x
[ https://issues.apache.org/jira/browse/DELTASPIKE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270590#comment-15270590 ] Matej Novotny commented on DELTASPIKE-1141: --- So to sum this up: * it is considered to be common practice for weld 1 users to add interceptors to their beans.xml in order to enable certain DS features * same principle applies to these two features discussed here * hence this is not a bug and a solution is therefore to simply fix the tests by adding the relevant beans.xml Will send a PR shortly. > @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] [Resolved] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x
[ 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 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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] [Comment Edited] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release
[ https://issues.apache.org/jira/browse/DELTASPIKE-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249623#comment-15249623 ] Matej Novotny edited comment on DELTASPIKE-1091 at 4/20/16 10:41 AM: - [~rafabene], 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? was (Author: manovotn): 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] [Commented] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release
[ https://issues.apache.org/jira/browse/DELTASPIKE-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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] [Created] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release
Matej Novotny created DELTASPIKE-1091: - Summary: 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 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-1031) Update profiles for Wildfly
[ https://issues.apache.org/jira/browse/DELTASPIKE-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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(DelegatingMet
[jira] [Commented] (DELTASPIKE-1010) Test failures with IBM Java
[ https://issues.apache.org/jira/browse/DELTASPIKE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.l
[jira] [Created] (DELTASPIKE-1010) Test failures with IBM Java
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) at