[JBoss JIRA] (DROOLS-2697) [DMN Designer] Improve readability of node labels
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2697?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2697:
----------------------------------------
[~dadossan] [~tirelli] thought this might be a good candidate for you; as it involves _Stunner_ related code.
Edson would like the node text to be truncated and appended with "..." if the text is wider than the Node view itself. E.g. a Node with text "A long description" would become "A long de..." if it is wider than the Node view. If the node is made wider the text would change to "A long descrip..." etc until the node is wide enough to show all the text.
You can also take this opportunity to perhaps remove the font border (as we have no control over it in the UI and it's always black and obscures the fonts _real_ colour).
> [DMN Designer] Improve readability of node labels
> -------------------------------------------------
>
> Key: DROOLS-2697
> URL: https://issues.jboss.org/browse/DROOLS-2697
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Daniel José dos Santos
> Priority: Major
>
> Node names are bold text without background rectangle and hence _merge_ into the node SVG. It'd be nicer to change font to regular and provide a (white) background rectangle to improve readability. See https://github.com/kiegroup/kie-wb-common/pull/1929#pullrequestreview-133...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-4228) Weld subsystem should declare a capability
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4228?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4228:
---------------------------------
Description:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
WeldDeploymentMarker is consideated as part of Weld subsystem, so, we are not going to move it to wfcore
was:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> Weld subsystem should declare a capability
> ------------------------------------------
>
> Key: WFCORE-4228
> URL: https://issues.jboss.org/browse/WFCORE-4228
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
> Specifically it was identified the following minor changes:
> * -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
> * Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> WeldDeploymentMarker is consideated as part of Weld subsystem, so, we are not going to move it to wfcore
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-4228) Weld subsystem should declare a capability
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4228?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4228:
---------------------------------
Description:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
was:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> Weld subsystem should declare a capability
> ------------------------------------------
>
> Key: WFCORE-4228
> URL: https://issues.jboss.org/browse/WFCORE-4228
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
> Specifically it was identified the following minor changes:
> * -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
> * Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-10929?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10929:
--------------------------------------
Steps to Reproduce:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add(use-server-log=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
was:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
> Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10929
> URL: https://issues.jboss.org/browse/WFLY-10929
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: helloworld.war
>
>
> Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}.
> However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too.
> When HTTP request with unescaped characters is performed against server:
> {code}
> curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
> {code}
> we get 200 OK HTTP response, although the result in access log looks like:
> {code:title=HTTP actual result}
> 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦
> _test.html?param=íê¸ì´ë¦
> _ahoy HTTP/1.1" 200 950
> {code}
> but we expect following:
> {code:title=HTTP expected result}
> 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950
> {code}
> Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:
> {code}
> curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
> {code}
> we receive 404 Not Found HTTP response and following record in access.log:
> {code:HTTPS actual result}
> 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68
> {code}
> however expected result should be similar to what we expect for HTTP, I guess.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-10929?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-10929:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Stuart Douglas)
> Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10929
> URL: https://issues.jboss.org/browse/WFLY-10929
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: helloworld.war
>
>
> Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}.
> However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too.
> When HTTP request with unescaped characters is performed against server:
> {code}
> curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
> {code}
> we get 200 OK HTTP response, although the result in access log looks like:
> {code:title=HTTP actual result}
> 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦
> _test.html?param=íê¸ì´ë¦
> _ahoy HTTP/1.1" 200 950
> {code}
> but we expect following:
> {code:title=HTTP expected result}
> 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950
> {code}
> Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:
> {code}
> curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
> {code}
> we receive 404 Not Found HTTP response and following record in access.log:
> {code:HTTPS actual result}
> 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68
> {code}
> however expected result should be similar to what we expect for HTTP, I guess.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3384) [DMN Designer] DMN Editor Index
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3384?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3384:
--------------------------------
Affects Version/s: 7.15.0.Final
> [DMN Designer] DMN Editor Index
> -------------------------------
>
> Key: DROOLS-3384
> URL: https://issues.jboss.org/browse/DROOLS-3384
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
>
> This JIRA aims to cover all tasks related to interactions between DMN files.
> The Import Feature introduces scenarios that couples DMN files to each other. See these two DMN files:
> {quote}*file1.dmn*
> - Person (Structure)
> -- name (Text)
> -- age (Number){quote}
> {quote}*file2.dmn*
> - Order (Structure)
> -- price (Number)
> -- product (Text)
> -- salesman (file1.Person)
> -- buyer (file1.Person){quote}
> Notice that the user cannot delete the "file1.dmn", because it is referenced by the "file2.dmn".
> Other scenarios:
> - How to handle DMN files from {{kjars}}?
> - Is the user allowed to rename the Data Type "Person"?
> - Is the user allowed to remove the Data Type "Person"?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3384) [DMN Designer] DMN Editor Index
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3384?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3384:
--------------------------------
Tester: Jozef Marko
> [DMN Designer] DMN Editor Index
> -------------------------------
>
> Key: DROOLS-3384
> URL: https://issues.jboss.org/browse/DROOLS-3384
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
>
> This JIRA aims to cover all tasks related to interactions between DMN files.
> The Import Feature introduces scenarios that couples DMN files to each other. See these two DMN files:
> {quote}*file1.dmn*
> - Person (Structure)
> -- name (Text)
> -- age (Number){quote}
> {quote}*file2.dmn*
> - Order (Structure)
> -- price (Number)
> -- product (Text)
> -- salesman (file1.Person)
> -- buyer (file1.Person){quote}
> Notice that the user cannot delete the "file1.dmn", because it is referenced by the "file2.dmn".
> Other scenarios:
> - How to handle DMN files from {{kjars}}?
> - Is the user allowed to rename the Data Type "Person"?
> - Is the user allowed to remove the Data Type "Person"?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-11374:
---------------------------------------
[~ev.srinivas] Looking at above magic script, I regret that I have asked :-) Before we dive into it could you double check that if start servers by my way usign standalone.sh and try to stop master using kill -15 and jboss-cli.sh and then start again then master does not announce as backup. Because both of the ways (kill -15, jboss-cli.sh) worked for me.
If it works for you as well then issue is in those scripts. If not then we can dive into those scripts.
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3385) Stateful session is not thread safe for update operation on JDK11
by Radovan Synek (Jira)
[ https://issues.jboss.org/browse/DROOLS-3385?page=com.atlassian.jira.plugi... ]
Radovan Synek updated DROOLS-3385:
----------------------------------
Description:
We have a test failure in multithreaded solving in OptaPlanner (please see the linked issue for details). Interestingly, it happens only with JDK11.
java.util.ConcurrentModificationException: null
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
at org.drools.core.impl.KnowledgeBaseImpl.getOrCreateExactTypeDeclaration(KnowledgeBaseImpl.java:1458)
at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:324)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1570)
at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:254)
was:
We have a test failure in multithreaded solving in OptaPlanner (please see the linked issue for details).
java.util.ConcurrentModificationException: null
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
at org.drools.core.impl.KnowledgeBaseImpl.getOrCreateExactTypeDeclaration(KnowledgeBaseImpl.java:1458)
at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:324)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1570)
at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:254)
> Stateful session is not thread safe for update operation on JDK11
> -----------------------------------------------------------------
>
> Key: DROOLS-3385
> URL: https://issues.jboss.org/browse/DROOLS-3385
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Reporter: Radovan Synek
> Assignee: Mario Fusco
> Priority: Critical
>
> We have a test failure in multithreaded solving in OptaPlanner (please see the linked issue for details). Interestingly, it happens only with JDK11.
> java.util.ConcurrentModificationException: null
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
> at org.drools.core.impl.KnowledgeBaseImpl.getOrCreateExactTypeDeclaration(KnowledgeBaseImpl.java:1458)
> at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:324)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1570)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:254)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months