[JBoss JIRA] (AS7-6546) Changing logging handler in standalone.xml only breaks startup of JBoss AS7
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-6546?page=com.atlassian.jira.plugin.s... ]
James Perkins updated AS7-6546:
-------------------------------
Fix Version/s: 7.3.0.Alpha1
> Changing logging handler in standalone.xml only breaks startup of JBoss AS7
> ---------------------------------------------------------------------------
>
> Key: AS7-6546
> URL: https://issues.jboss.org/browse/AS7-6546
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Logging
> Affects Versions: 7.2.0.Alpha1
> Reporter: Frank Langelage
> Assignee: James Perkins
> Fix For: 7.3.0.Alpha1
>
>
> Using an unmodified build of JBoss AS 8.0.0.Alpha1-SNAPSHOT as of today.
> Starting with --server-config=standalone-full.xml is fine.
> I made a copy of standalone-full.xml as standalone-langfr.xml and replaced the periodic-rotating-file-handler by a size-rotating-file-handler:
> <size-rotating-file-handler name="FILE" autoflush="false">
> <level name="DEBUG"/>
> <encoding value="UTF-8"/>
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <rotate-size value="1g"/>
> <append value="true"/>
> </size-rotating-file-handler>
> jboss@sb2000:/jboss/8.0/standalone/configuration diff -bw standalone-full.xml standalone-langfr.xml
> 68c68,70
> < <periodic-rotating-file-handler name="FILE" autoflush="true">
> ---
> > <size-rotating-file-handler name="FILE" autoflush="false">
> > <level name="DEBUG"/>
> > <encoding value="UTF-8"/>
> 73c75
> < <suffix value=".yyyy-MM-dd"/>
> ---
> > <rotate-size value="1g"/>
> 75c77
> < </periodic-rotating-file-handler>
> ---
> > </size-rotating-file-handler>
> Trying to start the server with this config fails:
> 12:21:57,916 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.CR1
> 12:21:58,458 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA
> 12:21:58,752 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" starting
> 12:22:03,232 INFO [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.7.GA
> 12:22:03,280 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 12:22:03,285 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.7.GA
> 12:22:03,359 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.14.GA
> 12:22:03,486 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("size-rotating-file-handler" => "FILE")
> ]): java.lang.IllegalArgumentException: No property "maxBackupIndex" setter found for handler "FILE"
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.setPropertyValueExpression(AbstractPropertyConfiguration.java:195) [jboss-logmanager-1.4.0.Final.jar:1.4.0.Final]
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.setPropertyValueString(AbstractPropertyConfiguration.java:156) [jboss-logmanager-1.4.0.Final.jar:1.4.0.Final]
> at org.jboss.as.logging.PropertyAttributeDefinition.setPropertyValue(PropertyAttributeDefinition.java:62) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.logging.HandlerOperations.handleProperty(HandlerOperations.java:504) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.logging.HandlerOperations.handleProperty(HandlerOperations.java:433) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.logging.HandlerOperations.access$000(HandlerOperations.java:72) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:196) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:204) [jboss-as-logging-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:191) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:225) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:333) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:308) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:188) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_39]
> This seem to be cause by the fact, that logging.properties is outdated and does not get updated on start.
> In logging.properties there still is the old config:
> handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
> handler.FILE.level=ALL
> handler.FILE.formatter=FILE
> handler.FILE.properties=autoFlush,append,fileName,suffix,enabled
> handler.FILE.constructorProperties=fileName,append
> handler.FILE.autoFlush=true
> handler.FILE.append=true
> handler.FILE.fileName=/mbi/tools/jboss/8.0/standalone/log/server.log
> handler.FILE.suffix=.yyyy-MM-dd
> handler.FILE.enabled=true
>
> An now the is some mixture in place which causes this failure.
> When changing the logging handler via web-console or possibly also when using jboss-cli both files are changed, standalone.xml and logging.properties.
> I think on startup logging.properties should be newly created by what's defined in the current config file.
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6482) "NullPointerException" in ApplicationClientStartService.run
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/AS7-6482?page=com.atlassian.jira.plugin.s... ]
Wolfgang Knauf closed AS7-6482.
-------------------------------
Verified against a 8.0.0 snapshot, thanks for fixing it.
> "NullPointerException" in ApplicationClientStartService.run
> -----------------------------------------------------------
>
> Key: AS7-6482
> URL: https://issues.jboss.org/browse/AS7-6482
> Project: Application Server 7
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Environment: JBoss 7.2.0 Alpha1 snapshot dated 2013-02-04
> Reporter: Wolfgang Knauf
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 7.2.0.Alpha1
>
> Attachments: Stateless.ear
>
>
> Attached is a simple EAR application with EJB, Web and application client module which invokes an EJB method.
> Deploy it to the server. Then run the application client:
> %JBOSS_HOME\bin\appclient.bat C:\Temp\Stateless.ear#StatelessClient.jar
> On the client side, after the status output of the ejb call, I see this console output. It ends with a NullReferenceException.
> 21:33:39,065 INFO [org.jboss.ejb.client.remoting] (Remoting "endpoint" task-2)EJBCLIENT000016: Channel Channel ID d24023d4 (outbound) of Remoting connection 0c25db92 to localhost/127.0.0.1:4447 can no longer process messages
> 21:33:39,112 INFO [org.jboss.jaxr] (MSC service thread 1-3) JBAS014002: UnBinding JAXR ConnectionFactory: java:jboss/jaxr/ConnectionFactory
> 21:33:39,143 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: StatelessEJB.jar) in 41ms
> 21:33:39,143 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: StatelessClient.jar) in 53ms
> 21:33:39,143 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: StatelessWeb.war) in 56ms
> 21:33:39,159 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment Stateless.ear (runtime-name: Stateless.ear) in 59ms
> 21:33:39,159 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> JBAS014776: Newly corrected services:
> service jboss.remoting.endpoint.subsystem (no longer required)
> 21:33:39,159 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss AS7.2.0.Alpha1-SNAPSHOT "Steropes" stopped in 35ms
> 21:33:39,159 ERROR [stderr] (Thread-38) Exception in thread "Thread-38" java.lang.NullPointerException
> 21:33:39,159 ERROR [stderr] (Thread-38) at org.jboss.as.appclient.service.ApplicationClientStartService$2.run(ApplicationClientStartService.java:156)
> 21:33:39,174 ERROR [stderr] (Thread-38) at java.lang.Thread.run(UnknownSource)
--
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
13 years, 5 months
[JBoss JIRA] (DROOLS-44) ClassCastException with OR statements
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-44?page=com.atlassian.jira.plugin.... ]
Mario Fusco resolved DROOLS-44.
-------------------------------
Fix Version/s: 5.6
6.0.0.Alpha1
Resolution: Done
> ClassCastException with OR statements
> -------------------------------------
>
> Key: DROOLS-44
> URL: https://issues.jboss.org/browse/DROOLS-44
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Environment: Windows 7, JDK 7, Maven 2.2
> Reporter: Mohammad Z
> Assignee: Mario Fusco
> Labels: classcastexception, eval, or
> Fix For: 5.6, 6.0.0.Alpha1
>
> Attachments: drools.zip
>
>
> Rules combined with OR and AND clauses and PROBABLY global variables throw a ClassCastException.
> This issue is raised due to the discussion in user-list
> http://drools.46999.n3.nabble.com/ClassCastException-after-migrating-from...
> I attached an isolated test.
> This is the error that I get:
> Caused by: org.drools.RuntimeDroolsException: com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1Invoker@d3924bb
> c : java.lang.ClassCastException: com.test.drools.EmployeeDetailsRulesModel cannot be cast to com.test.drools.Account
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:119)
> at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
> at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
> at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192)
> at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240.defaultConsequence(Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db57
> 34ab24bd05240.java:7)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> ... 37 more
> Caused by: java.lang.ClassCastException: com.test.drools.EmployeeDetailsRulesModel cannot be cast to com.test.drools.Account
> at org.drools.base.com.test.drools.Account1369078346$getAccountStartDate.getValue(Unknown Source)
> at org.drools.base.ClassFieldReader.getValue(ClassFieldReader.java:87)
> at org.drools.rule.Declaration.getValue(Declaration.java:233)
> at com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1InvokerGenerated.evaluate(Unknown Source)
> at com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
> ... 55 more
--
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
13 years, 5 months
[JBoss JIRA] (DROOLS-44) ClassCastException with OR statements
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-44?page=com.atlassian.jira.plugin.... ]
Mario Fusco reassigned DROOLS-44:
---------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> ClassCastException with OR statements
> -------------------------------------
>
> Key: DROOLS-44
> URL: https://issues.jboss.org/browse/DROOLS-44
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Environment: Windows 7, JDK 7, Maven 2.2
> Reporter: Mohammad Z
> Assignee: Mario Fusco
> Labels: classcastexception, eval, or
> Attachments: drools.zip
>
>
> Rules combined with OR and AND clauses and PROBABLY global variables throw a ClassCastException.
> This issue is raised due to the discussion in user-list
> http://drools.46999.n3.nabble.com/ClassCastException-after-migrating-from...
> I attached an isolated test.
> This is the error that I get:
> Caused by: org.drools.RuntimeDroolsException: com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1Invoker@d3924bb
> c : java.lang.ClassCastException: com.test.drools.EmployeeDetailsRulesModel cannot be cast to com.test.drools.Account
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:119)
> at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
> at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
> at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192)
> at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240.defaultConsequence(Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db57
> 34ab24bd05240.java:7)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.test.drools.Rule_employeePreloadSystemConstants_fa8d3c7c3b23439db5734ab24bd05240DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> ... 37 more
> Caused by: java.lang.ClassCastException: com.test.drools.EmployeeDetailsRulesModel cannot be cast to com.test.drools.Account
> at org.drools.base.com.test.drools.Account1369078346$getAccountStartDate.getValue(Unknown Source)
> at org.drools.base.ClassFieldReader.getValue(ClassFieldReader.java:87)
> at org.drools.rule.Declaration.getValue(Declaration.java:233)
> at com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1InvokerGenerated.evaluate(Unknown Source)
> at com.test.drools.Rule_employeeContributionStartDateAfterAccountStartDate_ff664e4a040442f190ea42829e28cdd1Eval1Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
> ... 55 more
--
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
13 years, 5 months
[JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available
by Yi Chen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ]
Yi Chen commented on SECURITY-709:
----------------------------------
Hi, Anil
I apologize for the delayed reply to your latest reply...
I've been giving this quite a bit of thought. I realized that JBoss is built in a very modular fashion and this problem is not solely an issue with the security module. However, this does not account for the fact that an LDAP server down (or any situation where the authentication source is unreachable) situation is not the same as an authentication failure. The security module should have passed this detail to the module that requested authentication so that the calling module can make the best decision possible instead of lumping everything into just a single authentication error. I understand that this will also require that the calling module knows what do to with the extra detail. But it is very important to our project that this functionality be present. So please consider working with the web container team to see if there is any way to accomplish this. It would be really great for us if JBoss can do this and this would likely help other people as well.
Thank you,
Yi
> Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available
> ---------------------------------------------------------------------------------------
>
> Key: SECURITY-709
> URL: https://issues.jboss.org/browse/SECURITY-709
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Affects Versions: PicketBox_v4_0_7
> Reporter: Yi Chen
> Assignee: Anil Saldhana
>
> I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method:
> ...
> catch (LoginException e)
> {
> // Don't log anonymous user failures unless trace level logging is on
> if (principal != null && principal.getName() != null || trace)
> log.error("Login failure", e);
> authException = e;
> }
> // Set the security association thread context info exception
> SubjectActions.setContextInfo("org.jboss.security.exception", authException);
> return authenticated;
> }
> So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client.
> Steps to reproduce:
> Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401.
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6533) Enable the reverse controller check for the infinispan subsystem transformer test
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6533?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-6533:
------------------------------------------
I've reenabled use of the virtual-nodes attribute for distributed caches. I have implemented the changes as per Brian's description below:
{quote}
Restore support for "virtual-nodes" in the "add" and "write-attribute" handlers. Not in the parsers, which already
translate virtual-nodes to segments. The handlers will log a deprecation WARN if this attribute is encountered. If encountered the
add or write-attribute handler will do the translation to virtual-nodes that we are already doing the other way when we
transform segments for use on legacy slaves. Basically do what the parser does, but for mgmt ops coming in from clients and not just for
xml.
{quote}
> Enable the reverse controller check for the infinispan subsystem transformer test
> ---------------------------------------------------------------------------------
>
> Key: AS7-6533
> URL: https://issues.jboss.org/browse/AS7-6533
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
--
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
13 years, 5 months