[JBoss JIRA] (DROOLS-2371) Unable to complete your request. The following exception occurred: (TypeError) in Guided Decision Table Graph
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2371?page=com.atlassian.jira.plugi... ]
Michael Anstis moved RHDM-480 to DROOLS-2371:
---------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-2371 (was: RHDM-480)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: Guided Decision Table Editor
(was: Decision Central)
Affects Version/s: 7.6.0.Final
(was: 7.0.0.GA)
QE Status: NEW
> Unable to complete your request. The following exception occurred: (TypeError) in Guided Decision Table Graph
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2371
> URL: https://issues.jboss.org/browse/DROOLS-2371
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.6.0.Final
> Environment: FireFox ESR 52.3.0 (64-bit)
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: support
>
> An Error pops up if we open the same Guided Decision Table both in Guided Decision Table Editor and Guided Decision Table Graph (without closing the Editors by "x" button).
> The error message has 2 variants.
> {noformat}
> Unable to complete your request. The following exception occurred: (TypeError) : a is null.
> {noformat}
> {noformat}
> Unable to complete your request. The following exception occurred: (TypeError) : Cannot read property 'I' of null.
> {noformat}
> See attached screen shots (TypeError01.png, TypeError02.png).
> If I close the popup, I can continue using decision-central.
> See "Steps to Reproduce" for detailed steps.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2371) Unable to complete your request. The following exception occurred: (TypeError) in Guided Decision Table Graph
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2371?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2371:
-----------------------------------
Sprint: 2018 Week 09-10
> Unable to complete your request. The following exception occurred: (TypeError) in Guided Decision Table Graph
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2371
> URL: https://issues.jboss.org/browse/DROOLS-2371
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.6.0.Final
> Environment: FireFox ESR 52.3.0 (64-bit)
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: support
>
> An Error pops up if we open the same Guided Decision Table both in Guided Decision Table Editor and Guided Decision Table Graph (without closing the Editors by "x" button).
> The error message has 2 variants.
> {noformat}
> Unable to complete your request. The following exception occurred: (TypeError) : a is null.
> {noformat}
> {noformat}
> Unable to complete your request. The following exception occurred: (TypeError) : Cannot read property 'I' of null.
> {noformat}
> See attached screen shots (TypeError01.png, TypeError02.png).
> If I close the popup, I can continue using decision-central.
> See "Steps to Reproduce" for detailed steps.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-9955:
-------------------------------------
[~zhfeng] please can you have a look and see if you can make the change that David is requesting?
> Compatibility problem: allow a timeout value of "0" to be set
> -------------------------------------------------------------
>
> Key: WFLY-9955
> URL: https://issues.jboss.org/browse/WFLY-9955
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: David Lloyd
> Assignee: Amos Feng
>
> Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value.
> The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-9955:
-----------------------------------
Assignee: Amos Feng (was: Tom Jenkinson)
> Compatibility problem: allow a timeout value of "0" to be set
> -------------------------------------------------------------
>
> Key: WFLY-9955
> URL: https://issues.jboss.org/browse/WFLY-9955
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: David Lloyd
> Assignee: Amos Feng
>
> Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value.
> The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9955:
-----------------------------------
It is coming from there, but the behavior of that method is not going to be changed. The change should be made in the handling of the management model attribute in the WildFly code base to allow a value of 0 (but perhaps deprecate it with a warning). In addition I think we should have a maximum timeout attribute as I said above, but this can be a separate enhancement (with support from WFTC).
> Compatibility problem: allow a timeout value of "0" to be set
> -------------------------------------------------------------
>
> Key: WFLY-9955
> URL: https://issues.jboss.org/browse/WFLY-9955
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
>
> Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value.
> The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-9955:
-------------------------------------
Where should this change be made? I thought the exception was coming from
at org.wildfly.transaction.client.ContextTransactionManager.setGlobalDefaultTransactionTimeout(ContextTransactionManager.java:183)
> Compatibility problem: allow a timeout value of "0" to be set
> -------------------------------------------------------------
>
> Key: WFLY-9955
> URL: https://issues.jboss.org/browse/WFLY-9955
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
>
> Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value.
> The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9973) WildFly 12 IIOP always requires SSL
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9973?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-9973:
------------------------------
Attachment: client-side.war
> WildFly 12 IIOP always requires SSL
> -----------------------------------
>
> Key: WFLY-9973
> URL: https://issues.jboss.org/browse/WFLY-9973
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 11.0.0.Final, 12.0.0.Final
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Attachments: client-side.war, server-side.war
>
>
> When app deployed to WF 10.1 calls an EJB deployed to WF 12.0 via IIOP, the call will fail because WF 12.0 responds (Location Forward message - GIOP protocol) that It requires SSL even if It does not (to the best of my knowledge).
> WF 12.0 standard IIOP subystem configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.0">
> <orb socket-binding="iiop"/>
> <initializers security="identity" transactions="spec"/>
> <security server-requires-ssl="false" client-requires-ssl="false"/>
> </subsystem>
> {code}
> It is observable [here|https://github.com/wildfly/wildfly/blob/10.1.0.Final/iiop-openjdk/sr...] (client side debugging). ssl.target_requires is true and ssl.target_supports is false.
> This does not happen when
> * server side is WF 10.1 - ssl.target_requires is false and ssl.target_supports is true.
> * client side is WF 12.0 - it works due to better condition at client side [here|https://github.com/wildfly/wildfly/blob/12.0.0.Final/iiop-openjdk/sr...] which results to not using SSL
> If IIOP subsystem is configured to use iiop ssl socket, It will work - EAP just does not responds correctly if ssl is not configured.
> It is possible that I have malconfigured server side EAP and I am missing something.
> Deployments used as reproducers are simple.
> client-side: simple servlet that calls an EJB
> {code:java}
> @WebServlet(urlPatterns = "/")
> public class ClientServlet extends HttpServlet {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> try {
> Context ctx = new InitialContext(new Properties());
> Object iiopObj = ctx.lookup("corbaname:iiop:127.0.0.1:3628#Bean");
> BeanHome home = (BeanHome) PortableRemoteObject.narrow(iiopObj, BeanHome.class);
> BeanRemote beanRemote = home.create();
> String string = beanRemote.invoke();
> System.out.println("Bean obtained by IIOP returned: " + string);
> resp.getWriter().append("Bean obtained by IIOP returned: ").append(string).append("\n");
> } catch (Exception e) {
> resp.getWriter().append("Calling bean failed: ");
> e.printStackTrace(resp.getWriter());
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> server-side: simple EJB
> {code:java}
> public class Bean {
> public String invoke() {
> return "server side invocation: success";
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9973) WildFly 12 IIOP always requires SSL
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9973?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-9973:
------------------------------
Attachment: server-side.war
> WildFly 12 IIOP always requires SSL
> -----------------------------------
>
> Key: WFLY-9973
> URL: https://issues.jboss.org/browse/WFLY-9973
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 11.0.0.Final, 12.0.0.Final
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Attachments: client-side.war, server-side.war
>
>
> When app deployed to WF 10.1 calls an EJB deployed to WF 12.0 via IIOP, the call will fail because WF 12.0 responds (Location Forward message - GIOP protocol) that It requires SSL even if It does not (to the best of my knowledge).
> WF 12.0 standard IIOP subystem configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.0">
> <orb socket-binding="iiop"/>
> <initializers security="identity" transactions="spec"/>
> <security server-requires-ssl="false" client-requires-ssl="false"/>
> </subsystem>
> {code}
> It is observable [here|https://github.com/wildfly/wildfly/blob/10.1.0.Final/iiop-openjdk/sr...] (client side debugging). ssl.target_requires is true and ssl.target_supports is false.
> This does not happen when
> * server side is WF 10.1 - ssl.target_requires is false and ssl.target_supports is true.
> * client side is WF 12.0 - it works due to better condition at client side [here|https://github.com/wildfly/wildfly/blob/12.0.0.Final/iiop-openjdk/sr...] which results to not using SSL
> If IIOP subsystem is configured to use iiop ssl socket, It will work - EAP just does not responds correctly if ssl is not configured.
> It is possible that I have malconfigured server side EAP and I am missing something.
> Deployments used as reproducers are simple.
> client-side: simple servlet that calls an EJB
> {code:java}
> @WebServlet(urlPatterns = "/")
> public class ClientServlet extends HttpServlet {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> try {
> Context ctx = new InitialContext(new Properties());
> Object iiopObj = ctx.lookup("corbaname:iiop:127.0.0.1:3628#Bean");
> BeanHome home = (BeanHome) PortableRemoteObject.narrow(iiopObj, BeanHome.class);
> BeanRemote beanRemote = home.create();
> String string = beanRemote.invoke();
> System.out.println("Bean obtained by IIOP returned: " + string);
> resp.getWriter().append("Bean obtained by IIOP returned: ").append(string).append("\n");
> } catch (Exception e) {
> resp.getWriter().append("Calling bean failed: ");
> e.printStackTrace(resp.getWriter());
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> server-side: simple EJB
> {code:java}
> public class Bean {
> public String invoke() {
> return "server side invocation: success";
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9973) WildFly 12 IIOP always requires SSL
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9973?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-9973:
------------------------------
Steps to Reproduce:
Lets have two server, WF 10.1 (client role), WF 12.0 (server role)
# deploy client-side.war to WF 10.1
# deploy server-side.jar to WF 12.0
# start WF 10.1 with command "./bin/standalone.sh -c standalone-full.xml -Djboss.node.name=1"
# start WF 12.0 with command "./bin/standalone.sh -c standalone-full.xml -Djboss.node.name=2 -Djboss.socket.binding.port-offset=100"
# access localhost:8080 to run the scenario
You can see in WF 10.1 console output that it has got into infinite loop trying to connect to unaccessible IIOP SSL socket.
was:
Lets have two server, WF 10.1 (client role), WF 12.0 (server role)
# deploy client-side.war to WF 10.1
# deploy server-side.jar to WF 12.0
# start WF 10.1 with command "./bin/standalone.sh -c standalone-full.xml -Djboss.node.name=1"
# start WF 12.0 with command "./bin/standalone.sh -c standalone-full.xml -Djboss.node.name=2 -Djboss.socket.binding.port-offset=100"
# access localhost:8080 to run the scenario
You can see in WF 10.1 console output that it has got into infinite loop trying to connect to IIOP SSL socket which is not accessible.
> WildFly 12 IIOP always requires SSL
> -----------------------------------
>
> Key: WFLY-9973
> URL: https://issues.jboss.org/browse/WFLY-9973
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 11.0.0.Final, 12.0.0.Final
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
>
> When app deployed to WF 10.1 calls an EJB deployed to WF 12.0 via IIOP, the call will fail because WF 12.0 responds (Location Forward message - GIOP protocol) that It requires SSL even if It does not (to the best of my knowledge).
> WF 12.0 standard IIOP subystem configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.0">
> <orb socket-binding="iiop"/>
> <initializers security="identity" transactions="spec"/>
> <security server-requires-ssl="false" client-requires-ssl="false"/>
> </subsystem>
> {code}
> It is observable [here|https://github.com/wildfly/wildfly/blob/10.1.0.Final/iiop-openjdk/sr...] (client side debugging). ssl.target_requires is true and ssl.target_supports is false.
> This does not happen when
> * server side is WF 10.1 - ssl.target_requires is false and ssl.target_supports is true.
> * client side is WF 12.0 - it works due to better condition at client side [here|https://github.com/wildfly/wildfly/blob/12.0.0.Final/iiop-openjdk/sr...] which results to not using SSL
> If IIOP subsystem is configured to use iiop ssl socket, It will work - EAP just does not responds correctly if ssl is not configured.
> It is possible that I have malconfigured server side EAP and I am missing something.
> Deployments used as reproducers are simple.
> client-side: simple servlet that calls an EJB
> {code:java}
> @WebServlet(urlPatterns = "/")
> public class ClientServlet extends HttpServlet {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> try {
> Context ctx = new InitialContext(new Properties());
> Object iiopObj = ctx.lookup("corbaname:iiop:127.0.0.1:3628#Bean");
> BeanHome home = (BeanHome) PortableRemoteObject.narrow(iiopObj, BeanHome.class);
> BeanRemote beanRemote = home.create();
> String string = beanRemote.invoke();
> System.out.println("Bean obtained by IIOP returned: " + string);
> resp.getWriter().append("Bean obtained by IIOP returned: ").append(string).append("\n");
> } catch (Exception e) {
> resp.getWriter().append("Calling bean failed: ");
> e.printStackTrace(resp.getWriter());
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> server-side: simple EJB
> {code:java}
> public class Bean {
> public String invoke() {
> return "server side invocation: success";
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months