[JBoss JIRA] (WFLY-8368) InterDeploymentDependenciesEarTestCase may fail with NoSuchEJBException
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-8368?page=com.atlassian.jira.plugin.... ]
Petr Kremensky moved JBEAP-9582 to WFLY-8368:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8368 (was: JBEAP-9582)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Test Suite
(was: EJB)
(was: Test Suite)
Affects Version/s: (was: 7.1.0.DR13)
> InterDeploymentDependenciesEarTestCase may fail with NoSuchEJBException
> -----------------------------------------------------------------------
>
> Key: WFLY-8368
> URL: https://issues.jboss.org/browse/WFLY-8368
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Minor
>
> org.jboss.as.test.integration.deployment.dependencies.ear.InterDeploymentDependenciesEarTestCase is expects to catch ISE in case that one of dependent deployments is not available
> {code:java}
> deployer.undeploy(DEP_APP1);
> try {
> helloApp2.getLog();
> fail("Calling EJB from dependent application should fail");
> } catch (IllegalStateException e) {
> //OK
> }
> {code}
> ISE stack trace
> {noformat}
> java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "app2/hello/LogAccessBean", view is interface org.jboss.as.test.integration.deployment.dependencies.ear.LogAccess, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:708)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:690)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:150)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy22.getLog(Unknown Source)
> at org.jboss.as.test.integration.deployment.dependencies.ear.InterDeploymentDependenciesEarTestCase.test(InterDeploymentDependenciesEarTestCase.java:142)
> {noformat}
> But in [our CI jobs|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-as-t...], test intermittently fails with NoSuchEJBException
> {noformat}
> javax.ejb.NoSuchEJBException: No such EJB: app2/hello/LogAccessBean
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:354)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:75)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:357)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:609)
> at org.jboss.ejb.client.EJBInvocationHandler.lambda$invoke$0(EJBInvocationHandler.java:164)
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:429)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:388)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:150)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy65.getLog(Unknown Source)
> at org.jboss.as.test.integration.deployment.dependencies.ear.InterDeploymentDependenciesEarTestCase.test(InterDeploymentDependenciesEarTestCase.java:142)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1476) Decision Tables (CSV) - Treat empty cells right from ObjectType declaration as merged
by Martin Cimbalek (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1476?page=com.atlassian.jira.plugi... ]
Martin Cimbalek updated DROOLS-1476:
------------------------------------
Description:
Because of CSV doesn't support merging cells like in .xls or .xlsx, saving decision table as .csv currently requires additional binding and matching instead of merging cells, which causes the merged columns are merged into one set of constraints.
Proposing that empty cells right from ObjectType definition in CSV would be treated as the merged ones in .xls. This approach may be applicable also for .xls
was:
Because of CSV doesn't support merging cells like in .xls(x), saving decision table as .csv currently requires additional binding and matching instead of merging cells, which causes the merged columns are merged into one set of constraints.
Proposing that empty cells right from ObjectType definition in CSV would be treated as the merged ones in .xls. This approach may be applicable also for .xls
> Decision Tables (CSV) - Treat empty cells right from ObjectType declaration as merged
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1476
> URL: https://issues.jboss.org/browse/DROOLS-1476
> Project: Drools
> Issue Type: Enhancement
> Components: decision tables
> Affects Versions: 7.0.0.Beta7
> Reporter: Martin Cimbalek
> Assignee: Mario Fusco
> Priority: Minor
>
> Because of CSV doesn't support merging cells like in .xls or .xlsx, saving decision table as .csv currently requires additional binding and matching instead of merging cells, which causes the merged columns are merged into one set of constraints.
> Proposing that empty cells right from ObjectType definition in CSV would be treated as the merged ones in .xls. This approach may be applicable also for .xls
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1476) Decision Tables (CSV) - Treat empty cells right from ObjectType declaration as merged
by Martin Cimbalek (JIRA)
Martin Cimbalek created DROOLS-1476:
---------------------------------------
Summary: Decision Tables (CSV) - Treat empty cells right from ObjectType declaration as merged
Key: DROOLS-1476
URL: https://issues.jboss.org/browse/DROOLS-1476
Project: Drools
Issue Type: Enhancement
Components: decision tables
Affects Versions: 7.0.0.Beta7
Reporter: Martin Cimbalek
Assignee: Mario Fusco
Priority: Minor
Because of CSV doesn't support merging cells like in .xls(x), saving decision table as .csv currently requires additional binding and matching instead of merging cells, which causes the merged columns are merged into one set of constraints.
Proposing that empty cells right from ObjectType definition in CSV would be treated as the merged ones in .xls. This approach may be applicable also for .xls
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
by Mario García García (JIRA)
[ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.... ]
Mario García García edited comment on WFLY-8358 at 3/15/17 3:25 AM:
--------------------------------------------------------------------
I forgot to mention that the same code works fine in jboss-as-7.1.1.Final. I mean the parameter arrives to HttpServletRequest as it was sent and it can be saw and traced with the 'ó' character.
By the way, I tried to attach the source code but JIRA didn't allow me. I am trying again attaching the code to this comment.
[^MiServlet.java]
[^index.jsp]
was (Author: mario2004):
I forgot to mention that the same code works fine in jboss-as-7.1.1.Final.
By the way, I tried to attach the source code but JIRA didn't allow me. I am trying again attaching the code to this comment.
[^MiServlet.java]
[^index.jsp]
> Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8358
> URL: https://issues.jboss.org/browse/WFLY-8358
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop
> Reporter: Mario García García
> Assignee: Jason Greene
> Attachments: MiServlet.java, index.jsp
>
>
> Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'.
> This is the String that is sent into a parameter:
> "Código"
> No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8').
> The received parameter in HttpServletRequest (doPost method) is showed like this:
> "C??digo".
> In Hex this is the content:
> 43 3f3f 6469676f (spaces added for better reading pourposes)
> This is no UTF-8. The proper encoding should be:
> 43 c3b3 6469676f (spaces added for better reading pourposes)
> Wildfly Configuration:
> Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP
> Default encoding: (empty)
> Java encoding: UTF8
> Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP
> Url charset: UTF-8
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
by Mario García García (JIRA)
[ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.... ]
Mario García García commented on WFLY-8358:
-------------------------------------------
I forgot to mention that the same code works fine in jboss-as-7.1.1.Final.
By the way, I tried to attach the source code but JIRA didn't allow me. I am trying again attaching the code to this comment.
[^MiServlet.java]
[^index.jsp]
> Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8358
> URL: https://issues.jboss.org/browse/WFLY-8358
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop
> Reporter: Mario García García
> Assignee: Jason Greene
> Attachments: MiServlet.java, index.jsp
>
>
> Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'.
> This is the String that is sent into a parameter:
> "Código"
> No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8').
> The received parameter in HttpServletRequest (doPost method) is showed like this:
> "C??digo".
> In Hex this is the content:
> 43 3f3f 6469676f (spaces added for better reading pourposes)
> This is no UTF-8. The proper encoding should be:
> 43 c3b3 6469676f (spaces added for better reading pourposes)
> Wildfly Configuration:
> Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP
> Default encoding: (empty)
> Java encoding: UTF8
> Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP
> Url charset: UTF-8
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
by Mario García García (JIRA)
[ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.... ]
Mario García García updated WFLY-8358:
--------------------------------------
Attachment: MiServlet.java
> Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8358
> URL: https://issues.jboss.org/browse/WFLY-8358
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop
> Reporter: Mario García García
> Assignee: Jason Greene
> Attachments: MiServlet.java, index.jsp
>
>
> Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'.
> This is the String that is sent into a parameter:
> "Código"
> No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8').
> The received parameter in HttpServletRequest (doPost method) is showed like this:
> "C??digo".
> In Hex this is the content:
> 43 3f3f 6469676f (spaces added for better reading pourposes)
> This is no UTF-8. The proper encoding should be:
> 43 c3b3 6469676f (spaces added for better reading pourposes)
> Wildfly Configuration:
> Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP
> Default encoding: (empty)
> Java encoding: UTF8
> Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP
> Url charset: UTF-8
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
by Mario García García (JIRA)
[ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.... ]
Mario García García updated WFLY-8358:
--------------------------------------
Attachment: index.jsp
> Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8358
> URL: https://issues.jboss.org/browse/WFLY-8358
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop
> Reporter: Mario García García
> Assignee: Jason Greene
> Attachments: MiServlet.java, index.jsp
>
>
> Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'.
> This is the String that is sent into a parameter:
> "Código"
> No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8').
> The received parameter in HttpServletRequest (doPost method) is showed like this:
> "C??digo".
> In Hex this is the content:
> 43 3f3f 6469676f (spaces added for better reading pourposes)
> This is no UTF-8. The proper encoding should be:
> 43 c3b3 6469676f (spaces added for better reading pourposes)
> Wildfly Configuration:
> Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP
> Default encoding: (empty)
> Java encoding: UTF8
> Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP
> Url charset: UTF-8
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2182) RuntimeVaultReader should not throw SecurityException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2182?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-2182:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1410583
Bugzilla Update: Perform
> RuntimeVaultReader should not throw SecurityException
> -----------------------------------------------------
>
> Key: WFCORE-2182
> URL: https://issues.jboss.org/browse/WFCORE-2182
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha20
>
>
> RuntimeVaultReader is throwing SecurityException if it catches a SecurityVaultException from PicketBoxSecurityVault. But the causes of those SecurityVaultException are not really security breaches, they just reflect failed searches, or, less likely, incorrect vault setup.
> Converting these into SecurityException, which is a RuntimeException, means the vault lookup will fail the management op that triggered it in a way that overrides rollback-on-runtime-failure=false. But at least in the case of failed searches, this is no different than any other failed attempt to resolve an expression and should be treated as such.
> Perhaps the type of the getCause() value from the SecurityVaultException can be used to discriminate behavior between failed searches and other issues, or perhaps the distinction can be ignored.
> Here is an example of a failed search using EAP 6:
> {code}
> 12:46:34,830 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 27) JBAS014612: Operation ("enable") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "xyzDS")
> ]): java.lang.SecurityException: JBAS013311: Security Exception
> at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:115)
> at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45)
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionString(ExpressionResolverImpl.java:319) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.parseAndResolve(ExpressionResolverImpl.java:228) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionStringRecursively(ExpressionResolverImpl.java:130) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:72) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:54) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:782) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:1002) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ParallelBootOperationContext.resolveExpressions(ParallelBootOperationContext.java:351) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition$1.resolveExpressions(AttributeDefinition.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveValue(AttributeDefinition.java:402) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:361) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:335) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.connector.util.ModelNodeUtil.getResolvedStringIfSetOrGetDefault(ModelNodeUtil.java:33)
> at org.jboss.as.connector.subsystems.datasources.DataSourceModelNodeUtil.from(DataSourceModelNodeUtil.java:151)
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:183)
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:102)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:708) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:543) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.IllegalArgumentException: Null input buffer
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:297)
> at org.jboss.as.security.vault.RuntimeVaultReader.getValue(RuntimeVaultReader.java:141)
> at org.jboss.as.security.vault.RuntimeVaultReader.getValueAsString(RuntimeVaultReader.java:123)
> at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:113)
> ... 26 more
> Caused by: java.lang.IllegalArgumentException: Null input buffer
> at javax.crypto.Cipher.doFinal(Cipher.java:2161) [jce.jar:1.8.0_111]
> at org.picketbox.util.EncryptionUtil.decrypt(EncryptionUtil.java:134)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:293)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month