March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6346) Undertow.js freemarker support broken due to class loading issues

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6346: ------------------------------------ Summary: Undertow.js freemarker support broken due to class loading issues Key: WFLY-6346 URL: https://issues.jboss.org/browse/WFLY-6346 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-164) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

Scott Marlow created JBEE-164: --------------------------------- Summary: org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) Key: JBEE-164 URL: https://issues.jboss.org/browse/JBEE-164 Project: JBoss JavaEE Spec APIs Issue Type: Bug Reporter: Scott Marlow Assignee: Scott Marlow Priority: Blocker Fix For: 1.0.6 Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-163?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated JBEE-163: ------------------------------ Fix Version/s: 1.0.6 > org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) > ------------------------------------------------------------------------------------------------- > > Key: JBEE-163 > URL: https://issues.jboss.org/browse/JBEE-163 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Fix For: 1.0.6 > > > Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). > To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-163?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on JBEE-163: ----------------------------------- pull request https://github.com/jboss/jboss-el-api_spec/pull/20 created > org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) > ------------------------------------------------------------------------------------------------- > > Key: JBEE-163 > URL: https://issues.jboss.org/browse/JBEE-163 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > > Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). > To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-163?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on JBEE-163: ----------------------------------- Closed https://github.com/jboss/jboss-el-api_spec/issues/19, so we can track this via JBEE-163. > org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) > ------------------------------------------------------------------------------------------------- > > Key: JBEE-163 > URL: https://issues.jboss.org/browse/JBEE-163 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > > Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). > To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-163?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated JBEE-163: ------------------------------ Description: Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) was: Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19. To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) > org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) > ------------------------------------------------------------------------------------------------- > > Key: JBEE-163 > URL: https://issues.jboss.org/browse/JBEE-163 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > > Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). > To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

