[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1993 at 1/11/16 12:11 PM:
----------------------------------------------------------
You mean use {{==}} rather than {{equals()}}? I'm probably misreading you...
was (Author: belaban):
You mean use {{==}} rather than {{equals()}}?
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5973) org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5973?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-5973.
-----------------------------
Fix Version/s: 10.0.0.CR1
Assignee: Tomaz Cerar (was: Stuart Douglas)
Resolution: Out of Date
This was fixed in 10. we rebased jastow to latest jasper from upstream.
If you can reproduce this also with WildFly 10 builds please reopen this
> org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5973
> URL: https://issues.jboss.org/browse/WFLY-5973
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final
> Reporter: Loc Ha
> Assignee: Tomaz Cerar
> Priority: Critical
> Fix For: 10.0.0.CR1
>
>
> -- Create any JSTL Simple tag (SimpleTagSupport) that having body is scriptless
> -- Create a JSP using the Simple tag
> -- Request the JSP multi time
> -- Using visualvm 1.3.8 to monitor the allocations of org.apache.jasper.runtime.BodyContentImpl --> You will see a lot of instance of BodyContentImpl created
> -- Click on Perform GC on VisualVM --> The remainging BodyContentImpl didn't go down to ZERO ---> Leaking memory
> -- Did the same test using Glashfish 4 --> When click on Perform GC --> BodyContentImpl went down to Zero --> No leaking memory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1993:
--------------------------------
You mean use {{==}} rather than {{equals()}}?
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5973) org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
by Loc Ha (JIRA)
Loc Ha created WFLY-5973:
----------------------------
Summary: org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
Key: WFLY-5973
URL: https://issues.jboss.org/browse/WFLY-5973
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 9.0.2.Final
Reporter: Loc Ha
Assignee: Stuart Douglas
Priority: Critical
-- Create any JSTL Simple tag (SimpleTagSupport) that having body is scriptless
-- Create a JSP using the Simple tag
-- Request the JSP multi time
-- Using visualvm 1.3.8 to monitor the allocations of org.apache.jasper.runtime.BodyContentImpl --> You will see a lot of instance of BodyContentImpl created
-- Click on Perform GC on VisualVM --> The remainging BodyContentImpl didn't go down to ZERO ---> Leaking memory
-- Did the same test using Glashfish 4 --> When click on Perform GC --> BodyContentImpl went down to Zero --> No leaking memory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1952) Compatibility between blocking and non-blocking TCP
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1952?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1952:
--------------------------------
OK, so now we can have protocol stacks with {{TCP}} and {{TCP_NIO2}} that communicate with each other. One required change was to add an entry for {{TP}} to {{jg-protocols.xml}}.
> Compatibility between blocking and non-blocking TCP
> ---------------------------------------------------
>
> Key: JGRP-1952
> URL: https://issues.jboss.org/browse/JGRP-1952
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> * Blocking RouterStubs can talk to a non-blocking GossipRouter, and vice versa
> * Ditto for {{PubServer}} and {{PubClient}}
> * Investigate whether this would also work for {{TCP}} and {{TCP_NIO2}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5519) Some clustering tests fails with security manager
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5519?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5519:
--------------------------------------
One more marshalling aggregate issue, see JBMAR-180.
> Some clustering tests fails with security manager
> -------------------------------------------------
>
> Key: WFLY-5519
> URL: https://issues.jboss.org/browse/WFLY-5519
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Marek Kopecký
> Assignee: Radoslav Husar
> Attachments: clustering.secman.zip
>
>
> *Description of problem:*
> Some clustering tests fails with security manager. Affected testcases:
> {noformat}org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase(SYNC-tcp).testGracefulSimpleFailover
> org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).failoverOnStop
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).connectionFactoryFailover
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).jmsConnectionFactoryFailover
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).noFailover
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).simpleFailover
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout
> org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testBasicXPC
> org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testSecondLevelCache
> org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.singleton.SingletonServiceTestCase(SYNC-tcp).testSingletonService
> org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase(SYNC-tcp).testFormAuthSingleSignOn
> org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testSerialized
> org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testSessionReplication
> org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testGracefulServeOnUndeploy
> org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testGracefulServeOnShutdown
> org.jboss.as.test.clustering.cluster.web.ExternalizerTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.ReplicationForNegotiationAuthenticatorTestCase(SYNC-tcp).testOneRequestSimpleFailover
> org.jboss.as.test.clustering.cluster.web.async.AsyncServletTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.context.InvalidateConversationTestCase(SYNC-tcp).testInvalidate
> org.jboss.as.test.clustering.cluster.web.expiration.CoarseSessionExpirationTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.expiration.FineSessionExpirationTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.passivation.CoarseSessionPassivationTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.passivation.FineSessionPassivationTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.cluster.web.shared.SharedSessionFailoverTestCase(SYNC-tcp).test
> org.jboss.as.test.clustering.single.registry.RegistryTestCase.org.jboss.as.test.clustering.single.registry.RegistryTestCase
> org.jboss.as.test.clustering.single.singleton.SingletonServiceTestCase.org.jboss.as.test.clustering.single.singleton.SingletonServiceTestCase{noformat}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Djboss.dist=$JBOSS_DIST -Dsecurity.manager -Dts.clustering -Dts.noSmoke
> *Actual results:*
> See attached logs
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5957) Unable to disable CN Check in "wildfly-8.2.0.Final"
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-5957?page=com.atlassian.jira.plugin.... ]
Alessio Soldano resolved WFLY-5957.
-----------------------------------
Resolution: Rejected
The cxf.tls-client.disableCNCheck property has been introduced in JBossWS 5 series which is installed by default in WildFly 9.
WildFly 8.2.0.Final includes JBossWS 4.3.2.Final, on which you're supposed to set the org.jboss.security.ignoreHttpsHost property for achieving the same.
> Unable to disable CN Check in "wildfly-8.2.0.Final"
> ---------------------------------------------------
>
> Key: WFLY-5957
> URL: https://issues.jboss.org/browse/WFLY-5957
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Karthikeyan Ramasamy
> Assignee: Alessio Soldano
>
> My application is working in wildfly-8.2.0.Final.
> This application needs to access a web service that allows only SSL connections.
> On posting request to webservice got "Marshalling Error: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true." exception.
> So i want to disable CN Check
> Tried with system properties.
> <system-properties>
> <property name="cxf.tls-client.disableCNCheck" value="true"/>
> </system-properties>.
> But the same is not working.
> Please help us to to disable this common name check on wildfly 8.2?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5652) Datasource spy attribute has no effect
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-5652?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on WFLY-5652:
------------------------------------
IMO this issue should be re-opened until the documentation in the wildfly_datasources XSDs is fixed, so they tell people the right logging category to enable.
> Datasource spy attribute has no effect
> --------------------------------------
>
> Key: WFLY-5652
> URL: https://issues.jboss.org/browse/WFLY-5652
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR2
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> The spy attribute of a datasource does not appear to have any effect. The datasources XSD says to set spy to true and enable the org.jboss.jdbc log category, but I did that and got no debug info in my log. From a quick search of the WildFly and IronJacamar codebases, it looks like no meaningful code ever checks the value of the spy attribute.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months