[JBoss JIRA] (WFLY-5011) OutdatedTopologyException: Cache not running on node <node_name>
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5011?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5011:
------------------------------------
I've filed an upstream issue w/Infinispan: ISPN-6007
> OutdatedTopologyException: Cache not running on node <node_name>
> ----------------------------------------------------------------
>
> Key: WFLY-5011
> URL: https://issues.jboss.org/browse/WFLY-5011
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.CR3
>
>
> Seen in our HTTP-based failover tests (no matter what failover type: jvmkill/shutdown/undeploy), with *distributed* cache used.
> Does not occur when replicated cache is used.
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf18 for example, perf19,20,21 log the following error message many times (seems like one error per each session)
> {code}
> [JBossINF] [0m[31m05:48:40,646 ERROR [io.undertow.request] (default task-110) UT005023: Exception handling request to /clusterbench/session: org.infinispan.statetransfer.OutdatedTopologyException: Cache not running on node perf18
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.checkTxCommandResponses(TxDistributionInterceptor.java:274)
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitLockControlCommand(TxDistributionInterceptor.java:186)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireRemoteIfNeeded(PessimisticLockingInterceptor.java:238)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:66)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:318)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:364)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:349)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:232)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:116)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1178) Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1178?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1178:
-------------------------------------------
No as if the specific description is not found then it should go back to the previous behaviour.
The only change is the key in the exception message if neither the 'new' one nor the old one is found.
> Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1178
> URL: https://issues.jboss.org/browse/WFCORE-1178
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.3.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Currently when we get the description of a reply value type for a ListAttributeDefintion or a MapAttributeDefinition we call addOperationParameterValueTypeDescription() from addOperationReplyValueTypeDescription() instead of providing its specific description.
> We should override the current code in the subclass to have a description specific to the reply attribute like we have per default after WFCORE-313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1178) Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1178?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1178:
------------------------------------------
Could a change like this break subsystems that already exist?
> Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1178
> URL: https://issues.jboss.org/browse/WFCORE-1178
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.3.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Currently when we get the description of a reply value type for a ListAttributeDefintion or a MapAttributeDefinition we call addOperationParameterValueTypeDescription() from addOperationReplyValueTypeDescription() instead of providing its specific description.
> We should override the current code in the subclass to have a description specific to the reply attribute like we have per default after WFCORE-313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5754) Use specific description for reply value types in TimerAttributeDefinition and LegacySupport
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFLY-5754:
---------------------------------------
Summary: Use specific description for reply value types in TimerAttributeDefinition and LegacySupport
Key: WFLY-5754
URL: https://issues.jboss.org/browse/WFLY-5754
Project: WildFly
Issue Type: Bug
Components: EJB, Security
Affects Versions: 10.0.0.CR4
Reporter: ehsavoie Hugonnet
Assignee: Darran Lofthouse
Priority: Minor
Currently when we get the description of a reply value type for a TimerAttributeDefinition or a LegacySupport we use operationParameterValueType description instead of operationReplyValueType description.
We should override the current code in those to have a description specific to the reply attribute like we have per default after WFCORE-313 / WFCORE-1178
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5754) Use specific description for reply value types in TimerAttributeDefinition and LegacySupport
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-5754?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-5754:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Darran Lofthouse)
> Use specific description for reply value types in TimerAttributeDefinition and LegacySupport
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5754
> URL: https://issues.jboss.org/browse/WFLY-5754
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.CR4
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Currently when we get the description of a reply value type for a TimerAttributeDefinition or a LegacySupport we use operationParameterValueType description instead of operationReplyValueType description.
> We should override the current code in those to have a description specific to the reply attribute like we have per default after WFCORE-313 / WFCORE-1178
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1178) Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1178?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1178:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1178
> URL: https://issues.jboss.org/browse/WFCORE-1178
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.3.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Currently when we get the description of a reply value type for a ListAttributeDefintion or a MapAttributeDefinition we call addOperationParameterValueTypeDescription() from addOperationReplyValueTypeDescription() instead of providing its specific description.
> We should override the current code in the subclass to have a description specific to the reply attribute like we have per default after WFCORE-313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5682:
----------------------------------------
Yes, it's confusing. Using a default value for 'relative-to' was a mistake; better would have been to leave the attribute with no default and just include object-store-relative-to="jboss.server.data.dir" in our standard config files. But we didn't do that and needed to preserve compatibility so we created the AS7-2078 standard for handling such cases. I don't want to have a separate variant beyond the two approaches described there.
It is tempting to do something very much like what you did though, Amos, and switch this to the version of the standard handling where there is no default for relative-to, and whether that is defined or not controls whether 'path' is regarded as being absolute. To do that though:
1) The standard config files will need to be updated to explicitly declare object-store-relative-to="jboss.server.data.dir" and object-store-path="tx-object-store". This will make the OOTB behavior consistent with past releases.
2) The parsers for old xsd versions should probably be updated to set object-store-relative-to to jboss.server.data.dir if the xml attribute is not defined, so the parsing of an old config produces the same result as it did before.
3) TransactionSubsystemAdd can have logic similar to what you have in your PR where it checks for object-store-relative-to being undefined and object-store-path being undefined or with a value of 'tx-object-store' and if found it uses the 'jboss.server.data.dir' as the object-store-relative-to value. It should do this in populateModel though, so the 'jboss.server.data.dir' value is stored in the model and persisted to xml. That allows old CLI scripts to work unchanged. If it does this though it should log a WARN. All of this paragraph is really just a bit of migration assistance.
I don't see any reason to drop the default value of 'tx-object-store' for 'object-store-path'. If we did, we would have to require that the attribute not be null, and that might break users who assumed it didn't have to be set.
Any of these changes (my branch, your PR or the suggestion above) all mean the management API for this subsystem has changed though, and we need to bump the API version. It's too late to do that for WF 10.0.0.Final, so this will need to be deferred to the next WildFly release. JBEAP-1913 then would not be resolved until after WildFly 10 is done.
> Can't define absolute path for object store location
> ----------------------------------------------------
>
> Key: WFLY-5682
> URL: https://issues.jboss.org/browse/WFLY-5682
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.CR5
>
>
> As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible.
> If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2].
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: 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.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> {code}
> [2]
> {code}
> 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)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13]
> Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters"
> at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205)
> at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1178) Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1178:
-----------------------------------------
Summary: Use specific description for reply value types in ListAttributeDefintion and MapAttributeDefinition
Key: WFCORE-1178
URL: https://issues.jboss.org/browse/WFCORE-1178
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.3.Final
Reporter: ehsavoie Hugonnet
Assignee: Brian Stansberry
Priority: Minor
Currently when we get the description of a reply value type for a ListAttributeDefintion or a MapAttributeDefinition we call addOperationParameterValueTypeDescription() from addOperationReplyValueTypeDescription() instead of providing its specific description.
We should override the current code in the subclass to have a description specific to the reply attribute like we have per default after WFCORE-313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1177) Service can't be installed if the path contains a closed bracket
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1177?page=com.atlassian.jira.plugi... ]
James Perkins moved WFLY-5751 to WFCORE-1177:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1177 (was: WFLY-5751)
Component/s: Scripts
(was: Scripts)
Affects Version/s: (was: 10.0.0.CR4)
(was: 9.0.1.Final)
(was: 9.0.2.Final)
Fix Version/s: (was: Awaiting Volunteers)
> Service can't be installed if the path contains a closed bracket
> ----------------------------------------------------------------
>
> Key: WFCORE-1177
> URL: https://issues.jboss.org/browse/WFCORE-1177
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: all Windows versions
> Reporter: Paul Wildberg
> Priority: Critical
> Labels: jboss
>
> Problem:
> If you start "service.bat install" in e.g. in C:\Program Files (x86)\wildfly-9.0.1.Final\bin\service you will get:
> Using the X86-64bit version of prunsrv
> "\wildfly-9.0.1.Final\domain\log" can not be used syntatically at this point (don't know if it is correct, I translated it from german. Original it is "kann syntaktisch an dieser Stelle nicht verarbeitet werden.")
> Cause:
> This is because of the ) in "Program Files (x86)" and this is a problem because in the service.bat in line 175 and 179 (set LOGPATH=%JBOSS_HOME%\domain\log - in version 9.0.1 and 9.0.2 - in Version 10 it may be in another line) the path is not set in double quotation marks.
> All other paths are set in double quotation marks.
> Solution:
> Set the path in double quotation marks:
> set LOGPATH="%JBOSS_HOME%\domain\log"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months