[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from NEW to ASSIGNED
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved MODCLUSTER-393 to WFLY-3112:
-------------------------------------------------
Project: WildFly (was: mod_cluster)
Key: WFLY-3112 (was: MODCLUSTER-393)
Affects Version/s: 8.0.0.Final
(was: 1.2.6.Final)
Security: Public
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LoggingEvent always returns class String
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-3111:
-------------------------------------
The only way this will work currently is if you include your own version of log4j. I'm assuming of course you're including a log4j configuration file in your deployment. If you're attempting to use an appender as a custom-handler I don't think it will be possible to work. Have a look at https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-HowdoIuselog4j.p... to see how to include your own version of log4j.
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LoggingEvent always returns class String
by Jörg Brück (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
Jörg Brück updated WFLY-3111:
-----------------------------
Summary: Accessing attribute message from class LoggingEvent always returns class String (was: Accessing attribute message from class LogigngEvent always returns class String)
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LogingEvent always returns class String
by Jörg Brück (JIRA)
Jörg Brück created WFLY-3111:
--------------------------------
Summary: Accessing attribute message from class LogingEvent always returns class String
Key: WFLY-3111
URL: https://issues.jboss.org/browse/WFLY-3111
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 8.0.0.Final
Environment: Windows 7, JDK 1.7.0_51
Reporter: Jörg Brück
Assignee: James Perkins
Priority: Minor
After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
have changed while accessing LoggingEvent in the function "append" of
class ApppenderSkeleton.
The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
this.fqnOfCategoryClass = fqnOfCategoryClass;
this.logger = logger;
this.level = level;
logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
The Object message is converted to string and saved in Class ExtLogRecord.
Here the implementation of getMessage:
public Object getMessage() {
return logRecord.getMessage();
}
Here the implementation of getMessage of ExtLogRecord
public String getMessage() {
return message;
}
Because of this String is always returned.
If I understand this code right you can transfer every object to log4j, but you can not access this objects
in an appender because of the LoggingEvent constructor where method toString is called.
What is the reason of this change in contrast to jboss 5.1.0?
Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LogigngEvent always returns class String
by Jörg Brück (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
Jörg Brück updated WFLY-3111:
-----------------------------
Summary: Accessing attribute message from class LogigngEvent always returns class String (was: Accessing attribute message from class LogingEvent always returns class String)
> Accessing attribute message from class LogigngEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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
12 years, 1 month
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Maxime Falaize (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Maxime Falaize commented on DROOLS-450:
---------------------------------------
I added a test case to my PR. You can test it with and without the patch.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2334) EL expansion broken in persistence.xml
by Ken H (JIRA)
[ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.... ]
Ken H updated WFLY-2334:
------------------------
Description:
When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}
was:
When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}
> EL expansion broken in persistence.xml
> --------------------------------------
>
> Key: WFLY-2334
> URL: https://issues.jboss.org/browse/WFLY-2334
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
> Environment: OSX, jdk 1.7.0_21
> Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {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
12 years, 1 month
[JBoss JIRA] (WFLY-2334) EL expansion broken in persistence.xml
by Ken H (JIRA)
[ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.... ]
Ken H updated WFLY-2334:
------------------------
Affects Version/s: 8.0.0.Final
JBoss AS7 7.2.0.Final
(was: 8.0.0.Beta1)
> EL expansion broken in persistence.xml
> --------------------------------------
>
> Key: WFLY-2334
> URL: https://issues.jboss.org/browse/WFLY-2334
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
> Environment: OSX, jdk 1.7.0_21
> Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {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
12 years, 1 month
[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly, and is missing transformer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------
Tomaz Cerar <tcerar(a)redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from NEW to POST
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2474
> URL: https://issues.jboss.org/browse/WFLY-2474
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> <acl>
> <acl-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </acl-module>
> </acl>
> {code}
> becomes
> {code}
> <acl>
> <login-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </login-module>
> </acl>
> {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
12 years, 1 month