Scott Marlow created JBEE-163: --------------------------------- Summary: org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) Key: JBEE-163 URL: https://issues.jboss.org/browse/JBEE-163 Project: JBoss JavaEE Spec APIs Issue Type: Bug Reporter: Scott Marlow Assignee: Scott Marlow Priority: Blocker Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19. To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1317) Log jndi-name in console log to identify datasource with wrong credentials if security-domain is used

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1317?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1317: ----------------------------------- Issue Type: Task (was: Enhancement) Fix Version/s: WildFly/IronJacamar 1.3.4.Final 1.0.37.Final 1.2.8.Final Priority: Minor (was: Major) > Log jndi-name in console log to identify datasource with wrong credentials if security-domain is used > ----------------------------------------------------------------------------------------------------- > > Key: JBJCA-1317 > URL: https://issues.jboss.org/browse/JBJCA-1317 > Project: IronJacamar > Issue Type: Task > Components: Core, Deployer > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Minor > Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6342) Transactional CDI event from JPA callback

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6342?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6342: ------------------------------------ >From a weld-dev IRC conversation on this: {quote} <smarlow> Should weld register the synchronixation associated with javax.enterprise.event.TransactionPhase.BEFORE_COMPLETION via TransactionSynchronizationRegistry? https://issues.jboss.org/browse/WFLY-6342 reports that Weld is using Transaction.registerSynchronization() currently which fails, since the active thread is beyond the point when non-interposed synchronization.beforeCompletion can be called <jbossbot> jira [WFLY-6342] Transactional CDI event from JPA callback [Open (Unresolved) Feature Request, Major, Stuart Douglas] https://issues.jboss.org/browse/WFLY-6342 <mkouba> smarlow: hi <smarlow> hi mkouba <mkouba> yes, for transactional observer methods weld is using JTA Synchronization - this is per the spec <mkouba> see also http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#observer_notification <jbossbot> Title: Contexts and Dependency Injection for the Java EE platform * smarlow looking <mkouba> "...for each observer method, either invoke the observer method immediately, or register the observer method for later invocation during the transaction completion phase, using a JTA Synchronization." <smarlow> interesting, so for the use case mentioned in the jira, the only expected solution is using TransactionPhase.IN_PROGRESS, since JPA and other components are supposed to use the TSR <smarlow> I think the switch from using Transaction to TSR happened around EE 5 for jpa <mkouba> smarlow: did you mean "are not supposed to use TSR"? <smarlow> well, more for EJB maybe {quote} > Transactional CDI event from JPA callback > ----------------------------------------- > > Key: WFLY-6342 > URL: https://issues.jboss.org/browse/WFLY-6342 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Giovanni Lovato > Assignee: Stuart Douglas > > Sending transactional CDI events from an JPA callback during a managed flush throws {{IllegalStateException (ARJUNA016082)}} in Wildfly 8.2.0.Final. > The following Arquillian test project on GitHub: [https://github.com/wrungel/bugs/tree/master/tx-observer-test] shows the error. > The JPA Listener (CDI Event sender): > {code} > public class UpdateListener { > @PreUpdate > public void callback(Object object) { > if (object instanceof FooEntity) { > getBeanManager().fireEvent(object); > } > } > } > {code} > CDI event observer: > {code} > public class UpdateObserver { > public void BEFORE_COMPLETION(@Observes(during = TransactionPhase.BEFORE_COMPLETION) FooEntity foo) { > ... > } > } > {code} > Transactional service: > {code} > @Transactional > public class FooService { > @PersistenceContext(unitName = "default") > EntityManager em; > public void managedFlush() { > // change entity property: > em.find(FooEntity.class, ID).setName(UUID.randomUUID().toString()); > } > } > {code} > Calling {{managedFlush()}} causes the following error: > {code} > WARN [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffac136c07:4115d5ad:553685a6:11, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@458cbc17 >: > javax.persistence.PersistenceException: error during managed flush > at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1887) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:119) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:50) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:358) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1166) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:147) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:93) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20] > at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:124) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:102) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at frol.txobserver.FooService$Proxy$_$$_WeldSubclass.managedFlush(Unknown Source) [f4da9dfa-ba67-446a-abe8-e5172fa8d5f3.jar:] > at frol.txobserver.TxObserverTest.error_during_managed_flush(TxObserverTest.java:44) [f4da9dfa-ba67-446a-abe8-e5172fa8d5f3.jar > ... > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING > at org.jboss.as.weld.services.bootstrap.WeldTransactionServices.registerSynchronization(WeldTransactionServices.java:85) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.weld.event.TransactionalObserverNotifier.deferNotification(TransactionalObserverNotifier.java:67) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:48) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:124) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:117) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:673) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at org.jboss.weld.util.ForwardingBeanManager.fireEvent(ForwardingBeanManager.java:101) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at frol.txobserver.UpdateListener.callback(UpdateListener.java:36) [f4da9dfa-ba67-446a-abe8-e5172fa8d5f3.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20] > at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20] > at org.hibernate.jpa.event.internal.jpa.ListenerCallback.performCallback(ListenerCallback.java:49) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.event.internal.jpa.CallbackRegistryImpl.callback(CallbackRegistryImpl.java:112) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.event.internal.jpa.CallbackRegistryImpl.preUpdate(CallbackRegistryImpl.java:76) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.event.internal.core.JpaFlushEntityEventListener.invokeInterceptor(JpaFlushEntityEventListener.java:67) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:342) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:293) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:160) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:231) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:102) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:55) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:114) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > ... 160 more > Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:375) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:352) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at org.jboss.as.weld.services.bootstrap.WeldTransactionServices.registerSynchronization(WeldTransactionServices.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] > ... 184 more > {code} > Some possibly interesting observations: > Non transactional CDI event observer {{(@Observes(during = TransactionPhase.IN_PROGRESS) ...)}} works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6340) Adding deployment permissions doesn't put server in requires reload state

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6340?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6340: ----------------------------------- Priority: Blocker (was: Major) > Adding deployment permissions doesn't put server in requires reload state > ------------------------------------------------------------------------- > > Key: WFLY-6340 > URL: https://issues.jboss.org/browse/WFLY-6340 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 10.0.0.Alpha4 > Reporter: Josef Cacek > Assignee: Kabir Khan > Priority: Blocker > Fix For: 10.1.0.Final > > > When adding permissions in the security-manager subsystem, the changes are not used until server reload. But the CLI operation *doesn't require reload*. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016