[JBoss JIRA] (DROOLS-325) Conditional named consequences don't allow references to public fields
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-325:
-----------------------------------
Summary: Conditional named consequences don't allow references to public fields
Key: DROOLS-325
URL: https://issues.jboss.org/browse/DROOLS-325
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Mac OS-X 10.9, JBoss Developer Studio, Oracle Hotspot 1.7.0_45
Reporter: Duncan Doyle
Assignee: Mark Proctor
See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin:
https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
As you can see in the 'src/main/resources/rules/Sample.drl', the first rule, which is commented out, references the public fields Message.HELLO and Message.GOODBYE in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
Rule Compilation error HELLO cannot be resolved or is not a field.
When I use the actual value of Message.HELLO and Message.GOODBYE, as shown in the second rule 'if (m.getStatus() == 0) break [sayHello]', everything works fine.
Please note that there is also an issue with using MVEL expressions in Conditional named consequences (as you can see in my example rules). That issue is tracked in JIRA DROOLS-324.
--
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, 2 months
[JBoss JIRA] (DROOLS-324) Conditional named consequences don't allow MVEL expressions in the condition of an if statement
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-324:
-----------------------------------
Summary: Conditional named consequences don't allow MVEL expressions in the condition of an if statement
Key: DROOLS-324
URL: https://issues.jboss.org/browse/DROOLS-324
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR5
Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
Reporter: Duncan Doyle
Assignee: Mark Proctor
See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
As you can see in the 'src/main/resources/rules/Sample.drl', the first rule, which is commented out, uses an MVEL expression in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
Rule Compilation error The field DroolsTest.Message.status is not visible.
When I use a Java dialect and define the conditional if as " if (m.getStatus() == 0) break [sayHello]", as shown in the second rule everything works fine.
Note that there is also an issue with using public constants in the condition, but I'll open another JIRA for that issue.
--
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, 2 months
[JBoss JIRA] (WFLY-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]
This works for datasources, which is good news, but unfortunately it does not work for the other big use case for this feature, JMS queues and topics. That is, these 2 commands are insufficient to make Queues/Topics editable:
/core-service=management/access=authorization/constraint=application-classification/type=messaging/classification=jms-topic:write-attribute(name=configured-application,value=true)
/core-service=management/access=authorization/constraint=application-classification/type=messaging/classification=jms-queue:write-attribute(name=configured-application,value=true)
My guess as to the cause of this is that the relevant "Presenter" covers all sorts of other stuff, i.e. Connection Factories, Security Settings, Address Settings, Diverts, and these (correctly) cannot be configured to become "application resources."
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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, 2 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by gui borland (JIRA)
[ https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin.... ]
gui borland updated WFLY-2454:
------------------------------
Issue Type: Bug (was: Feature Request)
> Cannot stop recovery manager when configured with volatile store
> ----------------------------------------------------------------
>
> Key: WFLY-2454
> URL: https://issues.jboss.org/browse/WFLY-2454
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
> I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
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, 2 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by gui borland (JIRA)
gui borland created WFLY-2455:
---------------------------------
Summary: Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
Key: WFLY-2455
URL: https://issues.jboss.org/browse/WFLY-2455
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: gui borland
Assignee: Tom Jenkinson
Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
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, 2 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by gui borland (JIRA)
gui borland created WFLY-2454:
---------------------------------
Summary: Cannot stop recovery manager when configured with volatile store
Key: WFLY-2454
URL: https://issues.jboss.org/browse/WFLY-2454
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: gui borland
Assignee: Tom Jenkinson
When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
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, 2 months
[JBoss JIRA] (WFLY-2436) do not allow JPA deployment failure to stop the server
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2436?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2436:
------------------------------------
With fix applied, warnings will be logged but the server doesn't terminate:
{quote}
16:27:09,351 WARN [org.jboss.as.jpa] (Controller Boot Thread) JBAS011411: Unexpected problem gathering statistics: java.lang.IllegalStateException: JBAS011477: Persistence unit 'invaliddeploy.jar#TEST_PU' is not available
{quote}
> do not allow JPA deployment failure to stop the server
> ------------------------------------------------------
>
> Key: WFLY-2436
> URL: https://issues.jboss.org/browse/WFLY-2436
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 8.0.0.CR1
>
> Attachments: invaliddeploy.jar
>
>
> Deploying the attached invalid deployment, causes a deployment failure. Restarting the server with the attached deployment, can cause the server to terminate with:
> {quote}
> 14:03:24,361 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: java.lang.NullPointerException
> at org.jboss.as.jpa.management.EntityManagerFactoryLookup.entityManagerFactory(EntityManagerFactoryLookup.java:39)
> at org.jboss.as.jpa.hibernate4.management.HibernateEntityStatistics.getDynamicChildrenNames(HibernateEntityStatistics.java:145)
> at org.jboss.as.jpa.management.DynamicManagementStatisticsResource.getChildren(DynamicManagementStatisticsResource.java:166)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:567) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:223) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:512) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:274) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:684) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:659) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:470) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:274) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:269) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:332) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:293) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:255) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {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, 2 months
[JBoss JIRA] (WFLY-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Harald Pehl <hpehl(a)redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]
The console uses @AccessControl annotations to bind 1-n resources to presenters. Presenters are the "P" in the MVP architecture used in the console. Most presenters are addressable using an URL like http://localhost:9990/console/App.html#datasources.
When the presenter is shown for the first time, the console reads the access control metadata of its configured resources to decide whether operations can be executed or attributes are readable/writable.
The datasource presenter is configured using the following resources:
@AccessControl(resources = {
"/{selected.profile}/subsystem=datasources/data-source=*",
"/{selected.profile}/subsystem=datasources/xa-data-source=*"
})
The current implementation uses an "all-or-nothing" rule: If not all resources are writable, none will be writable. To cut a long story short. Making also the xa-data-source an application resource will give the deployer the permissions to edit both the data-source and the xa-data-source resource:
/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=xa-data-source:write-attribute(name=configured-application, value=true)
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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, 2 months
[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/JBCOMMON-131?page=com.atlassian.jira.plug... ]
Dimitris Andreadis closed JBCOMMON-131.
---------------------------------------
Resolution: Rejected
First you hijack an old forum thread to ask a different question.
Then you pick up a random project tracker (JBCOMMON) and open a bug report for something that is not a bug but a usage question.
Learn how to ask questions properly:
https://community.jboss.org/wiki/HowToAskAForumQuestion
And ask your question in the AS7 user forum:
https://community.jboss.org/en/jbossas7
If you re-open the ticket, I'll just remove it.
PS
By just looking at your case you are probably referencing a cache that is not defined elsewhere.
> Setting cache timeout for JAAS under jboss-eap-6.1 does not work
> ----------------------------------------------------------------
>
> Key: JBCOMMON-131
> URL: https://issues.jboss.org/browse/JBCOMMON-131
> Project: JBoss Common
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: jboss-eap-6.1
> Reporter: Artur Mioduszewski
> Assignee: Dimitris Andreadis
>
> When: cache-type="default" in security-domain configuration -> authentication works correctly.
> When I have used below configuration in order to try to set cache timeout in JAAS -> JAAS authentication stops to work - I am not able to log in (on JBoss console there are not any errors)
> <code>
> ...
> <security-domain name="myJaasDomain" cache-type="infinispan">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
> <module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
> <module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="base64"/>
> <module-option name="unauthenticatedIdentity" value="guest"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
> <cache-container name="cluster" aliases="ha-partition" default-cache="default">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC" batching="true">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <transaction mode="NONE"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC">
> <transaction mode="NONE"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <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, 2 months