December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-366) Add support for grouping to Infinispan subsystem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-366?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-366: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Add support for grouping to Infinispan subsystem > ------------------------------------------------ > > Key: WFLY-366 > URL: https://issues.jboss.org/browse/WFLY-366 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > Enable setting of groups in Infinispan subsystem. More information about grouping can be found at https://docs.jboss.org/author/display/ISPN/The+Grouping+API. > It should be possible to enable it as well as set a grouper class. The following is respective configuration for standalone Infinispan. > {code:xml} > <clustering> > <hash> > <groups enabled="true"> > <grouper class="com.acme.KXGrouper" /> > </groups> > </hash> > </clustering> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-375) Add support to specify ciphers available with Remoting

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-375?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-375: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Add support to specify ciphers available with Remoting > ------------------------------------------------------ > > Key: WFLY-375 > URL: https://issues.jboss.org/browse/WFLY-375 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-84) Jasper using wrong ProtectionDomain for compiled JSP

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-84: ----------------------------- Fix Version/s: 8.0.0.Final > Jasper using wrong ProtectionDomain for compiled JSP > ---------------------------------------------------- > > Key: WFLY-84 > URL: https://issues.jboss.org/browse/WFLY-84 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment. I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated. This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-377) Provide "destroy-queue" and "destroy-topic" operations to CLI

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-377: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Provide "destroy-queue" and "destroy-topic" operations to CLI > ------------------------------------------------------------- > > Key: WFLY-377 > URL: https://issues.jboss.org/browse/WFLY-377 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CLI, JMS > Reporter: Miroslav Novak > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions. > They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic. > The goal is to provide a simple way how to get rid of those objects to administrators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-89) Spurious server dirs created when directory-grouping="by-type" is set

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-89?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-89: ----------------------------- Fix Version/s: 8.0.0.Final > Spurious server dirs created when directory-grouping="by-type" is set > --------------------------------------------------------------------- > > Key: WFLY-89 > URL: https://issues.jboss.org/browse/WFLY-89 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Add directory-grouping="by-type" to the <host><servers> element in the stock host.xml and run domain.sh. The following empty directories are created: > $JBOSS_HOME/domain/servers/server-one > $JBOSS_HOME/domain/servers/server-two > The content that would normally be in those dirs if directory-grouping="by-type" wasn't set appears to all be going where it should (e.g. under domain/data, domain/log etc) so the only issue here is the empty directories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-122) Clean unreferenced deployments from the content repository

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-122?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-122: ------------------------------ Fix Version/s: 8.0.0.Final > Clean unreferenced deployments from the content repository > ---------------------------------------------------------- > > Key: WFLY-122 > URL: https://issues.jboss.org/browse/WFLY-122 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 8.0.0.CR1, 8.0.0.Final > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-378) Provide ability to detect server shutdown

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-378?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-378: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Provide ability to detect server shutdown > ----------------------------------------- > > Key: WFLY-378 > URL: https://issues.jboss.org/browse/WFLY-378 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > Fix For: 8.0.0.Final > > > The general use case is that a subsystem maintains state (on behalf of a deployment) that should be removed on explicit user interaction (i.e. mgmt op) but not on subsystem/server shutdown. This should also work in the domain case. Perhaps the ApplicationServerService (or similar) could be queried about whether it is currently shutting down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR operation in testsuite run

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-91: ----------------------------- Fix Version/s: 8.0.0.Final > Impossible to use "reload" MDR operation in testsuite run > --------------------------------------------------------- > > Key: WFLY-91 > URL: https://issues.jboss.org/browse/WFLY-91 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Vladimir Rastseluev > Assignee: Alexey Loubyansky > Fix For: 8.0.0.CR1, 8.0.0.Final > > Attachments: AS7-4185-failure.txt > > > Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). > Test successfully pass, when runs alone. > If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception: > org.jboss.remoting3.NotOpenException: Writes closed > at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296) > at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177) > at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298) > at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-131) Seam2Processor will not have permissions to its added resource loader

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-131: ------------------------------ Fix Version/s: 8.0.0.Final > Seam2Processor will not have permissions to its added resource loader > --------------------------------------------------------------------- > > Key: WFLY-131 > URL: https://issues.jboss.org/browse/WFLY-131 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: David Lloyd > Assignee: Ales Justin > Labels: security > Fix For: 8.0.0.CR1, 8.0.0.Final > > > The {{Seam2Processor}} class adds a {{VFSResourceLoader}} to the deployment in order to copy certain Seam classes into it. The problem is that the {{VFSResourceLoader}} will fail at runtime with a permission exception because there is no corresponding {{VirtualFilePermission}}. > For this type of resource loader, it is better just to add the JAR using {{JarFileResourceLoader}}, which does not require permissions at load time and is much faster anyway. > If you must use {{VFSResourceLoader}}, then instead of creating and adding the resource loader yourself, add a {{ResourceRoot}} to the deployment context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-379) Fix & re-enable ignored security tests

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-379?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-379: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Fix & re-enable ignored security tests > -------------------------------------- > > Key: WFLY-379 > URL: https://issues.jboss.org/browse/WFLY-379 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Alpha1 > Environment: AS8 with undertow > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > AS8 with undertow fails few security tests. > This issue is here just for tracking what they are so they can be fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 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 December 2013