July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5038) Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include immutable classes introduced in Java 8

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5038?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5038: ------------------------------- Summary: Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include immutable classes introduced in Java 8 (was: Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include new immutable classes Java 8) > Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include immutable classes introduced in Java 8 > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5038 > URL: https://issues.jboss.org/browse/WFLY-5038 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Alpha6 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5038) Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include new immutable classes Java 8

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5038: ---------------------------------- Summary: Update org.wildfly.clustering.web.infinispan.session.MutableDetector to include new immutable classes Java 8 Key: WFLY-5038 URL: https://issues.jboss.org/browse/WFLY-5038 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.0.0.Alpha6 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-846) Some tests throws "Permission check failed" while run with security manager

by Hynek Mlnařík (JIRA)

[ https://issues.jboss.org/browse/WFCORE-846?page=com.atlassian.jira.plugin... ] Hynek Mlnařík reassigned WFCORE-846: ------------------------------------ Assignee: Jan Tymel (was: Josef Cacek) > Some tests throws "Permission check failed" while run with security manager > --------------------------------------------------------------------------- > > Key: WFCORE-846 > URL: https://issues.jboss.org/browse/WFCORE-846 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.Alpha11 > Reporter: Petr Kremensky > Assignee: Jan Tymel > > Some tests are failing to deploy an archive when testsuite run with security manager enabled. > {noformat} > 08:03:07,171 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service test.deployment.trivial: org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.trivial.prop" "write")" in code source "(vfs:/content/test-http-deployment.sar <no signer certificates>)" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:274) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:176) > at java.lang.System.setProperty(System.java:792) > at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:80) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 08:03:07,173 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-5) WFLYCTL0013: Operation ("add") failed - address: ([{"deployment" => "test-http-deployment.sar"}]) - failure description: {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar <no signer certificates>)\" of \"null\")"}} > 08:03:07,174 ERROR [org.jboss.as.server] (XNIO-1 task-5) WFLYSRV0021: Deploy of deployment "test-http-deployment.sar" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar <no signer certificates>)\" of \"null\")"}} > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4464) JDBC driver module-slot is not persisted in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4464?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4464: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1213642|https://bugzilla.redhat.com/show_bug.cgi?id=1213642] from ON_QA to VERIFIED > JDBC driver module-slot is not persisted in domain mode > ------------------------------------------------------- > > Key: WFLY-4464 > URL: https://issues.jboss.org/browse/WFLY-4464 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.2.0.Final > Reporter: Lin Gao > Assignee: Lin Gao > Fix For: 9.0.0.CR1 > > > The module-slot of jdbc-driver is NOT persisted in domain mode, but it is persisted in standalone mode. > After debugging, I found that the performRuntime() method of JdbcDriverAdd.java is not called in domain mode, but is called in standalone mode. > For more information about the issue, please refer to the thread: https://developer.jboss.org/thread/253654 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-775) domain mode - server fails to start intermittently

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-775?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-775: ------------------------------------------------ Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1245751|https://bugzilla.redhat.com/show_bug.cgi?id=1245751] from ON_QA to VERIFIED > domain mode - server fails to start intermittently > -------------------------------------------------- > > Key: WFCORE-775 > URL: https://issues.jboss.org/browse/WFCORE-775 > Project: WildFly Core > Issue Type: Bug > Environment: EAP 6.4.0 > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 2.0.0.Alpha11 > > > Server instances occasionally fail in domain mode using EAP 6.4.0. It appears to be due to the hashes being exchanged between the server instance and host controller. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-865) ClearAgendaGroup should materialize all activations and then cancel them

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-865: ---------------------------------- Summary: ClearAgendaGroup should materialize all activations and then cancel them Key: DROOLS-865 URL: https://issues.jboss.org/browse/DROOLS-865 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco ClearAgendaGroup has to flush the propagation queue in a blocking way, This will materialize all rule matches so that they can be all cancelled. Once this will be implemented also this PR https://github.com/droolsjbpm/drools/pull/464 needs to be merged. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-183) Protocols for password changing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-183: -------------------------------------- The problem with that is that the password change may be happening due to the existing password being compromised. > Protocols for password changing > ------------------------------- > > Key: ELY-183 > URL: https://issues.jboss.org/browse/ELY-183 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.0.0.Final > > > Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-) > A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options. > Are there any existing protocols to remotely set a password securely? > Is there anything specific to our current password types we can take advantage of? > Are there features of any of our SASL mechanisms to apply a second layer of confidentiality? > Any other options? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-183) Protocols for password changing

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-183: -------------------------------- Only idea: send new password encrypted with old password (or its hash) > Protocols for password changing > ------------------------------- > > Key: ELY-183 > URL: https://issues.jboss.org/browse/ELY-183 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.0.0.Final > > > Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-) > A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options. > Are there any existing protocols to remotely set a password securely? > Is there anything specific to our current password types we can take advantage of? > Are there features of any of our SASL mechanisms to apply a second layer of confidentiality? > Any other options? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4048) Make sure predicated handlers (like handler-info.conf) can be used at a server level

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4048?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4048: ----------------------------------- No, this is about adding support to subsystem configuration. > Make sure predicated handlers (like handler-info.conf) can be used at a server level > ------------------------------------------------------------------------------------ > > Key: WFLY-4048 > URL: https://issues.jboss.org/browse/WFLY-4048 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 10.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-841) Patching module testsuite failure

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ] Alexey Loubyansky commented on WFCORE-841: ------------------------------------------ Given the async nature of the new Aesh, your guess of the output being late is worth investigating. That would mean other tests could be affected too. [~brian.stansberry] have you seen this failure only in this test? And on this line? > Patching module testsuite failure > --------------------------------- > > Key: WFCORE-841 > URL: https://issues.jboss.org/browse/WFCORE-841 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > OS X Yosemite 10.10.4 > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Alpha12 > > > When running the core build locally , the 'patching' module testsuite fails: > {code} > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined. > Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase > Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase > Running org.jboss.as.patching.cli.PatchInspectUnitTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase > testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE! > java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}> > 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:144) > at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76) > at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57) > at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180) > {code} > If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order. > Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround. > The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 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 2015