[Red Hat JIRA] (WFLY-13966) org.apache.xerces.parsers.DOMParser.parse throwing org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 2; "The markup in the document preceding the root element must be well-formed."
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFLY-13966?page=com.atlassian.jira.plugi... ]
Jason Lee resolved WFLY-13966.
------------------------------
Resolution: Out of Date
Neither Scott nor I have been able to reproduce this failure.
> org.apache.xerces.parsers.DOMParser.parse throwing org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 2; "The markup in the document preceding the root element must be well-formed."
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13966
> URL: https://issues.redhat.com/browse/WFLY-13966
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Assignee: Jason Lee
> Priority: Major
> Labels: EE9
>
> {quote}While running jacc/ejb tests, we get the below failure:
>
> [javatest.batch] [0m[0m15:15:38,672 INFO [org.jboss.as.server] (Thread-45) WFLYSRV0010: Deployed "jacc_ejb_methodperm.ear" (runtime-name : "jacc_ejb_methodperm.ear")
> [javatest.batch] [0m[0m15:15:38,676 INFO [stdout] (Thread-194) ************************************************************
> [javatest.batch] [0m[0m15:15:38,676 INFO [stdout] (Thread-194) * props file set to "/tmp/smarlow-cts-props.txt"
> [javatest.batch] [0m[0m15:15:38,677 INFO [stdout] (Thread-194) ************************************************************
> [javatest.batch] [0m[0m15:15:38,677 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ####### Value of harness.socket.retry.count is "10"
> [javatest.batch] [0m[0m15:15:38,677 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ####### Value of harness.log.port is "2000"
> [javatest.batch] [0m[0m15:15:38,677 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ####### Actual bind value of harness.log.port is "2000"
> [javatest.batch] [0m[0m15:15:38,739 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: *** in EETest.run(argv,p)
> [javatest.batch] [0m[0m15:15:38,739 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: TESTCLASS=com.sun.ts.tests.jacc.ejb.methodperm.Client
> [javatest.batch] [0m[0m15:15:38,739 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ** IN getRunMethod: testClass=com.sun.ts.tests.jacc.ejb.methodperm.Client
> [javatest.batch] [0m[0m15:15:38,739 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ** IN getRunMethod: testname=EJBMethodPermissionAddToRole
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ** GOT RUN METHOD!
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: **runmethod=EJBMethodPermissionAddToRole
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ABOUT TO GET SETUP METHOD!
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: No setupMethod annotation present
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: getSetupMethod - checking for testcase specific setup method: EJBMethodPermissionAddToRole_setup
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: getSetupMethod - checking for default class specific setup method
> [javatest.batch] [0m[0m15:15:38,740 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: GOT SETUP METHOD!
> [javatest.batch] [0m[0m15:15:38,741 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: No cleanupMethod annotation present
> [javatest.batch] [0m[0m15:15:38,741 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: getCleanupMethod - checking for testcase specific cleanup method: EJBMethodPermissionAddToRole_cleanup
> [javatest.batch] [0m[0m15:15:38,741 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: getCleanupMethod - checking for default class specific cleanup method
> [javatest.batch] [0m[0m15:15:38,741 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: GOT CLEANUP METHOD!
> [javatest.batch] [0m[0m15:15:38,741 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: TRACE: ABOUT TO INVOKE SETUP METHOD!
> [javatest.batch] [0m[0m15:15:38,742 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: setting logFileLocation based on passed in Properties
> [javatest.batch] [0m[0m15:15:38,742 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: log.file.location = /tmp/tck/wildfly/ee-9/dist/target/wildfly-21.0.0.Final-SNAPSHOT/standalone/log
> [javatest.batch] [0m[0m15:15:38,742 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: Setup ok
> [javatest.batch] [0m[31m15:15:38,744 ERROR [stderr] (Thread-194) [Fatal Error] :1:2: The markup in the document preceding the root element must be well-formed.
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: ERROR: The markup in the document preceding the root element must be well-formed.
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) 10-13-2020 15:15:38: ERROR: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 2; The markup in the document preceding the root element must be well-formed.
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:245)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at com.sun.ts.tests.jacc.util.LogFileProcessor.fetchLogs(LogFileProcessor.java:227)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at com.sun.ts.tests.jacc.ejb.methodperm.Client.setup(Client.java:82)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] [0m[0m15:15:38,745 INFO [stdout] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:569)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:337)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at com.sun.ts.tests.jacc.ejb.methodperm.Client.main(Client.java:66)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194) at java.lang.Thread.run(Thread.java:748)
> [javatest.batch] [0m[0m15:15:38,746 INFO [stdout] (Thread-194)
> [javatest.batch] [0m[31m15:15:38,746 ERROR [stderr] (Thread-194) org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 2; The markup in the document preceding the root element must be well-formed.
> [javatest.batch] [0m[31m15:15:38,746 ERROR [stderr] (Thread-194) at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:245)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.tests.jacc.util.LogFileProcessor.fetchLogs(LogFileProcessor.java:227)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.tests.jacc.ejb.methodperm.Client.setup(Client.java:82)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:569)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:337)
> [javatest.batch] [0m[31m15:15:38,747 ERROR [stderr] (Thread-194) at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at com.sun.ts.tests.jacc.ejb.methodperm.Client.main(Client.java:66)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99)
> [javatest.batch] [0m[31m15:15:38,748 ERROR [stderr] (Thread-194) at java.lang.Thread.run(Thread.java:748)
> {quote}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (JBMETA-420) Add the EE 9 xsds
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/JBMETA-420?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JBMETA-420:
-------------------------------------
Nice, thanks [~brian.stansberry]! I started reviewing the change but got distracted. It will be good to enable {code}<property name="org.jboss.metadata.parser.validate" value="true"/>{code} again!
> Add the EE 9 xsds
> -----------------
>
> Key: JBMETA-420
> URL: https://issues.redhat.com/browse/JBMETA-420
> Project: JBoss Metadata
> Issue Type: Enhancement
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> Follow up on JBMETA-419 by adding the relevant EE 9 xsd documents.
> They're not final yet so I figure it's better to add them separately from the JBMETA-419 parsing enhancement, which isn't particularly reliant on the exact schema files.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14434) Heap usage continuously growing and exhausting available heap memory in production
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14434?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-14434:
-------------------------------------
The 18.0.x branch has not been active for over a year. If your environment genuinely has that much inflexibility, you really ought to consider using EAP 7.3 (which is based on WF18) where the support window is measured in years, rather than months; and the following issues are already addressed.
If you are willing to manage patching WF18 yourself, look to these jiras:
https://issues.redhat.com/browse/WFLY-12937
https://issues.redhat.com/browse/WFLY-12938
https://issues.redhat.com/browse/WFLY-12939
https://issues.redhat.com/browse/WFLY-13998 (affects ATTRIBUTE granularity)
> Heap usage continuously growing and exhausting available heap memory in production
> ----------------------------------------------------------------------------------
>
> Key: WFLY-14434
> URL: https://issues.redhat.com/browse/WFLY-14434
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Manas Panda
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Heap_Size_keeps_increasing.jpg, Heap_dump_analysis_1.jpg
>
>
> # Problem description:
> Critical issue of heap usage continuously growing and exhausting available heap memory in production. As you can see in below heap dump org.infinispan.container.impl.DefaultDataContainer is growing as the time passes and not garbage collected by GC. This increase in heap happening after upgrading from Wildfly 10.1 to Wildfly 18.0.1. There is no change in JDK in both cases ( Wildfly 10.1 and Wildfly 18.0.1).
> 2. Web application environment
> * OS: RHEL 7.5
> * Wildfly 18.0.1
> * JDK 1.8
> * Wildfly is being run in cluster mode
> * Integrated with Keycloak 3.4.3 for SSO ( SAML)
> * Enabled Wildfly clustering mode
> * G1GC garbage collector used. And 20gigs of heap allocated ( -Xmx)
> * Environment of Web App on Wildfly 10.1 is same ( except Wildfly 18) with same hardware
> * Web application uses Spring web framework and security
> 3. Heap dump analysis
> * We have few web users logging in and every second and external application consuming few API’s exposed by same application.
> * As you can see infinispan.container.impl.DefaultDataContainer Has already grown 14gigs.
> * Please note that web application does not use infinispan directly.
> * The heap does not grow in wildfly 10.1 and its normal ( garbage gets collected and size gets reduced after GC)
> Please find the snapshot as attached.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14444) Reduce overhead of map protostream marshallers
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-14444:
-----------------------------------
Summary: Reduce overhead of map protostream marshallers
Key: WFLY-14444
URL: https://issues.redhat.com/browse/WFLY-14444
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: No Release
Reporter: Paul Ferraro
Assignee: Paul Ferraro
We can reduce the overhead of map marshalling by marshalling key and value as separate repeated fields, rather than using a repeated Map.Entry field.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14298) Using fault-tolerance in Wildfly 22 causes WELD-001408
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFLY-14298?page=com.atlassian.jira.plugi... ]
Jason Lee updated WFLY-14298:
-----------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat Employee' was removed.)
> Using fault-tolerance in Wildfly 22 causes WELD-001408
> ------------------------------------------------------
>
> Key: WFLY-14298
> URL: https://issues.redhat.com/browse/WFLY-14298
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, MP Metrics
> Affects Versions: 22.0.0.Final
> Reporter: sdfsd fsdfsdf
> Assignee: Jason Lee
> Priority: Major
>
> In wildfly 21, I used to put these lines into the standalone-full-ha.xml:
> <extension module="org.wildfly.extension.microprofile.fault-tolerance-smallrye"/>
> ...
> <subsystem xmlns="urn:wildfly:microprofile-fault-tolerance-smallrye:1.0"/>
> If I put those lines into the standalone-full-ha.xml of Wildfly 22 I get the following error when deploying an appliction that uses fault-tolerance:
> WELD-001408: Unsatisfied dependencies for type MetricRegistry with qualifiers @Default
> @Inject io.smallrye.faulttolerance.metrics.MetricsCollectorFactory.registry
>
> I already have these lines in the standalone:
> <extension module="org.wildfly.extension.metrics"/>
> <extension module="org.wildfly.extension.health"/>
>
> Is there something else I need to add in the standalone in order to keep using fault-tolerance in Wildfly 22?
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14298) Using fault-tolerance in Wildfly 22 causes WELD-001408
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFLY-14298?page=com.atlassian.jira.plugi... ]
Jason Lee edited comment on WFLY-14298 at 2/16/21 2:35 PM:
-----------------------------------------------------------
[~psonpson2] Does your config have something like this in it as well?
{code:java}
<subsystem xmlns="urn:wildfly:metrics:1.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
{code}
WildFly 22 added a subsystem that has to be there for Metrics to work, so a WF 21 config used under WF 22 will not work without that config change.
That aside, I tested your config changes on WildFly master (WF 23), and the server started without complaint.
was (Author: jaslee):
[~psonpson2] Does your config have something like this in it as well?
{code:java}
<subsystem xmlns="urn:wildfly:metrics:1.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
{code}
That aside, I tested your config changes on WildFly master (WF 23), and the server started without complaint.
> Using fault-tolerance in Wildfly 22 causes WELD-001408
> ------------------------------------------------------
>
> Key: WFLY-14298
> URL: https://issues.redhat.com/browse/WFLY-14298
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, MP Metrics
> Affects Versions: 22.0.0.Final
> Reporter: sdfsd fsdfsdf
> Assignee: Jason Lee
> Priority: Major
>
> In wildfly 21, I used to put these lines into the standalone-full-ha.xml:
> <extension module="org.wildfly.extension.microprofile.fault-tolerance-smallrye"/>
> ...
> <subsystem xmlns="urn:wildfly:microprofile-fault-tolerance-smallrye:1.0"/>
> If I put those lines into the standalone-full-ha.xml of Wildfly 22 I get the following error when deploying an appliction that uses fault-tolerance:
> WELD-001408: Unsatisfied dependencies for type MetricRegistry with qualifiers @Default
> @Inject io.smallrye.faulttolerance.metrics.MetricsCollectorFactory.registry
>
> I already have these lines in the standalone:
> <extension module="org.wildfly.extension.metrics"/>
> <extension module="org.wildfly.extension.health"/>
>
> Is there something else I need to add in the standalone in order to keep using fault-tolerance in Wildfly 22?
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14298) Using fault-tolerance in Wildfly 22 causes WELD-001408
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFLY-14298?page=com.atlassian.jira.plugi... ]
Jason Lee commented on WFLY-14298:
----------------------------------
[~psonpson2] Does your config have something like this in it as well?
{code:java}
<subsystem xmlns="urn:wildfly:metrics:1.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
{code}
That aside, I tested your config changes on WildFly master (WF 23), and the server started without complaint.
> Using fault-tolerance in Wildfly 22 causes WELD-001408
> ------------------------------------------------------
>
> Key: WFLY-14298
> URL: https://issues.redhat.com/browse/WFLY-14298
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, MP Metrics
> Affects Versions: 22.0.0.Final
> Reporter: sdfsd fsdfsdf
> Assignee: Jason Lee
> Priority: Major
>
> In wildfly 21, I used to put these lines into the standalone-full-ha.xml:
> <extension module="org.wildfly.extension.microprofile.fault-tolerance-smallrye"/>
> ...
> <subsystem xmlns="urn:wildfly:microprofile-fault-tolerance-smallrye:1.0"/>
> If I put those lines into the standalone-full-ha.xml of Wildfly 22 I get the following error when deploying an appliction that uses fault-tolerance:
> WELD-001408: Unsatisfied dependencies for type MetricRegistry with qualifiers @Default
> @Inject io.smallrye.faulttolerance.metrics.MetricsCollectorFactory.registry
>
> I already have these lines in the standalone:
> <extension module="org.wildfly.extension.metrics"/>
> <extension module="org.wildfly.extension.health"/>
>
> Is there something else I need to add in the standalone in order to keep using fault-tolerance in Wildfly 22?
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-5172) [DMN Designer] Graph - Default names for input nodes
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-5172?page=com.atlassian.jira.plug... ]
Guilherme Gomes reassigned DROOLS-5172:
---------------------------------------
Assignee: Guilherme Gomes (was: Mario Fusco)
> [DMN Designer] Graph - Default names for input nodes
> ----------------------------------------------------
>
> Key: DROOLS-5172
> URL: https://issues.redhat.com/browse/DROOLS-5172
> Project: Drools
> Issue Type: Task
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
>
> When users update the type of a recently created input node, they usually change the node name from “InputData–1” to “Person” (if the new type is “Person”).
> Should we do this automatically? Should we ask for the type when users create an input node? Should we apply the same approach for other nodes (BKMs, Decisions, etc.)?
> This UX JIRA aims to cover these open questions, to enhance the user experience when they are creating new nodes in the canvas.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month