[JBoss JIRA] (WFLY-10212) Deploying of jms bridge requires a lot of mandatory parameters
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-10212?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet reassigned WFLY-10212:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Deploying of jms bridge requires a lot of mandatory parameters
> --------------------------------------------------------------
>
> Key: WFLY-10212
> URL: https://issues.jboss.org/browse/WFLY-10212
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Erich Duda
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> As you can see in the listing \[1\], deploying of jms bridge requires a lot of mandatory parameters such as: {{max-batch-size}}, {{max-batch-time}}, {{max-retries}}, {{failure-retry-interval}}.
> These parameters should not be mandatory and should use some reasonable defaults.
> \[1\]
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/jms-bridge=mybridge:add(
> ! max-batch-size* quality-of-service* source-credential-reference subscription-name target-destination*
> add-messageID-in-header max-batch-time* selector source-destination* target-connection-factory* target-password
> client-id max-retries* source-connection-factory* source-password target-context target-user
> failure-retry-interval* module source-context source-user target-credential-reference
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11476) [GSS](7.2.z) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-11476:
-----------------------------------
Summary: [GSS](7.2.z) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
Key: WFLY-11476
URL: https://issues.jboss.org/browse/WFLY-11476
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 14.0.0.Beta2
Reporter: Brad Maxwell
Assignee: Bartosz Baranowski
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, 5 months
[JBoss JIRA] (DROOLS-3395) [DMN Designer] Two copies of node are created
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3395?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3395:
----------------------------------------
[~jomarko] Could you please re-confirm this issue (still?) exists.
I tried with the current {{master}} and only single copies were made.
Is it possible the keyboard navigation interferes with copy/paste (and you was using your branch)?
> [DMN Designer] Two copies of node are created
> ---------------------------------------------
>
> Key: DROOLS-3395
> URL: https://issues.jboss.org/browse/DROOLS-3395
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Spotted during DROOLS-3371 review, however it is probably not related.
> If user copies diagram node by CTRL+C and CTRL+V it results two copies of the given node are created.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11474) Make activemq dependency on cli module optional
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11474?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet reassigned WFLY-11474:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Make activemq dependency on cli module optional
> -----------------------------------------------
>
> Key: WFLY-11474
> URL: https://issues.jboss.org/browse/WFLY-11474
> Project: WildFly
> Issue Type: Task
> Components: JMS
> Reporter: Jean-Francois Denise
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> Dependency on org.jboss.as.cli from org.wildfly.extension.messaging-activemq should be made optional.
> At runtime, the commands are not loaded on the server side. They are loaded thanks to ServiceLoader from CLI, so if CLI is present, the commands are in use, otherwise they are un-used.
> We would observe a gain of 2.3+MB in filesystem footprint when a server without CLI is provisioned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3393:
-------------------------------------
[~bdellasc] Personally I'm concerned the icon might be too visually disruptive, and am hoping that the colors sufficiently passing the color tests might be enough?
> Please review scenario error cell text for legibility/accessibility.
> ---------------------------------------------------------------------
>
> Key: DROOLS-3393
> URL: https://issues.jboss.org/browse/DROOLS-3393
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Klara Kufova
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png
>
>
> [~kkufova] [~bdellasc]
> I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded.
> I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes.
> I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible.
> Just wanted to ask about this, please let me know what you think.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months