[JBoss JIRA] (WFCORE-5060) AS-TS IBM test cases fails due to update mockserver-netty
by Vratislav Marek (Jira)
[ https://issues.redhat.com/browse/WFCORE-5060?page=com.atlassian.jira.plug... ]
Vratislav Marek moved JBEAP-19970 to WFCORE-5060:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-5060 (was: JBEAP-19970)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: 13.0.0.Beta2
12.0.3.Final
11.0.0.Final
(was: 7.4.0.CD20)
> AS-TS IBM test cases fails due to update mockserver-netty
> ---------------------------------------------------------
>
> Key: WFCORE-5060
> URL: https://issues.redhat.com/browse/WFCORE-5060
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Beta2, 12.0.3.Final, 11.0.0.Final
> Reporter: Vratislav Marek
> Priority: Major
>
> Affected test Cases
> * org.wildfly.extension.elytron.CertificateAuthoritiesTestCase
> * org.wildfly.extension.elytron.KeyStoresTestCase
> * org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> It failed after:
> * [wildfly/wildfly-core: Pull Request 4085|https://github.com/wildfly/wildfly-core/pull/4085]
> * update mockserver-client-java/core/netty from 5.4.1 to 5.9.0
> Root cause:
> * java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
> Environments:
> * IBM jdk 1.8
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K updated WFLY-13692:
-----------------------
Description:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
was:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K updated WFLY-13692:
-----------------------
Description:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
was:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure", which ignored.
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (JGRP-2495) A variant of RELAY2.printTopology() returning a member list
by S Pokutniy (Jira)
S Pokutniy created JGRP-2495:
--------------------------------
Summary: A variant of RELAY2.printTopology() returning a member list
Key: JGRP-2495
URL: https://issues.redhat.com/browse/JGRP-2495
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.0.24
Reporter: S Pokutniy
Assignee: Bela Ban
It would be great if there existed a variant of A variant of RELAY2.printTopology() function, returning a list of all members with their logical names and physical addresses. As of now printTopology(boolean) returns a string with all members. Even though the members of one site do not know about the members of the other site, it would still be great to be able to show the list of all members connected over the bridge, be it for demonstration or monitoring purpose.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K updated WFLY-13692:
-----------------------
Description:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure", which ignored.
was:
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imaging that "some-stupid-element" is in fact "jboss-deployment-structure", which ignored.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
L K created WFLY-13692:
--------------------------
Summary: Anything in jboss-all.xml after <weld/> element is ignored
Key: WFLY-13692
URL: https://issues.redhat.com/browse/WFLY-13692
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 20.0.1.Final
Reporter: L K
Assignee: Matěj Novotný
Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
As a result, everything that comes after </weld> is ignored.
This jboss-all.xml fails, as expected:
{code:java}
<jboss xmlns="urn:jboss:1.0">
<some-stupid-element/>
<weld xmlns="urn:jboss:weld:1.1"/>
</jboss>
{code}
This one is successfully parsed (but must also fail):
{code:java}
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1"/>
<some-stupid-element/>
</jboss>
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13360) Log INFO message when EJB does not implement Business interface
by Carlo de Wolf (Jira)
[ https://issues.redhat.com/browse/WFLY-13360?page=com.atlassian.jira.plugi... ]
Carlo de Wolf edited comment on WFLY-13360 at 7/23/20 7:54 AM:
---------------------------------------------------------------
EJB B does not need to implement business interface explicitly, it just won't expose the views defined in EJB A.
{panel:title=EJB 3.2 4.9.2.1}
A session bean class is permitted to have superclasses that are themselves session bean classes. However, there are no special rules that apply to the processing of annotations or the deployment descriptor for this case. For the purposes of processing a particular session bean class, all superclass processing is identical regardless of whether the superclasses are themselves session bean classes. In this regard, the use of session bean classes as superclasses merely represents a convenient use of _implementation inheritance_, but does not have _component inheritance semantics_.
{panel}
was (Author: wolfc):
EJB B does not need to implement business interface explicitly, it just won't expose the views defined in EJB A.
{panel:title=EJB 3.2 4.9.2.1}
A session bean class is permitted to have superclasses that are themselves session bean classes. How-
ever, there are no special rules that apply to the processing of annotations or the deployment descriptor
for this case. For the purposes of processing a particular session bean class, all superclass processing is
identical regardless of whether the superclasses are themselves session bean classes. In this regard, the
use of session bean classes as superclasses merely represents a convenient use of _implementation inher-
itance_, but does not have _component inheritance semantics_.
{panel}
> Log INFO message when EJB does not implement Business interface
> ---------------------------------------------------------------
>
> Key: WFLY-13360
> URL: https://issues.redhat.com/browse/WFLY-13360
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> From the specification every business interface need to be declared explicitly as a business interface by @Remote or @Local annotation or deployment descriptor.
> {code}
> EJB 3.2 specification
> 4.9.7 Session Bean’s Business Interface
> - The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor.
> - All business interfaces must be explicitly designated as such if any of the following is true:
> - the bean exposes a no-interface view
> - any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> - using the Local or Remote annotation with a non-empty value on the bean class
> - using the Local or Remote annotation on the interface
> - in the deployment descriptor
> {code}
> If EJB A implements I and EJB B extends A , EJB B must also declare it implements I in order to be spec compliant:
> {code}
> public interface I {...}
>
> @Stateless
> public class A implements I {...}
>
> @Stateless
> public class B extends A {...}
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13360) Log INFO message when EJB does not implement Business interface
by Carlo de Wolf (Jira)
[ https://issues.redhat.com/browse/WFLY-13360?page=com.atlassian.jira.plugi... ]
Carlo de Wolf commented on WFLY-13360:
--------------------------------------
EJB B does not need to implement business interface explicitly, it just won't expose the views defined in EJB A.
{panel:title=EJB 3.2 4.9.2.1}
A session bean class is permitted to have superclasses that are themselves session bean classes. How-
ever, there are no special rules that apply to the processing of annotations or the deployment descriptor
for this case. For the purposes of processing a particular session bean class, all superclass processing is
identical regardless of whether the superclasses are themselves session bean classes. In this regard, the
use of session bean classes as superclasses merely represents a convenient use of _implementation inher-
itance_, but does not have _component inheritance semantics_.
{panel}
> Log INFO message when EJB does not implement Business interface
> ---------------------------------------------------------------
>
> Key: WFLY-13360
> URL: https://issues.redhat.com/browse/WFLY-13360
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> From the specification every business interface need to be declared explicitly as a business interface by @Remote or @Local annotation or deployment descriptor.
> {code}
> EJB 3.2 specification
> 4.9.7 Session Bean’s Business Interface
> - The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor.
> - All business interfaces must be explicitly designated as such if any of the following is true:
> - the bean exposes a no-interface view
> - any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> - using the Local or Remote annotation with a non-empty value on the bean class
> - using the Local or Remote annotation on the interface
> - in the deployment descriptor
> {code}
> If EJB A implements I and EJB B extends A , EJB B must also declare it implements I in order to be spec compliant:
> {code}
> public interface I {...}
>
> @Stateless
> public class A implements I {...}
>
> @Stateless
> public class B extends A {...}
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month