[JBoss JIRA] (DROOLS-2446) [GSS] (6.4.z) Concurrent spreadsheet table validation doesn't work properly
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2446?page=com.atlassian.jira.plugi... ]
Toni Rikkola moved RHBRMS-3091 to DROOLS-2446:
----------------------------------------------
Project: Drools (was: JBoss BRMS Platform)
Key: DROOLS-2446 (was: RHBRMS-3091)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: build
(was: Business Central)
Affects Build: (was: RC1)
Affects Version/s: 7.6.0.Final
(was: 6.4.9)
QE Status: NEW
> [GSS] (6.4.z) Concurrent spreadsheet table validation doesn't work properly
> ---------------------------------------------------------------------------
>
> Key: DROOLS-2446
> URL: https://issues.jboss.org/browse/DROOLS-2446
> Project: Drools
> Issue Type: Bug
> Components: build
> Affects Versions: 7.6.0.Final
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Labels: support
>
> Assume this scenarios
> # A
> ## Create a project (say, 'proj1') and upload a spreadsheet (8000rows-spreadsheet.xls)
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the spreadsheet (8000rows-spreadsheet.xls) and user2 validates the same spreadsheet (8000rows-spreadsheet.xls)
> ## empty-validation-error.png reproduced
> # B
> ## Upload another spreadsheet (8000rows-spreadsheet2.xls) to the same project 'proj1'
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) and user2 validates the second spreadsheet (8000rows-spreadsheet2.xls)
> ## empty-validation-error.png reproduced
> # C
> ## Upload another spreadsheet (8000rows-spreadsheet3.xls) to another project (say, 'proj2')
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) in 'proj1' and user2 validates the third spreadsheet (8000rows-spreadsheet3.xls) in 'proj2'
> ## *Doesn't reproduce the empty-validation-error.png*
> So, I guess we need to limit to only one validation per project (= GAV) at the same time. It should be limited at backend service.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2446) Concurrent spreadsheet table validation doesn't work properly
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2446?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-2446:
---------------------------------
Summary: Concurrent spreadsheet table validation doesn't work properly (was: [GSS] (6.4.z) Concurrent spreadsheet table validation doesn't work properly)
> Concurrent spreadsheet table validation doesn't work properly
> -------------------------------------------------------------
>
> Key: DROOLS-2446
> URL: https://issues.jboss.org/browse/DROOLS-2446
> Project: Drools
> Issue Type: Bug
> Components: build
> Affects Versions: 7.6.0.Final
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Labels: support
>
> Assume this scenarios
> # A
> ## Create a project (say, 'proj1') and upload a spreadsheet (8000rows-spreadsheet.xls)
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the spreadsheet (8000rows-spreadsheet.xls) and user2 validates the same spreadsheet (8000rows-spreadsheet.xls)
> ## empty-validation-error.png reproduced
> # B
> ## Upload another spreadsheet (8000rows-spreadsheet2.xls) to the same project 'proj1'
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) and user2 validates the second spreadsheet (8000rows-spreadsheet2.xls)
> ## empty-validation-error.png reproduced
> # C
> ## Upload another spreadsheet (8000rows-spreadsheet3.xls) to another project (say, 'proj2')
> ## Login as user1 with browser1
> ## Login as user2 with browser2
> ## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) in 'proj1' and user2 validates the third spreadsheet (8000rows-spreadsheet3.xls) in 'proj2'
> ## *Doesn't reproduce the empty-validation-error.png*
> So, I guess we need to limit to only one validation per project (= GAV) at the same time. It should be limited at backend service.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10169) bin/client/jboss-cli-client.jar contains some useless aesh classes
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-10169?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFLY-10169:
--------------------------------------
cc: [~stalep]
> bin/client/jboss-cli-client.jar contains some useless aesh classes
> ------------------------------------------------------------------
>
> Key: WFLY-10169
> URL: https://issues.jboss.org/browse/WFLY-10169
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
>
> bin/client/jboss-cli-client.jar contains some useless aesh classes.
> jboss-cli-client.jar should contains only necessary classes. This jar file should not be unnecessarily too large.
> {noformat}
> ./examples
> ./examples/Example$FooCommand.class
> ./examples/Example$BlueBoldRenderer.class
> ./examples/Example$LongOutputCommand.class
> ./examples/AeshGraphicsExample.class
> ./examples/Example$ClearCommand.class
> ./examples/Example$BarActivator.class
> ./examples/Example$TestConsoleCommand.class
> ./examples/AeshGraphicsExample$ExitCommand.class
> ./examples/AeshGraphicsExample$GraphicsCommand.class
> ./examples/Example$HiddenCommand.class
> ./examples/Example$DirectoryValidatorInvocation.class
> ./examples/SimpleExample.class
> ./examples/Example$ExampleValidatorInvocationProvider.class
> ./examples/Example$Base.class
> ./examples/Example$LessCompleter.class
> ./examples/Example$ExitCommand.class
> ./examples/Example$HideActivator.class
> ./examples/SimpleExample$ExitCommand.class
> ./examples/Example$LsCommand.class
> ./examples/Example$RunCommand.class
> ./examples/Example$Rebase.class
> ./examples/Example$DirectoryValidator.class
> ./examples/Example$ManProviderExample.class
> ./examples/Example.class
> ./examples/Example$GroupCommand.class
> ./examples/Example$PromptCommand.class
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10169) bin/client/jboss-cli-client.jar contains some useless aesh classes
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-10169:
------------------------------------
Summary: bin/client/jboss-cli-client.jar contains some useless aesh classes
Key: WFLY-10169
URL: https://issues.jboss.org/browse/WFLY-10169
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: Marek Kopecký
Assignee: Jean-Francois Denise
bin/client/jboss-cli-client.jar contains some useless aesh classes.
jboss-cli-client.jar should contains only necessary classes. This jar file should not be unnecessarily too large.
{noformat}
./examples
./examples/Example$FooCommand.class
./examples/Example$BlueBoldRenderer.class
./examples/Example$LongOutputCommand.class
./examples/AeshGraphicsExample.class
./examples/Example$ClearCommand.class
./examples/Example$BarActivator.class
./examples/Example$TestConsoleCommand.class
./examples/AeshGraphicsExample$ExitCommand.class
./examples/AeshGraphicsExample$GraphicsCommand.class
./examples/Example$HiddenCommand.class
./examples/Example$DirectoryValidatorInvocation.class
./examples/SimpleExample.class
./examples/Example$ExampleValidatorInvocationProvider.class
./examples/Example$Base.class
./examples/Example$LessCompleter.class
./examples/Example$ExitCommand.class
./examples/Example$HideActivator.class
./examples/SimpleExample$ExitCommand.class
./examples/Example$LsCommand.class
./examples/Example$RunCommand.class
./examples/Example$Rebase.class
./examples/Example$DirectoryValidator.class
./examples/Example$ManProviderExample.class
./examples/Example.class
./examples/Example$GroupCommand.class
./examples/Example$PromptCommand.class
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-113) Allocate OpenShift and Jenkins resources for testing Jaeger productized images
by Kevin Earls (JIRA)
[ https://issues.jboss.org/browse/SWSQE-113?page=com.atlassian.jira.plugin.... ]
Kevin Earls commented on SWSQE-113:
-----------------------------------
Hi [~gbaufake] and [~fbrychta]. I've created the "jaeger-test" project on b11 for this, but I need a couple of modifications in order to be able to deploy ElasticSearch correctly. These are:
1. oc adm policy add-role-to-user admin system:serviceaccount:jaeger-test:jenkins
2. I'm not sure exactly how to do this, as my notes apply to minishift. These were: "minishift ssh 'echo "sysctl -w vm.max_map_count=262144" | sudo tee -a /var/lib/boot2docker/bootlocal.sh'". Obviously we aren't running minishift here, but I need the same changes applied. Unfortunately I think this may require a cluster restart.
> Allocate OpenShift and Jenkins resources for testing Jaeger productized images
> ------------------------------------------------------------------------------
>
> Key: SWSQE-113
> URL: https://issues.jboss.org/browse/SWSQE-113
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Kevin Earls
> Assignee: Filip Brychta
>
> I need internal Jenkins and OpenShift resources for https://issues.jboss.org/browse/KIALI-336 which covers testing productized Jaeger images. I have already started working with [~fbrychta] but we have not completely resolved this yet.
> I can work with either of these two options
> -- A project on an OpenShift Cluster where I can create my own Jenkins instance.
> -- An external Jenkins which has an agent defined which can run on OpenShift.
> I'm not completely sure if the second solution will work, as when I run tests I will need to have access to ports that are not externally accessible. In that case I'd be happy to use the first solution.
> Finally, this will just be for smoke and possibly simple functional tests, so I won't need high levels of resources.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10167) [GSS](7.1.z) Upgrade Xerces so that DocumentBuilder can pase an emoji properly
by Osamu Nagano (JIRA)
Osamu Nagano created WFLY-10167:
-----------------------------------
Summary: [GSS](7.1.z) Upgrade Xerces so that DocumentBuilder can pase an emoji properly
Key: WFLY-10167
URL: https://issues.jboss.org/browse/WFLY-10167
Project: WildFly
Issue Type: Bug
Components: XML Frameworks
Affects Versions: 12.0.0.Final
Reporter: Osamu Nagano
Assignee: Jason Greene
Attachments: testapp.zip, testappng.war
An smiley face emoji, decimal code 😁, can be parsed properly by JDK's implementation (loaded by {{com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl}}) but failed with WildFly's implementation (xercesImpl-2.11.0.SP5.jar) which throws {{org.xml.sax.SAXParseException}}.
{code}
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 84; Character reference "�" is an invalid XML character.
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:245)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
at com.example.XMLTest.main(XMLTest.java:77)
at com.example.XMLServlet.doRequest(XMLServlet.java:65)
at com.example.XMLServlet.doGet(XMLServlet.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This means a standalone Java application suddenly stops working on WildFly and need to be addressed. There is a workaround using files under {{META-INF/services}} and {{jboss-deployment-structure.xml}}. But the workaround is too mysterious for most of users. An out-of-the-box solution is expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10166) Upgrade Xerces so that DocumentBuilder can pase an emoji properly
by Osamu Nagano (JIRA)
Osamu Nagano created WFLY-10166:
-----------------------------------
Summary: Upgrade Xerces so that DocumentBuilder can pase an emoji properly
Key: WFLY-10166
URL: https://issues.jboss.org/browse/WFLY-10166
Project: WildFly
Issue Type: Bug
Components: XML Frameworks
Affects Versions: 12.0.0.Final
Reporter: Osamu Nagano
Assignee: Jason Greene
Attachments: testapp.zip, testappng.war
An smiley face emoji, decimal code 😁, can be parsed properly by JDK's implementation (loaded by {{com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl}}) but failed with WildFly's implementation (xercesImpl-2.11.0.SP5.jar) which throws {{org.xml.sax.SAXParseException}}.
{code}
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 84; Character reference "�" is an invalid XML character.
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:245)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
at com.example.XMLTest.main(XMLTest.java:77)
at com.example.XMLServlet.doRequest(XMLServlet.java:65)
at com.example.XMLServlet.doGet(XMLServlet.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This means a standalone Java application suddenly stops working on WildFly and need to be addressed. There is a workaround using files under {{META-INF/services}} and {{jboss-deployment-structure.xml}}. But the workaround is too mysterious for most of users. An out-of-the-box solution is expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10166) Upgrade Xerces so that DocumentBuilder can pase an emoji properly
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10166?page=com.atlassian.jira.plugin... ]
Osamu Nagano updated WFLY-10166:
--------------------------------
Attachment: testapp.zip
testappng.war
> Upgrade Xerces so that DocumentBuilder can pase an emoji properly
> -----------------------------------------------------------------
>
> Key: WFLY-10166
> URL: https://issues.jboss.org/browse/WFLY-10166
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 12.0.0.Final
> Reporter: Osamu Nagano
> Assignee: Jason Greene
> Attachments: testapp.zip, testappng.war
>
>
> An smiley face emoji, decimal code 😁, can be parsed properly by JDK's implementation (loaded by {{com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl}}) but failed with WildFly's implementation (xercesImpl-2.11.0.SP5.jar) which throws {{org.xml.sax.SAXParseException}}.
> {code}
> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 84; Character reference "�" is an invalid XML character.
> at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:245)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
> at com.example.XMLTest.main(XMLTest.java:77)
> at com.example.XMLServlet.doRequest(XMLServlet.java:65)
> at com.example.XMLServlet.doGet(XMLServlet.java:38)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This means a standalone Java application suddenly stops working on WildFly and need to be addressed. There is a workaround using files under {{META-INF/services}} and {{jboss-deployment-structure.xml}}. But the workaround is too mysterious for most of users. An out-of-the-box solution is expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month