[JBoss JIRA] (DROOLS-3554) KieContainer#updateToVersion removing rules with accumulate
by Olga Rodionova (Jira)
Olga Rodionova created DROOLS-3554:
--------------------------------------
Summary: KieContainer#updateToVersion removing rules with accumulate
Key: DROOLS-3554
URL: https://issues.jboss.org/browse/DROOLS-3554
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.16.0.Final
Reporter: Olga Rodionova
Assignee: Mario Fusco
Attachments: RuleRemovalTest.java, SimpleRuleWithAccumulate.drl
Consider a rule with accumulate pattern in the LHS which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including this rule, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
Create a new KieModule excluding this rule from the KieFileSystem, update the KieContainer. Expect the logically inserted fact to be retracted, as the rule which trigged its creation is no longer present. Turns out that the fact is still present in the working memory
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-5321) Deploying a war to wildfly should mention the localhost url including context root of that war in the log
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-5321?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFLY-5321:
-----------------------------------
Is this still relevant? As Tomaz already mentioned - there is a log message with context present in the server.log. With {{WildFly 15.0.1.Final}}, I tried to deploy [helloworld app|https://github.com/wildfly/quickstart/tree/15.0.1.Final/helloworld] and I can see following messages in server.log during the app deployment:
{code}
11:57:28,761 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /home/jstourac/workspace/tests-wildfly-openssl/workspace/wildfly-15.0.0.Final/standalone/data/content/94/2f9afd71503e8ceec071eeafd821be218df569/content
11:57:28,764 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war")
11:57:28,896 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment helloworld.war
11:57:28,989 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-6) HV000001: Hibernate Validator 6.0.13.Final
11:57:29,215 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.0.5 (Final)
11:57:29,486 INFO [io.smallrye.metrics] (MSC service thread 1-4) MicroProfile: Metrics activated
11:57:30,310 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/helloworld' for server 'default-server'
11:57:30,318 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")
{code}
See this one particularly:
{code}
11:57:30,310 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/helloworld' for server 'default-server'
{code}
This message mentions context in which the app has been registered and also server where it has been deployed.
> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5321
> URL: https://issues.jboss.org/browse/WFLY-5321
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Reporter: Geoffrey De Smet
> Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications
by Tamás Ábele (Jira)
[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ]
Tamás Ábele commented on WFLY-11151:
------------------------------------
When I opened the issue and wrote about it, I did not identified the root cause.
But now we are planning to patch the wildfly server, so I have more information about it.
The elementNames stack which is used for HTML tag renaming seems to be part of the Passthru Elements implementation. The first problem with the implementation was the
"f:selectItems with value of type Map not working with HTML5 friendly Markup" issue
(https://github.com/javaserverfaces/mojarra/issues/3138)
It was solved with the followings:
* git log
!fix-1.png|thumbnail!
* git diff
!fix-1b.png|thumbnail!
Unfortunately this fix caused another problem. The issue is titled "Wrong ending tag when an "option" element is rendered after a pass-through element" and can be found: https://github.com/javaserverfaces/mojarra/issues/3727
It was solved with the followings:
* git log
!fix-2.png|thumbnail!
* git diff
!fix-2b.png|thumbnail!
With the modifications above a problem which affected just Passthru Elements, now became a more common problem. If an option element (rendered by a JSF component) is on the page with a JSF component which does not close HTML tags right, than the JSF runtime will MIX up things. Because we do not use Passthru Elements the problems started here and with wildfly 14.
I do not like the
{code:java}
if (original.equals("option"))
{code}
code in the HtmlResponseWriter class at all. The HtmlResponseWriter should not know that an option TAG name exists. It is wrong approach.
But it is very hard to fix things now in a right way, so in our environment we are planning a patch which will make wildfly 14 as stable as wildfly 10 and a little bit even more. For this we are planning to do the following:
1)First we do not start using the elementNames stack when an option tag found. We use it only when the renaming is necessary. So in the com.sun.faces.renderkit.html_basic.HtmlResponseWriter class instead of this:
{code:java}
if (original.equals("option")) {
if(elementNames == null) {
elementNames = new LinkedList<>();
}
elementNames.push(original);
return original;
}
{code}
we are planing to use this:
{code:java}
if (original.equals("option")) {
if( (elementNames != null) && (elementNames.size()>0) ) {
elementNames.push(original);
}
return original;
}
{code}
2)Secondly we do not want to use the elementNames stack after the tag was closed which needed the renaming. This will reduce the risk of an error. To do this we are planning to replace this:
{code:java}
if(!original.equals(name) || elementNames != null) {
if(elementNames == null) {
elementNames = new LinkedList<>();
}
elementNames.push(name);
}
{code}
with this:
{code:java}
if( (!original.equals(name)) || ( (elementNames!=null) && (elementNames.size()>0) ) ) {
if(elementNames == null) {
elementNames = new LinkedList<>();
}
elementNames.push(name);
}
{code}
> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
> Key: WFLY-11151
> URL: https://issues.jboss.org/browse/WFLY-11151
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Final
> Reporter: Tamás Ábele
> Assignee: Farah Juma
> Priority: Major
> Attachments: fix-1.png, fix-1b.png, fix-2.png, fix-2b.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10648) curly brackets {} not working in url
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-10648?page=com.atlassian.jira.plugin... ]
Jan Stourac edited comment on WFLY-10648 at 1/25/19 5:20 AM:
-------------------------------------------------------------
Note that this starts to work when you percent-encode the curly brackets, so you use:
{code}
http://localhost:8080?q=%7B%7D
{code}
on your locally running WildFly (checked with WildFly 15). Although, it looks like common browsers (Firefox, Chrome) don't encode these. Based on [RFC1738|https://tools.ietf.org/html/rfc1738#section-2.2], curly brackets are supposed to be 'unsafe' characters and as such percent-encoded always. Although the RFC1738 has been obsoleted by [RFC3986|https://tools.ietf.org/html/rfc3986] which does not specify in any way (or I didn't find it).
Note there is a workaround to allow unescaped characters in URL for your listener:
{code}
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
{code}
was (Author: jstourac):
Note that this starts to work when you percent-encode the curly brackets, so you use:
{code}
http://localhost:8080?q=%7B%7D
{code}
on your locally running WildFly (checked with WildFly 15). Although, it looks like common browsers (Firefox, Chrome) don't encode these. Based on [RFC1738|https://tools.ietf.org/html/rfc1738#section-2.2], curly brackets are supposed to be 'unsafe' characters and as such percent-encoded always. Although the RFC1738 has been obsoleted by [RFC3986|https://tools.ietf.org/html/rfc3986] which does not specify in any way.
Note there is a workaround to allow unescaped characters in URL for your listener:
{code}
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
{code}
> curly brackets {} not working in url
> ------------------------------------
>
> Key: WFLY-10648
> URL: https://issues.jboss.org/browse/WFLY-10648
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Final
> Reporter: Arun Kumar
> Assignee: Flavia Rainone
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications
by Tamás Ábele (Jira)
[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ]
Tamás Ábele updated WFLY-11151:
-------------------------------
Attachment: fix-2b.png
> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
> Key: WFLY-11151
> URL: https://issues.jboss.org/browse/WFLY-11151
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Final
> Reporter: Tamás Ábele
> Assignee: Farah Juma
> Priority: Major
> Attachments: fix-1.png, fix-1b.png, fix-2.png, fix-2b.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications
by Tamás Ábele (Jira)
[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ]
Tamás Ábele updated WFLY-11151:
-------------------------------
Attachment: fix-2.png
> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
> Key: WFLY-11151
> URL: https://issues.jboss.org/browse/WFLY-11151
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Final
> Reporter: Tamás Ábele
> Assignee: Farah Juma
> Priority: Major
> Attachments: fix-1.png, fix-1b.png, fix-2.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications
by Tamás Ábele (Jira)
[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ]
Tamás Ábele updated WFLY-11151:
-------------------------------
Attachment: fix-1b.png
> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
> Key: WFLY-11151
> URL: https://issues.jboss.org/browse/WFLY-11151
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Final
> Reporter: Tamás Ábele
> Assignee: Farah Juma
> Priority: Major
> Attachments: fix-1.png, fix-1b.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications
by Tamás Ábele (Jira)
[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ]
Tamás Ábele updated WFLY-11151:
-------------------------------
Attachment: fix-1.png
> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
> Key: WFLY-11151
> URL: https://issues.jboss.org/browse/WFLY-11151
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Final
> Reporter: Tamás Ábele
> Assignee: Farah Juma
> Priority: Major
> Attachments: fix-1.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months