[JBoss JIRA] (WFLY-13691) Ajax call causes exception: Target Unreachable, 'null' returned null
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13691?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-13691:
-----------------------------------
[~soul2zimate] Would you be able to take a look at this one?
> Ajax call causes exception: Target Unreachable, 'null' returned null
> --------------------------------------------------------------------
>
> Key: WFLY-13691
> URL: https://issues.redhat.com/browse/WFLY-13691
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 20.0.1.Final
> Reporter: erick leal
> Priority: Major
>
> I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
> Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
> When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
> XHTML:
>
> {code:java}
> <f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
> beans
> {code:java}
> import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
> model
> {code:java}
> public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
> You also need to set in web.xml the following param
> {code:java}
> <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5061) DMN strongly typed codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ]
Matteo Mortari reassigned DROOLS-5061:
--------------------------------------
Assignee: Matteo Mortari (was: Luca Molteni)
> DMN strongly typed codegen DMNContext and DMNResult
> ---------------------------------------------------
>
> Key: DROOLS-5061
> URL: https://issues.redhat.com/browse/DROOLS-5061
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> *Motivation*: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
> *Goals*: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> *Impacts*: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
> A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Surface and interface common to:
> * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
> * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
> ** for Quarkus based, use RegisterForReflection annotation
> ** use MP validation for allowedvalues
> * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
> Documentation:
> * the programmatic use of the generated classes, directly, is DISCOURAGED
> * if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[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)
5 years, 11 months
[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)
5 years, 11 months
[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)
5 years, 11 months
[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)
5 years, 11 months
[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)
5 years, 11 months
[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)
5 years, 11 months