[JBoss JIRA] (DROOLS-81) Drools freezes during execution
by Andrew kelly (JIRA)
[ https://issues.jboss.org/browse/DROOLS-81?page=com.atlassian.jira.plugin.... ]
Andrew kelly commented on DROOLS-81:
------------------------------------
We changes the MVel Optimizer used when constructing Rules and this has reduced the occurance of the problem. However when Rules are serialized the MVELCompilationUnit hardcodes the Optimizer.
// Just temporary as PropertyHandler is not working with ASM
OptimizerFactory.setDefaultOptimizer( OptimizerFactory.SAFE_REFLECTIVE );
Can this be fixed in Drools 5.5?
> Drools freezes during execution
> -------------------------------
>
> Key: DROOLS-81
> URL: https://issues.jboss.org/browse/DROOLS-81
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Andrew kelly
> Assignee: Mario Fusco
>
> When Drools is being run to process rules on a number of threads on occasion the rules engine freezes with the stack trace below and does not complete. There are a number of other threads that are also frozen out waiting to lock 0x00002aab9d4caf58:
> Frozen Thread
> "pool-3-thread-8" prio=10 tid=0x00002ab53d16e000 nid=0x1c29 runnable [0x0000000049fc7000]
> java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:408)
> - locked \<0x00002aab9d4caf58\> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
> at java.util.WeakHashMap.get(WeakHashMap.java:464)
> at org.mvel2.util.ParseTools.getBestCandidate(ParseTools.java:241)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1039)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> - locked \<0x00002aaec5b1b160\> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
> at com.iontrading.arc.liquidityrules.engine.BatchRulesEngine.processAll(BatchRulesEngine.java:64)
> at com.iontrading.arc.liquidityrules.api.rulestoresource.AbstractRuleStoreSourceService.performBaselineProcessing(AbstractRuleStoreSourceService.java:860)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService.access$600(RuleStoreSourceService.java:32)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:66)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:38)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Example of other frozen threads:
> "pool-3-thread-9" prio=10 tid=0x00002ab53d16f800 nid=0x1c2a waiting for monitor entry [0x000000004a0c9000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:386)
> - waiting to lock \<0x00002aab9d4caf58\> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
> at java.util.WeakHashMap.get(WeakHashMap.java:464)
> at org.mvel2.util.ParseTools.getBestCandidate(ParseTools.java:241)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1039)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
> at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> - locked \<0x00002aaeedca2870\> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
> at com.iontrading.arc.liquidityrules.engine.BatchRulesEngine.processAll(BatchRulesEngine.java:64)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService.performViewProcessing(RuleStoreSourceService.java:133)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:78)
> at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:38)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-1273) Remove hard wired dependency on configadmin
by Thomas Diesler (JIRA)
Thomas Diesler created WFLY-1273:
------------------------------------
Summary: Remove hard wired dependency on configadmin
Key: WFLY-1273
URL: https://issues.jboss.org/browse/WFLY-1273
Project: WildFly
Issue Type: Task
Components: ConfigAdmin, OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
{code}
interface SystemPackagesIntegration {
String[] DEFAULT_SYSTEM_MODULES = new String[] {
"javax.api",
"javax.inject.api",
"org.apache.xerces",
"org.jboss.as.configadmin",
"org.jboss.as.controller-client",
"org.jboss.as.osgi",
"org.jboss.dmr",
"org.jboss.logging",
"org.jboss.modules",
"org.jboss.msc",
"org.jboss.osgi.framework",
"org.jboss.osgi.repository",
"org.jboss.osgi.resolver"
};
{code}
A modular build that contains osgi must currently also contain configadmin
--
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
11 years, 8 months
[JBoss JIRA] (JBDEPLOY-278) DefaultStructureCache uses unescaped path as regex
by Hui Wang (JIRA)
[ https://issues.jboss.org/browse/JBDEPLOY-278?page=com.atlassian.jira.plug... ]
Hui Wang commented on JBDEPLOY-278:
-----------------------------------
Hi James, I think it's better to assign this issue to dev, so that they can add the fix to the branch tag and it will be included in EAP 5.3.0 release.
> DefaultStructureCache uses unescaped path as regex
> --------------------------------------------------
>
> Key: JBDEPLOY-278
> URL: https://issues.jboss.org/browse/JBDEPLOY-278
> Project: JBoss Deployers
> Issue Type: Bug
> Components: vfs
> Affects Versions: JBDEPLOY-2.0.10.GA
> Reporter: James Livingston
> Attachments: JBDEPLOY-278.diff, JBDEPLOY-278.patch
>
>
> DefaultStructureCache.getLeaves() takes an unescaped pathName and then uses it as part of a regular expression. This could cause problems if pathName contained any characters that have special meaning in regexps.
> The method also creates a new Pattern object on each call which is relatively expensive.
> It could be fixed and the regex creation dropped by using the following:
> bool matches = key.startsWith(pathName) && (key.charAt(pathName.length) == '/') && (key.substring(pathName.length + 1).indexOf('/') == -1)
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-1113) JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1113?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-1113.
------------------------------------
Fix Version/s: 8.0.0.Alpha1
Resolution: Out of Date
> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-1113
> URL: https://issues.jboss.org/browse/WFLY-1113
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation
> Environment: n/a
> Reporter: Craig Ringer
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha1
>
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-1272) Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1272?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-1272:
---------------------------------
Assignee: (was: Thomas Diesler)
Component/s: Server
(was: ConfigAdmin)
> Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
> -----------------------------------------------------------------
>
> Key: WFLY-1272
> URL: https://issues.jboss.org/browse/WFLY-1272
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Emmanuel Hugonnet
>
> Hi,
> I have a quite complexe application which I'm trying to port form JBoss 6.1.0 to JBoss 7.2.0.
> The ear is exploded as well as the war it contains. I have activated the auto-deploy-exploded on the deployment scanner.
> I have no error messages only warnings but the startup goes into an infinite loop trying to deploy my application again and again.
> If I set the auto-deploy-exploded to false then I can deploy correctly.
> Maybe it is because my application takes some time to launch (having to load a bunch of data into cache on startup).
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-1272) Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-1272:
---------------------------------------
Summary: Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
Key: WFLY-1272
URL: https://issues.jboss.org/browse/WFLY-1272
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Reporter: Emmanuel Hugonnet
Assignee: Thomas Diesler
Hi,
I have a quite complexe application which I'm trying to port form JBoss 6.1.0 to JBoss 7.2.0.
The ear is exploded as well as the war it contains. I have activated the auto-deploy-exploded on the deployment scanner.
I have no error messages only warnings but the startup goes into an infinite loop trying to deploy my application again and again.
If I set the auto-deploy-exploded to false then I can deploy correctly.
Maybe it is because my application takes some time to launch (having to load a bunch of data into cache on startup).
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-1271) Infinispan remote-store requires remote-servers but not marked as required in mgmt model
by Takayoshi Kimura (JIRA)
Takayoshi Kimura created WFLY-1271:
--------------------------------------
Summary: Infinispan remote-store requires remote-servers but not marked as required in mgmt model
Key: WFLY-1271
URL: https://issues.jboss.org/browse/WFLY-1271
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Takayoshi Kimura
Assignee: Paul Ferraro
Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
Command remote-store=REMOTE_STORE:add fails with this exception:
{quote}
15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 22 more
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 23 more
{quote}
Reproduce steps:
{quote}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
{
"outcome" => "failed",
"failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
{
"outcome" => "success",
"response-headers" => {"process-state" => "reload-required"}
}
{quote}
In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
{quote}
<xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
{quote}
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-786) NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/WFLY-786?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek reassigned WFLY-786:
-----------------------------------
Assignee: Brian Stansberry (was: Ondrej Zizka)
Fix assignation of this issue to the author of TestCase.
> NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-786
> URL: https://issues.jboss.org/browse/WFLY-786
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Michael Musgrove
> Assignee: Brian Stansberry
>
> This test fails when we run the test suite with the following IPv6 options:
> {noformat}
> -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Djboss.bind.address=[::1] -Djboss.bind.address.management=[::1] -Djboss.bind.address.unsecure=[::1]
> {noformat}
>
> It appears that the test is expecting an array containing one nic address but instead gets two (IPv4 and IPv6) addresses. The linked JBTM jira is where we initially reported the issue. Test output is:
> {noformat}
> Failed tests:
> testBasic(org.jboss.as.controller.interfaces.NicInterfaceCriteriaUnitTestCase): expected:<[/0:0:0:0:0:0:0:1%1]> but was:<[/0:0:0:0:0:0:0:1%1, /127.0.0.1]>
> testMultipleCriteria(org.jboss.as.controller.interfaces.NotInterfaceCriteriaUnitTestCase): expected:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> testMultipleCriteria(org.jboss.as.controller.interfaces.AnyInterfaceCriteriaUnitTestCase): expected:<{name:lo (lo)=[/0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:lo (lo)=[/127.0.0.1, /0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> {noformat}
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-738) XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
by Hisanobu Okuda (JIRA)
Hisanobu Okuda created SECURITY-738:
---------------------------------------
Summary: XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
Key: SECURITY-738
URL: https://issues.jboss.org/browse/SECURITY-738
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossXACML
Affects Versions: picketbox_xacml_2.0.8.Final
Environment: EAP 6.0.1
Reporter: Hisanobu Okuda
Assignee: Anil Saldhana
We are using the DatabaseResourceAttributeLocator in jboss-xacml 2.0.8.Final for fetching a policy attribute from an Oracle 11g database. The Oracle JDBC driver is ojdbc6 11.2.0.x. However, the locator fails with an SQLException. The complete stacktrace is attached, but the interesting part is the following:
{code}
Caused by: java.sql.SQLException: error occurred during batching: batch must be either executed or cleared
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3435)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3493)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
at org.jboss.security.xacml.locators.attrib.DatabaseAttributeLocator.getColumnValue(DatabaseAttributeLocator.java:215)
... 48 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months