[JBoss JIRA] (ELY-1293) System.currentTimeMillis() cannot be mocked on IBM JDK
by Peter Palaga (JIRA)
Peter Palaga created ELY-1293:
---------------------------------
Summary: System.currentTimeMillis() cannot be mocked on IBM JDK
Key: ELY-1293
URL: https://issues.jboss.org/browse/ELY-1293
Project: WildFly Elytron
Issue Type: Bug
Reporter: Peter Palaga
Assignee: Darran Lofthouse
{{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
{code}
JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test
{code}
Expected: the tests mocking {{System.currentTimeMillis()}} should pass
Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
{code}
java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
This is the case with
* PeriodicRotatingFileAuditEndpointTest
* SizeRotatingFileAuditEndpointTest
* GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3077) Operation removing http-connector requires full server reload but does not change the server state accordingly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3077?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3077:
------------------------------------------
This one is odd. I can see a problem here, in that RemotingHttpUpgradeService.stop does this:
injectedRegistry.getValue().removeProtocol(JBOSS_REMOTING);
That will remove all upgrade handling for JBOSS_REMOTING, not just the handling added in the service instance's start() method. That's a problem if you have >1 http-connector for the same undertow listener, which seems to be what the test in question sets up (standard config has http-connector=http-remoting-connector and test adds http-connector=ejb3-tests, both with the same connector-ref.)
So I would expect not doing a reload to break things because removing http-connector=ejb3-tests results in http-connector=http-remoting-connector no longer working until reload happens. But I don't see how it would result in http upgrade continuing to work until the reload happens.
I'm not sure how the test setup with two http-connectors on the same undertow listener functions properly in the test anyway, since my reading of ChannelUpgradeHandler tells me it will always pick the one registered by the first RemotingHttpUpgradeService to add the protocol, since all such registrations will use an equivalent SimpleHttpUpgradeHandshake.
> Operation removing http-connector requires full server reload but does not change the server state accordingly
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3077
> URL: https://issues.jboss.org/browse/WFCORE-3077
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Michal Jurc
> Assignee: David Lloyd
>
> Removing a {{http-connector}} with {{allow-resource-service-restart}} set to {{true}} will yield the following result:
> {code}{
> "operation" => "remove",
> "address" => [
> ("subsystem" => "remoting"),
> ("http-connector" => "ejb3-tests")
> ],
> "operation-headers" => {"allow-resource-service-restart" => true}
> }
> {"outcome" => "success"}{code}
> However, the removal of {{http-connector}} will only register after full server reload.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.sy... ]
Peter Palaga commented on ELY-477:
----------------------------------
[~olukas] this one can probably be closed. There is no {{testWrongRuleOrder()}} in {{XmlConfigurationTest}} anymore. The only issue in {{XmlConfigurationTest}} on IBM JDK is the hanging {{testCertificateInCredentials}} that is tracked in ELY-1292.
> XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
> ----------------------------------------------------------
>
> Key: ELY-477
> URL: https://issues.jboss.org/browse/ELY-477
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.1.0.Beta4
> Reporter: Ondrej Lukas
> Fix For: 1.2.0.Beta1
>
>
> Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with:
> {code}
> expected:<-1> but was:<7>
> and stacktrace:
> java.lang.AssertionError: expected:<-1> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96)
> ...
> {code}
> It is caused by undefined line number of XML parsing failure for IBM JDK.
> Stacktrace of checked XMLStreamException for IBM JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException:
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> at authentication-client.xml:
> at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
> ...
> {code}
> Stacktrace of checked XMLStreamException for Oracle JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException:
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> at authentication-client.xml:7:39:
> at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3077) Operation removing http-connector requires full server reload but does not change the server state accordingly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3077?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-8821 to WFCORE-3077:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3077 (was: WFLY-8821)
Component/s: Remoting
(was: Remoting)
> Operation removing http-connector requires full server reload but does not change the server state accordingly
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3077
> URL: https://issues.jboss.org/browse/WFCORE-3077
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Michal Jurc
> Assignee: David Lloyd
>
> Removing a {{http-connector}} with {{allow-resource-service-restart}} set to {{true}} will yield the following result:
> {code}{
> "operation" => "remove",
> "address" => [
> ("subsystem" => "remoting"),
> ("http-connector" => "ejb3-tests")
> ],
> "operation-headers" => {"allow-resource-service-restart" => true}
> }
> {"outcome" => "success"}{code}
> However, the removal of {{http-connector}} will only register after full server reload.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-478) Some tests fail with AttachNotSupportedException for IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-478?page=com.atlassian.jira.plugin.sy... ]
Peter Palaga commented on ELY-478:
----------------------------------
Yes, I can confirm that the stack traces ATM appearing on IBM JDK resemble the one from ELY-534 rather than the one reported here. This issue can be closed.
> Some tests fail with AttachNotSupportedException for IBM JDK
> ------------------------------------------------------------
>
> Key: ELY-478
> URL: https://issues.jboss.org/browse/ELY-478
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta4
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Some tests fail with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded on IBM JDK
> Stack trace of exception:
> {code}
> java.lang.ExceptionInInitializerError
> at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
> at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:88)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
> at mockit.internal.startup.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:82)
> at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:47)
> at mockit.internal.startup.AgentInitialization.loadAgentFromLocalJarFile(AgentInitialization.java:27)
> at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:208)
> at mockit.integration.junit4.JMockit.<clinit>(JMockit.java:21)
> ... 17 more
> Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
> at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
> at mockit.internal.startup.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:72)
> ... 21 more
> {code}
> This is probably only test issue.
> Affected tests:
> org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest
> org.wildfly.security.sasl.digest.CompatibilityClientTest
> org.wildfly.security.sasl.digest.CompatibilityServerTest
> org.wildfly.security.sasl.entity.EntityTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest
> org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest
> org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest
> org.wildfly.security.sasl.otp.OTPTest
> org.wildfly.security.sasl.scram.ScramClientCompatibilityTest
> org.wildfly.security.sasl.scram.ScramServerCompatibilityTest
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3076) Handle to audit.log is being held until next GC
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3076?page=com.atlassian.jira.plugi... ]
Jan Kalina moved JBEAP-12229 to WFCORE-3076:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3076 (was: JBEAP-12229)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.0.Beta28
(was: 7.1.0.ER2)
> Handle to audit.log is being held until next GC
> -----------------------------------------------
>
> Key: WFCORE-3076
> URL: https://issues.jboss.org/browse/WFCORE-3076
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta28
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> There is an issue with elytron audit.log handle being open until next GC cycle.
> We hit it in installer testing (JBEAP-1404) so the usecase is rather specific. Installer first starts an embedded server via CLI wrapper, do some configuration, stop the embeded server and then tries to delete newly created files from previous procedure (like all log files) - all running in the same JVM. The problem is the deletion step intermittently fails on Windows (it won't let you delete a file with open handle, unlike Linux) but the handle would be open in any OS. Intermittently because it depends on GC activity.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> {{mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=AuditLogFileLockingTestCase}}
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server in given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months