[JBoss JIRA] (WFLY-6135) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
Scott Marlow created WFLY-6135:
----------------------------------
Summary: Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
Key: WFLY-6135
URL: https://issues.jboss.org/browse/WFLY-6135
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 9.0.2.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Priority: Minor
Fix For: 10.1.0.Final
SPEC: If a component is called and the JTA transaction is propagated into that component:
If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6127:
-------------------------------
Fix Version/s: 10.1.0.Final
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Minor
> Fix For: 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ]
Artur Kronenberg edited comment on DROOLS-1030 at 2/5/16 12:51 PM:
-------------------------------------------------------------------
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are inserted on session level. For example, I had to restructure my rules to not use entrypoints so that these facts could also expire programatically.
Hope that helps
UPDATE: not actually working because a fact is not reevaluated. My new workaround:
The timer task inserts a new ExpiryFact each time it runs. That way there's a new fact that must be evaluated. The fact caries an expiryTimestamp that i can then compare with the expiry field on my other facts.
was (Author: pandaadb):
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are inserted on session level. For example, I had to restructure my rules to not use entrypoints so that these facts could also expire programatically.
Hope that helps
> Nullpointer in JpaTimerJobInstance.call on startup
> ---------------------------------------------------
>
> Key: DROOLS-1030
> URL: https://issues.jboss.org/browse/DROOLS-1030
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
> Attachments: test-standalone.zip
>
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition:
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation.
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug?
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
* DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
* DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * DONE: MessageDispatcher: remove MessageListener
> * DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> ** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
> * DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1605.
----------------------------
Resolution: Done
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * DONE: MessageDispatcher: remove MessageListener
> * DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> ** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
> * DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1620) RpcDispatcher/MessageDispatcher changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1620?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1620:
---------------------------
Summary: RpcDispatcher/MessageDispatcher changes (was: MessageDispatcher changes)
> RpcDispatcher/MessageDispatcher changes
> ---------------------------------------
>
> Key: JGRP-1620
> URL: https://issues.jboss.org/browse/JGRP-1620
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
> ** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
> * Return null from castMessage() if the call is async, instead of a null {{RspList}}
> * Investigate whether non-blocking RPCs need to create Request instances at all
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1620) RpcDispatcher/MessageDispatcher changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1620?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1620:
---------------------------
Description:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Return null from castMessage() if the call is async, instead of a null {{RspList}}
* Investigate whether non-blocking RPCs need to create Request instances at all
* Return a {{CompletableFuture}} instead of a {{NotifyingFuture}}
was:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Return null from castMessage() if the call is async, instead of a null {{RspList}}
* Investigate whether non-blocking RPCs need to create Request instances at all
> RpcDispatcher/MessageDispatcher changes
> ---------------------------------------
>
> Key: JGRP-1620
> URL: https://issues.jboss.org/browse/JGRP-1620
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
> ** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
> * Return null from castMessage() if the call is async, instead of a null {{RspList}}
> * Investigate whether non-blocking RPCs need to create Request instances at all
> * Return a {{CompletableFuture}} instead of a {{NotifyingFuture}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
* DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * DONE: MessageDispatcher: remove MessageListener
> * DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> ** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to T
> * DONE: {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6131) Cannot reconfigure standard paths
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6131?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-6131.
-------------------------------
Release Notes Text:
you can override them by passing system property to startup script.
if you try to do it in the paths section it is already too late as server is already booting.
Resolution: Rejected
> Cannot reconfigure standard paths
> ---------------------------------
>
> Key: WFLY-6131
> URL: https://issues.jboss.org/browse/WFLY-6131
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jason Greene
>
> The [WildFly 10 Admin Guide|https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide...] says that it should be possible to change the location of various directories that WildFly uses. Specifically, it states that
> {quote}
> WildFly automatically provides a number of standard paths without any need for the user to configure them in a configuration file:
> jboss.home.dir - the root directory of the WildFly distribution
> user.home - user's home directory
> user.dir - user's current working directory
> java.home - java installation directory
> jboss.server.base.dir - root directory for an individual server instance
> jboss.server.config.dir - directory the server will use for configuration file storage
> jboss.server.data.dir - directory the server will use for persistent data file storage
> jboss.server.log.dir - directory the server will use for log file storage
> jboss.server.temp.dir - directory the server will use for temporary file storage
> jboss.controller.temp.dir - directory the server will use for temporary file storage
> jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances (managed domain mode only)
> Users can add their own paths or override all except the first 5 of the above by adding a <path/> element to their configuration file.
> {quote}
> I tried setting jboss.server.data.dir as described and got the following error:
> {noformat}
> 17:49:53,753 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[50,9]
> Message: WFLYCTL0173: jboss.server.data.dir is reserved
> at org.jboss.as.server.parsing.PathsXml.parsePath(PathsXml.java:131) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.PathsXml.parsePaths(PathsXml.java:105) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.CommonXml.parsePaths(CommonXml.java:185) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:227) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
> ... 3 more
> {noformat}
> Indeed, examining the source for PathsXml reveals that almost all of the paths listed in the documentation (not just the first 5) are considered restricted and cannot be changed. I'm not sure if this is actually a bug or if the documentation is just wrong. If the former, this issue belongs in WFCORE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months