[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=16607059#comment-16607059
]
Matej Novotny commented on DELTASPIKE-1318:
---
It should be injectable, according to
[docs|http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_managing_the_built_in_contexts]
it is _unmanaged_ and _unbound_ context.
Can you try injecting {{ApplicationContext}} somewhere else in your app without
using DS? Having the result of that we could see if the problem is in your
app(or paraya/osgi) or in DS.
Alternatively, if you can provide a reproducer?
> Unsatisfied dependencies for type ApplicationContext
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Assignee: Matej Novotny
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>
> Maven dependencies
> {code:java}
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
>
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
>
> {code}
> Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
> @Inject
> private ContextControl contextControl;
> ...
> }{code}
> payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026]
> [javax.enterprise.system.core] [tid: _ThreadID=47
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713]
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
>
[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=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=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)
[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)
[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)
[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=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)
[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=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=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=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)
[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=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] [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] [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] [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=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=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)
[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)
[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] [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=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=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=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=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] [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=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] [Commented] (DELTASPIKE-1031) Update profiles for Wildfly
[
https://issues.apache.org/jira/browse/DELTASPIKE-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15016712#comment-15016712
]
Matej Novotny commented on DELTASPIKE-1031:
---
PR can be found at -> https://github.com/apache/deltaspike/pull/46
> Update profiles for Wildfly
> ---
>
> Key: DELTASPIKE-1031
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1031
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration, Tests
>Affects Versions: 1.5.1
>Reporter: Matej Novotny
>
> Taking a closer look at how test structure looks like, I saw that running
> tests against Wildfly:
> {{mvn clean verify -Pwildfly-managed}}
> will launch Arquillian profile named {{jbossas-managed-7}}.
> Similar situation is with remote profile (and maybe other tiny bits).
> This naming seems inappropriate and highly confusing when (for instance) you
> need to temper with Arq. settings in order to debug code.
> I would suggest adding separate profiles to {{arquillian-jboss.xml}}.
> Apart from this, what do you think about updating the default WFLY from 8 to
> 9 (or even 10, there is CR4 already)?
> Will send a PR with these tiny changes soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1031) Update profiles for Wildfly
Matej Novotny 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=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(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
>
[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
[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=14971120#comment-14971120
]
Matej Novotny commented on DELTASPIKE-1010:
---
Hi [~gpetracek]! Thanks for quick response.
The patch only solves the problem for that one particular test I listed as an
example (or in fact its -2 errors in the test run). There are many other errors
when executing with this setup. Here is a summary of such test run for
core-impl module:
{code}
<-- clipped -->
Results :
Failed tests:
testInjectConfig(org.apache.deltaspike.test.core.api.config.propertyconfigsource.ConfigPropertyWARTest):
expected: but was:
testInjectConfig(org.apache.deltaspike.test.core.api.config.propertyconfigsource.ConfigPropertyEARTest):
expected: but was:
Tests in error:
testTraversalPathOrder(org.apache.deltaspike.test.core.impl.exception.control.traversal.TraversalPathTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertNoOtherHandlersCalledAfterAbort(org.apache.deltaspike.test.core.impl.exception.control.flow.DepthAbortControlTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOrderIsCorrectDepthFirst(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOrderIsCorrectWithQualifiers(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOrderIsCorrectBreadthFirst(org.apache.deltaspike.test.core.impl.exception.control.handler.HandlerComparatorTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOutboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.RethrowTest):
Unexpected exception, expected but
was
assertInboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.RethrowTest):
Unexpected exception, expected but
was
assertOutboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.ThrowingNewExceptionTest):
Unexpected exception, expected but
was
assertInboundRethrow(org.apache.deltaspike.test.core.impl.exception.control.flow.ThrowingNewExceptionTest):
Unexpected exception, expected but
was
assertNoHandlersAfterHandledAreCalled(org.apache.deltaspike.test.core.impl.exception.control.flow.HandledExceptionHandlerTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertNoHandlersAfterHandledAreCalledDesc(org.apache.deltaspike.test.core.impl.exception.control.flow.HandledExceptionHandlerTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertCorrectNumberOfHandlerCallsForProceedCause(org.apache.deltaspike.test.core.impl.exception.control.flow.ProceedCauseHandlerTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertNoOtherHandlersCalledAfterAbort(org.apache.deltaspike.test.core.impl.exception.control.flow.BreadthFirstAbortControlTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOutboundHanldersAreCalled(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertOutboundHanldersAreCalledOnce(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertInboundHanldersAreCalledOnce(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertAdditionalParamsAreInjected(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
assertProtectedHandlersAreCalled(org.apache.deltaspike.test.core.impl.exception.control.handler.CallingHandlersTest):
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageImpl
incompatible with java.util.Collection
testMinimalMessage(org.apache.deltaspike.test.core.api.message.MinimalMessagesTest):
com.sun.proxy.$Proxy129 incompatible with java.lang.String
