[JBoss JIRA] (WFLY-7915) CCME in WildFlyJobXmlResolver
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7915?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-7915:
---------------------------------
Assignee: James Perkins (was: Cheng Fang)
> CCME in WildFlyJobXmlResolver
> -----------------------------
>
> Key: WFLY-7915
> URL: https://issues.jboss.org/browse/WFLY-7915
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Tomaz Cerar
> Assignee: James Perkins
>
> When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
> Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
> {code}
> Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110)
> at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> {code}
> see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7915) CCME in WildFlyJobXmlResolver
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7915?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-7915:
------------------------------
Description:
When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
{code}
Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110)
at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
{code}
see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
was:
When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
{noformat}
Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110) at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
{noformat}
see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
> CCME in WildFlyJobXmlResolver
> -----------------------------
>
> Key: WFLY-7915
> URL: https://issues.jboss.org/browse/WFLY-7915
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Tomaz Cerar
> Assignee: Cheng Fang
>
> When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
> Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
> {code}
> Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231)
> at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110)
> at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> {code}
> see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7915) CCME in WildFlyJobXmlResolver
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-7915:
---------------------------------
Summary: CCME in WildFlyJobXmlResolver
Key: WFLY-7915
URL: https://issues.jboss.org/browse/WFLY-7915
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: Tomaz Cerar
Assignee: Cheng Fang
When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
{noformat}
Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231) at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110) at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
{noformat}
see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7913) Rename default-realm attribute in Elytron properties-realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7913?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7913:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Rename default-realm attribute in Elytron properties-realm
> ----------------------------------------------------------
>
> Key: WFLY-7913
> URL: https://issues.jboss.org/browse/WFLY-7913
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> The newly introduced attribute {{default-realm}} in {{properties-realm}} configuration in Elytron is ambiguous and should be renamed. The attribute contains default value for realm-name and it's used in password hash computation. So it's rather related to {{users-properties}} part only.
> *Suggestion for improvement:*
> Rename the attribute to sth. like {{realm-name-to-hash}} and put it into {{users-properties}} configuration if possible.
> {code:xml}
> <properties-realm name="ApplicationRealm">
> <users-properties path="application-users.properties" relative-to="jboss.server.config.dir" realm-name-to-hash="ApplicationRealm"/>
> <groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> {code}
> or (if it's not easy to have it in users-properties configuration)
> {code:xml}
> <properties-realm name="ApplicationRealm" realm-name-to-hash="ApplicationRealm">
> <users-properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
> <groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-691) Elytron properties-realm is not compatible with legacy user property files
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-691:
---------------------------
Fix Version/s: 1.1.0.Beta12
> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
> Key: ELY-691
> URL: https://issues.jboss.org/browse/ELY-691
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta12
>
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password // results to username elytron with password password
> elytronumlautöäü=password // results to username elytronumlautöäü with password password
> elytron用戶=password // results to username elytron用戶 with password password
> backslash\\=password // results to username backslash\ with password password
> backslash\\inthemiddle=password // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\ // results to username elytron2 with password password\
> elytron3=pass\\word // results to username elytron3 with password pass\word
> elytron4=passwordWithumlautöäü // results to username elytron4 with password passwordWithumlautöäü
> elytron5=用戶 // results to username elytron5 with password 用戶
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7914) injection of sub-sub-EJB fails with proxy
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/WFLY-7914?page=com.atlassian.jira.plugin.... ]
Tom Eicher updated WFLY-7914:
-----------------------------
Description:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs (below an {{abstract}} class) are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
public class WeldProcessortInjectionProblemTest {
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
System.out.println(a);
}
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
was:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs (below an {{abstract}} class) are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
System.out.println(a);
}
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
> injection of sub-sub-EJB fails with proxy
> -----------------------------------------
>
> Key: WFLY-7914
> URL: https://issues.jboss.org/browse/WFLY-7914
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> wildfly-arquillian-2.0.2.Final
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: Tom Eicher
> Assignee: Jason Greene
>
> When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs (below an {{abstract}} class) are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
> In more Detail:
> {code}
> public interface A extends Serializable {}
> ...
> @Stateless
> public class A1 implements A {
> public A1() {
> }
> }
> ...
> public interface B extends A {}
> ...
> @Stateless
> public class B1 implements B {
> public B1() {
> }
> }
> ...
> public abstract class C implements A { }
> ...
> @Stateless
> public class C1 extends C {
> public C1() {
> }
> }
> ...
> @Stateless
> public class C2 extends C implements A {
> public C2() {
> }
> }
> ...
> public class WeldProcessortInjectionProblemTest {
>
> @Inject @Any Instance<A> testinstances;
> @Test
> public void testSubclassInjection() {
> boolean foundC1=false, foundC2=false;
> for (A a : testinstances) {
> System.out.println(a);
> }
> }
> }
> ...
> Proxy for view class: com.ehtwo.core.util.A of EJB: C2
> Proxy for view class: com.ehtwo.core.util.A of EJB: A1
> Proxy for view class: com.ehtwo.core.util.B of EJB: B1
> {code}
> so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
> this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
> please move/copy issue to Wildfly-Core or Weld or as you see fit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1411) OOPath constraint bugs emerged during dogfooding
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1411?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1411:
----------------------------------------
Missing test class:
{code:java}
package org.drools.compiler.xpath;
public class TMFileWithParentObj extends TMFile {
private long id;
private Object parent;
public TMFileWithParentObj(long id, String name, int size, Object parent) {
super(name, size);
this.id = id;
this.parent = parent;
}
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public Object getParent() {
return parent;
}
public void setParent(Object parent) {
this.parent = parent;
}
}
{code}
> OOPath constraint bugs emerged during dogfooding
> ------------------------------------------------
>
> Key: DROOLS-1411
> URL: https://issues.jboss.org/browse/DROOLS-1411
> Project: Drools
> Issue Type: Bug
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> Misc OOPath constraint bugs emerged during dogfooding using in DMN Validation rules
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7914) injection of sub-sub-EJB fails with proxy
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/WFLY-7914?page=com.atlassian.jira.plugin.... ]
Tom Eicher updated WFLY-7914:
-----------------------------
Description:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs (below an {{abstract}} class) are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
System.out.println(a);
}
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
was:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
System.out.println(a);
}
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
> injection of sub-sub-EJB fails with proxy
> -----------------------------------------
>
> Key: WFLY-7914
> URL: https://issues.jboss.org/browse/WFLY-7914
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> wildfly-arquillian-2.0.2.Final
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: Tom Eicher
> Assignee: Jason Greene
>
> When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs (below an {{abstract}} class) are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
> In more Detail:
> {code}
> public interface A extends Serializable {}
> ...
> @Stateless
> public class A1 implements A {
> public A1() {
> }
> }
> ...
> public interface B extends A {}
> ...
> @Stateless
> public class B1 implements B {
> public B1() {
> }
> }
> ...
> public abstract class C implements A { }
> ...
> @Stateless
> public class C1 extends C {
> public C1() {
> }
> }
> ...
> @Stateless
> public class C2 extends C implements A {
> public C2() {
> }
> }
> ...
> @Singleton
> public class WeldProcessorInjectionProblemBean {
> }
> ...
> public class WeldProcessortInjectionProblemTest {
>
> @Inject WeldProcessorInjectionProblemBean client;
> @Inject @Any Instance<A> testinstances;
> @Test
> public void testSubclassInjection() {
> boolean foundC1=false, foundC2=false;
> for (A a : testinstances) {
> System.out.println(a);
> }
> }
> }
> ...
> Proxy for view class: com.ehtwo.core.util.A of EJB: C2
> Proxy for view class: com.ehtwo.core.util.A of EJB: A1
> Proxy for view class: com.ehtwo.core.util.B of EJB: B1
> {code}
> so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
> this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
> please move/copy issue to Wildfly-Core or Weld or as you see fit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7914) injection of sub-sub-EJB fails with proxy
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/WFLY-7914?page=com.atlassian.jira.plugin.... ]
Tom Eicher updated WFLY-7914:
-----------------------------
Description:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
System.out.println(a);
}
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
was:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
if (a instanceof C1) {
foundC1=true;
}
if (a instanceof C2) {
foundC2=true;
}
}
Assert.assertFalse("subsub EJB without re-implementaion of parent-parent-if was found. Weld was fixed. please remove workaround.", foundE1);
Assert.assertTrue("subsub EJB with re-implementaion of parent-parent-if was found. Weld even more broken?", foundE2);
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
> injection of sub-sub-EJB fails with proxy
> -----------------------------------------
>
> Key: WFLY-7914
> URL: https://issues.jboss.org/browse/WFLY-7914
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> wildfly-arquillian-2.0.2.Final
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: Tom Eicher
> Assignee: Jason Greene
>
> When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
> In more Detail:
> {code}
> public interface A extends Serializable {}
> ...
> @Stateless
> public class A1 implements A {
> public A1() {
> }
> }
> ...
> public interface B extends A {}
> ...
> @Stateless
> public class B1 implements B {
> public B1() {
> }
> }
> ...
> public abstract class C implements A { }
> ...
> @Stateless
> public class C1 extends C {
> public C1() {
> }
> }
> ...
> @Stateless
> public class C2 extends C implements A {
> public C2() {
> }
> }
> ...
> @Singleton
> public class WeldProcessorInjectionProblemBean {
> }
> ...
> public class WeldProcessortInjectionProblemTest {
>
> @Inject WeldProcessorInjectionProblemBean client;
> @Inject @Any Instance<A> testinstances;
> @Test
> public void testSubclassInjection() {
> boolean foundC1=false, foundC2=false;
> for (A a : testinstances) {
> System.out.println(a);
> }
> }
> }
> ...
> Proxy for view class: com.ehtwo.core.util.A of EJB: C2
> Proxy for view class: com.ehtwo.core.util.A of EJB: A1
> Proxy for view class: com.ehtwo.core.util.B of EJB: B1
> {code}
> so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
> this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
> please move/copy issue to Wildfly-Core or Weld or as you see fit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7914) injection of sub-sub-EJB fails with proxy
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/WFLY-7914?page=com.atlassian.jira.plugin.... ]
Tom Eicher updated WFLY-7914:
-----------------------------
Description:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundC1=false, foundC2=false;
for (A a : testinstances) {
if (a instanceof C1) {
foundC1=true;
}
if (a instanceof C2) {
foundC2=true;
}
}
Assert.assertFalse("subsub EJB without re-implementaion of parent-parent-if was found. Weld was fixed. please remove workaround.", foundE1);
Assert.assertTrue("subsub EJB with re-implementaion of parent-parent-if was found. Weld even more broken?", foundE2);
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
was:
When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
In more Detail:
{code}
public interface A extends Serializable {}
...
@Stateless
public class A1 implements A {
public A1() {
}
}
...
public interface B extends A {}
...
@Stateless
public class B1 implements B {
public B1() {
}
}
...
public abstract class C implements A { }
...
@Stateless
public class C1 extends C {
public C1() {
}
}
...
@Stateless
public class C2 extends C implements A {
public C2() {
}
}
...
@Singleton
public class WeldProcessorInjectionProblemBean {
}
...
public class WeldProcessortInjectionProblemTest {
@Inject WeldProcessorInjectionProblemBean client;
@Inject @Any Instance<A> testinstances;
@Test
public void testSubclassInjection() {
boolean foundE1=false, foundE2=false;
for (A a : testinstances) {
if (a instanceof E1) {
foundE1=true;
}
if (a instanceof E2) {
foundE2=true;
}
}
Assert.assertFalse("subsub EJB without re-implementaion of parent-parent-if was found. Weld was fixed. please remove workaround.", foundE1);
Assert.assertTrue("subsub EJB with re-implementaion of parent-parent-if was found. Weld even more broken?", foundE2);
}
}
...
Proxy for view class: com.ehtwo.core.util.A of EJB: C2
Proxy for view class: com.ehtwo.core.util.A of EJB: A1
Proxy for view class: com.ehtwo.core.util.B of EJB: B1
{code}
so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
please move/copy issue to Wildfly-Core or Weld or as you see fit.
> injection of sub-sub-EJB fails with proxy
> -----------------------------------------
>
> Key: WFLY-7914
> URL: https://issues.jboss.org/browse/WFLY-7914
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> wildfly-arquillian-2.0.2.Final
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: Tom Eicher
> Assignee: Jason Greene
>
> When a hierarchy of EJBs is looked up via {{Inject Instance}} for an interface that the toplevel ejb implements, lower-hierarchy EJBs are not found unless they (redundantly) reimplement the interface, when Weld is using view proxies.
> In more Detail:
> {code}
> public interface A extends Serializable {}
> ...
> @Stateless
> public class A1 implements A {
> public A1() {
> }
> }
> ...
> public interface B extends A {}
> ...
> @Stateless
> public class B1 implements B {
> public B1() {
> }
> }
> ...
> public abstract class C implements A { }
> ...
> @Stateless
> public class C1 extends C {
> public C1() {
> }
> }
> ...
> @Stateless
> public class C2 extends C implements A {
> public C2() {
> }
> }
> ...
> @Singleton
> public class WeldProcessorInjectionProblemBean {
> }
> ...
> public class WeldProcessortInjectionProblemTest {
>
> @Inject WeldProcessorInjectionProblemBean client;
> @Inject @Any Instance<A> testinstances;
> @Test
> public void testSubclassInjection() {
> boolean foundC1=false, foundC2=false;
> for (A a : testinstances) {
> if (a instanceof C1) {
> foundC1=true;
> }
> if (a instanceof C2) {
> foundC2=true;
> }
> }
> Assert.assertFalse("subsub EJB without re-implementaion of parent-parent-if was found. Weld was fixed. please remove workaround.", foundE1);
> Assert.assertTrue("subsub EJB with re-implementaion of parent-parent-if was found. Weld even more broken?", foundE2);
> }
> }
> ...
> Proxy for view class: com.ehtwo.core.util.A of EJB: C2
> Proxy for view class: com.ehtwo.core.util.A of EJB: A1
> Proxy for view class: com.ehtwo.core.util.B of EJB: B1
> {code}
> so, C1 is _not found/injected_ but C2 _is found/injected_, just because C2 re-implements A, which is redundant because it's at the top of the class hierarchy anyway.
> this only happens when "proxy for view" are being applied. (in my case because the EJBs are in a JAR and the Test in a WAR inside an EAR). When running inside one module, and no weld proxies are used, all classes including C1 are injected correctly.
> please move/copy issue to Wildfly-Core or Weld or as you see fit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months