July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9109) The jdbc-job-repository does not properly register the org.wildfly.batch.job.repository

by James Perkins (JIRA)

James Perkins created WFLY-9109: ----------------------------------- Summary: The jdbc-job-repository does not properly register the org.wildfly.batch.job.repository Key: WFLY-9109 URL: https://issues.jboss.org/browse/WFLY-9109 Project: WildFly Issue Type: Bug Components: Batch Reporter: James Perkins Assignee: James Perkins The {{jdbc-job-repository}} should be registering the {{org.wildfly.batch.job.repository}} capability. The {{in-memory-job-repository}} may not remove the capability correctly either. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9108) The jdbc-job-repository does not properly register the org.wildfly.batch.job.repository

by James Perkins (JIRA)

James Perkins created WFLY-9108: ----------------------------------- Summary: The jdbc-job-repository does not properly register the org.wildfly.batch.job.repository Key: WFLY-9108 URL: https://issues.jboss.org/browse/WFLY-9108 Project: WildFly Issue Type: Bug Components: Batch Reporter: James Perkins Assignee: James Perkins The {{jdbc-job-repository}} should be registering the {{org.wildfly.batch.job.repository}} capability. The {{in-memory-job-repository}} may not remove the capability correctly either. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ELY-1292) XmlConfigurationTest.testCertificateInCredentials hangs on IBM JDK

by Peter Palaga (JIRA)

Peter Palaga created ELY-1292: --------------------------------- Summary: XmlConfigurationTest.testCertificateInCredentials hangs on IBM JDK Key: ELY-1292 URL: https://issues.jboss.org/browse/ELY-1292 Project: WildFly Elytron Issue Type: Bug Reporter: Peter Palaga Assignee: Darran Lofthouse {{XmlConfigurationTest.testCertificateInCredentials}} does not terminate on IBM JDK. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9107) Block non-SSL IIOP port when SSL transport is required

by Tomasz Adamski (JIRA)

Tomasz Adamski created WFLY-9107: ------------------------------------ Summary: Block non-SSL IIOP port when SSL transport is required Key: WFLY-9107 URL: https://issues.jboss.org/browse/WFLY-9107 Project: WildFly Issue Type: Enhancement Reporter: Tomasz Adamski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2017