[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1914:
--------------------------------
S3_PING2 is 168k, which is quite large. As commented on the PR, I suggest moving this to github.com/jgroups-extras. You could the actually add dependencies, making your code smaller. Documentation would also be there, and I'd link from the JGroups manual to it.
The jgroups-extras repo is used to host JGroups protocols that have dependencies, e.g. AZURE_PING, KUBE_PING etc.
Thoughts?
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1087) KieBase update wrong match for rules containing constraints over the accumulate
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1087?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1087.
-------------------------------
Resolution: Out of Date
We are about to drop support for reteoo and since the reported incremental compilation issue is only there this ticket is now obsolete.
> KieBase update wrong match for rules containing constraints over the accumulate
> -------------------------------------------------------------------------------
>
> Key: DROOLS-1087
> URL: https://issues.jboss.org/browse/DROOLS-1087
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final, 6.3.0.Final, 6.4.0.Beta2, 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20160309.DROOLS-1087.zip, 20160503.yetagain1087.zip
>
>
> Ciao, I will attach reproducer with same style as {{org.drools.compiler.integrationtests.IncrementalCompilationTest.testIncrementalCompilation}} / {{testIncrementalCompilationWithRedeclares}}
> h2. Executive summary
> When performing KieBase update, rules containing constraints over the accumulate Event, are firing with wrong matches and/or firing for already seen matches and violating the no-loop.
> h2. Detailed description of the reproducer.
> Assume a KB starting with only these two rules:
> {code}
> declare Measurement
> @role(event)
> end
> rule "color RED seen in the last 2 minutes"
> no-loop
> when
> accumulate ( $token: Measurement( id == "color", $colorVal : val, $colorVal == "red") over window:time(2m);
> $mySet : collectSet( $colorVal ),
> $val : count($token) ;
> $val >= 1
> )
> then
> System.out.println("I have seen color RED in the last 2m "+$mySet);
> end
> rule "color GREEN seen in the last 2 minutes"
> no-loop
> when
> accumulate ( $token: Measurement( id == "color", $colorVal : val, $colorVal == "green") over window:time(2m);
> $mySet : collectSet( $colorVal ),
> $val : count($token) ;
> $val >= 1
> )
> then
> System.out.println("I have seen color GREEN in the last 2m "+$mySet);
> end
> {code}
> and then on upgrade/update, the same rule as above un-touched, but additionally the following rule:
> {code}
> rule "id X seen in the last 2 minutes"
> no-loop
> when
> accumulate ( $token: Measurement( id == "x", $colorVal : val) over window:time(2m);
> $mySet : collectSet( $colorVal ),
> $val : count($token) ;
> $val >= 1
> )
> then
> System.out.println("I have seen Measurement for id=x in the last 2m "+$mySet);
> end
> {code}
> Where {{Measurement}} just a POJO as per Kie Artifact, basically containing fields: {{String id;String val;}}
> with the following of Measurement insertions, one at each minute:
> {code}
> -> Measurement [id=color, val=red]
> (KB update here)
> -> Measurement [id=x, val=x]
> -> Measurement [id=color, val=green]
> ...
> {code}
> the following problems are highlighted:
> h6. Drools version 6.2.0.Final with Reteoo
> The problem is highlighted after the 2nd Measurment event insertion below, the rules "color GREEN seen in the last 2 minutes" and "id X seen in the last 2 minutes" are firing with wrong matches, because:
> * the rule "color GREEN seen in the last 2 minutes" should fire only for {{Measurement\[id=color, val=green]}} Events, which has not occured, and is matching instead over {{Measurement\[id=color, val=red]}}
> * the rule "id X seen in the last 2 minutes" should fire only for {{Measurement\[id=x, _]}} Events, but is considering also the {{Measurement\[id=color, _]}} event which occured earlier.
> {code}
> 2016-03-09 09:33:20,952 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: MemoryKieModule[releaseId=org.test:test:1.0.0]
> 2016-03-09 09:33:21,240 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) There should be rules:
> 2016-03-09 09:33:21,240 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color RED seen in the last 2 minutes
> 2016-03-09 09:33:21,240 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color GREEN seen in the last 2 minutes
> 2016-03-09 09:33:21,240 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Creating kieSession
> 2016-03-09 09:33:21,319 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Now running data
> 2016-03-09 09:33:21,321 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 60000
> -> Measurement [id=color, val=red]
> I have seen color RED in the last 2m [red]
> 2016-03-09 09:33:21,539 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: MemoryKieModule[releaseId=org.test:test:1.0.1]
> 2016-03-09 09:33:21,743 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Update of KB performed.
> 2016-03-09 09:33:21,744 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color RED seen in the last 2 minutes
> 2016-03-09 09:33:21,744 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color GREEN seen in the last 2 minutes
> 2016-03-09 09:33:21,744 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule id X seen in the last 2 minutes
> 2016-03-09 09:33:21,744 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 120000
> -> Measurement [id=x, val=x]
> I have seen Measurement for id=x in the last 2m [red, x]
> I have seen color GREEN in the last 2m [red]
> I have seen color RED in the last 2m [red]
> 2016-03-09 09:33:21,750 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 180000
> <- Measurement [id=color, val=red]
> -> Measurement [id=color, val=green]
> I have seen color GREEN in the last 2m [green]
> I have seen Measurement for id=x in the last 2m [x]
> 2016-03-09 09:33:21,752 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 240000
> <- Measurement [id=x, val=x]
> -> Measurement [id=color, val=blue]
> 2016-03-09 09:33:21,752 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Final checks
> {code}
> h6. Drools version 6.2.0.Final with Phreak
> NPE
> {code}
> java.lang.NullPointerException
> at org.drools.core.reteoo.NodeTypeEnums.isBetaNode(NodeTypeEnums.java:87)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:252)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:92)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:1044)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:996)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1302)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1289)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1262)
> at com.acme.accumulateUpgradeTest.RuleTest.test(RuleTest.java:185)
> {code}
> h6. Drools version 6.3.0.Final with Reteoo
> Not in scope of this JIRA record. I think this release had a bug when running with the setup of this reproducer because if I try I get NPE at {{org.drools.core.RuleBaseConfiguration.configureReteComponentFactory()}}
> h6. Drools version 6.3.0.Final with Phreak
> Same NPE as "6.2.0.Final with Phreak"
> h6. Drools version 6.4.0.Beta2 with Reteoo
> Same problem as "6.2.0.Final with Reteoo"
> h6. Drools version 6.4.0.Beta2 with Phreak
> Better, but I'm not sure why rule "color RED seen in the last 2 minutes" is firing again after the rule-update, it is no-loop and the conditions of the rules are the same as before the rule-update, hence I'm not sure why it fired again.
> {code}
> 2016-03-09 09:45:25,301 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: MemoryKieModule[releaseId=org.test:test:1.0.0]
> 2016-03-09 09:45:25,594 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) There should be rules:
> 2016-03-09 09:45:25,594 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color RED seen in the last 2 minutes
> 2016-03-09 09:45:25,594 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color GREEN seen in the last 2 minutes
> 2016-03-09 09:45:25,594 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Creating kieSession
> 2016-03-09 09:45:25,696 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Now running data
> 2016-03-09 09:45:25,698 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 60000
> -> Measurement [id=color, val=red]
> I have seen color RED in the last 2m [red]
> 2016-03-09 09:45:25,854 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: MemoryKieModule[releaseId=org.test:test:1.0.1]
> 2016-03-09 09:45:26,023 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Update of KB performed.
> 2016-03-09 09:45:26,023 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color RED seen in the last 2 minutes
> 2016-03-09 09:45:26,023 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule color GREEN seen in the last 2 minutes
> 2016-03-09 09:45:26,023 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) kp [Package name=com.acme.accumulateUpgradeTest] rule id X seen in the last 2 minutes
> 2016-03-09 09:45:26,023 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 120000
> -> Measurement [id=x, val=x]
> I have seen color RED in the last 2m [red]
> I have seen Measurement for id=x in the last 2m [x]
> 2016-03-09 09:45:26,029 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 180000
> -> Measurement [id=color, val=green]
> <- Measurement [id=color, val=red]
> I have seen color GREEN in the last 2m [green]
> 2016-03-09 09:45:26,033 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) advance clock @ 240000
> -> Measurement [id=color, val=blue]
> <- Measurement [id=x, val=x]
> 2016-03-09 09:45:26,033 INFO [com.acme.accumulateUpgradeTest.RuleTest] (main) Final checks
> {code}
> h2. Final note.
> Please notice in the reproducer I've used {{setSourcePath}} to ".txt" because I'm aliging with the Drool's JUnit tests: https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test...
> However changing {{setSourcePath}} to ".drl" would NOT solve the problem, at least for the rule "id X seen in the last 2 minutes".
> Can you kindly advise, please?
> Thank you
> Ciao,
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ]
Radim Hatlapatka commented on WFCORE-1632:
------------------------------------------
The issue isn't with graceful shutdown as such, the issue is with server stopping. The server stopping hangs and waits for request processing to finish. If the server was doing some long time processing the only way to shut him down is by forcibly killing it instead of being just stopped in timely manner.
Note currently the processing which is done is completely pointless as there is no way to deliver the result in such case as the connection itself was destroyed. So there is done processing which is then thrown away.
> Server processing request isn't stopped immediately but waits for request processing to finish
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1632
> URL: https://issues.jboss.org/browse/WFCORE-1632
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, IO, Server
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such.
> After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...]
> Steps to reproduce:
> 1) start EAP server with deployed app from attachment
> 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}}
> 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}}
> See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-761:
------------------------------------------------
Lin Gao <lgao(a)redhat.com> changed the Status of [bug 1287732|https://bugzilla.redhat.com/show_bug.cgi?id=1287732] from POST to MODIFIED
> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
> Key: WFCORE-761
> URL: https://issues.jboss.org/browse/WFCORE-761
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
> Priority: Critical
> Labels: downstream_dependency
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
> Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
> should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-6200:
-------------------------------
Without the PR in this Jira merged, the {{connection_url}} is still required to be defined.
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6806) Failed to deploy war in EAP 7.0.0, error shows "Duplicate Filter registration for ..."
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6806?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-5160 to WFLY-6806:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6806 (was: JBEAP-5160)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.0.0.GA)
> Failed to deploy war in EAP 7.0.0, error shows "Duplicate Filter registration for ..."
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6806
> URL: https://issues.jboss.org/browse/WFLY-6806
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> When deployed attached "ugspa.war" into EAP 7.0.0 GA, error shows:
> ~~~
> 2016-06-23 08:53:11,036 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 76) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ugspa: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ugspa: java.lang.RuntimeException: java.lang.IllegalStateException: Duplicate Filter registration for 'multipartFilter'. Check to ensure the Filter is only configured once.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Duplicate Filter registration for 'multipartFilter'. Check to ensure the Filter is only configured once.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: Duplicate Filter registration for 'multipartFilter'. Check to ensure the Filter is only configured once.
> at org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer.registerFilter(AbstractSecurityWebApplicationInitializer.java:216)
> at org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer.registerFilters(AbstractSecurityWebApplicationInitializer.java:198)
> at org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer.insertFilters(AbstractSecurityWebApplicationInitializer.java:162)
> at sg.edu.nus.ugspa.config.security.SecurityWebApplicationInitializer.beforeSpringSecurityFilterChain(SecurityWebApplicationInitializer.java:11)
> at org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer.onStartup(AbstractSecurityWebApplicationInitializer.java:112)
> at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:175)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:184)
> ... 8 more
> ---And if deploy again---
> 2016-06-23 09:30:30,819 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 136) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ugspa: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ugspa: java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.NullPointerException
> at sg.edu.nus.ugspa.config.web.WebApplicationInitializer.onStartup(WebApplicationInitializer.java:43)
> at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:175)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:184)
> ... 8 more
> ~~~
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6742) javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6742?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6742:
--------------------------------------
This has been fixed in Undertow, it will be fixed in WF 10.1
> javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding
> ------------------------------------------------------------------
>
> Key: WFLY-6742
> URL: https://issues.jboss.org/browse/WFLY-6742
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: Ubuntu 16.04 LTS
> oracle java
> java version "1.8.0_91"
> Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
> Wildfly 8.2.0.Final
> Wildfly 10.0.0.Final
> Reporter: Maxim Wirt
> Assignee: Stuart Douglas
> Attachments: визитка.svg
>
>
> Servlet 3.1 file upload feature implementation uses incorrect character set for decoding file names
> request.getCharacterEncoding() returns "UTF-8",
> System property file.encoding is set to UTF-8, but
> javax.servlet.http.Part.getSubmittedFileName() returns file name encoded using Latin character set
> all non-latin symbols in name of the file become unreadably characters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6805) javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6805:
------------------------------------
Summary: javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding
Key: WFLY-6805
URL: https://issues.jboss.org/browse/WFLY-6805
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final, 10.0.0.Final
Environment: Ubuntu 16.04 LTS
oracle java
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Wildfly 8.2.0.Final
Wildfly 10.0.0.Final
Reporter: Maxim Wirt
Assignee: Stuart Douglas
Servlet 3.1 file upload feature implementation uses incorrect character set for decoding file names
request.getCharacterEncoding() returns "UTF-8",
System property file.encoding is set to UTF-8, but
javax.servlet.http.Part.getSubmittedFileName() returns file name encoded using Latin character set
all non-latin symbols in name of the file become unreadably characters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months