[JBoss JIRA] Created: (JBCOMMON-27) Incorrect behaviour in TCLFilter
by Scott M Stark (JIRA)
Incorrect behaviour in TCLFilter
---------------------------------
Key: JBCOMMON-27
URL: http://jira.jboss.com/jira/browse/JBCOMMON-27
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.GA
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: 1.0.5.GA
Just one TCLFilter can be added to an appender, decide method return either ACCEPT or DENY.
Should return NEUTRAL is some case.
public int decide(LoggingEvent event)
{
int ok = Filter.DENY;
if( acceptOnMatch == true )
{
ok = Filter.DENY;
if( isMatchingTCL() ){
ok = Filter.ACCEPT;
}
}
else
{
ok = Filter.ACCEPT; // CHANGING THIS ROW TO ok = Filter.NEUTRAL; should do that you check the other filters to.
if( isMatchingTCL() )
ok = Filter.DENY;
}
return ok;
}
Log4j.xml:
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %c - %m%n"/>
</layout>
<filter class="org.jboss.logging.filter.TCLFilter">
<param name="AcceptOnMatch" value="false"/>
<param name="DeployURL" value="jboss-common-client.jarpoyan"/>
</filter>
<filter class="org.jboss.logging.filter.TCLFilter">
<param name="AcceptOnMatch" value="false"/>
<param name="DeployURL" value="dnsns.jarpoyan"/>
</filter>
</appender>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBAS-4404) Tests testJdbc and testControlFlags in org.jboss.test.security.test.LoginModulesUnitTestCase may fail incorrectly
by Stephen Burdeau (JIRA)
Tests testJdbc and testControlFlags in org.jboss.test.security.test.LoginModulesUnitTestCase may fail incorrectly
-----------------------------------------------------------------------------------------------------------------
Key: JBAS-4404
URL: http://jira.jboss.com/jira/browse/JBAS-4404
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.5.GA
Environment: Unisys MCP
Reporter: Stephen Burdeau
Suites: org.jboss.test.security.test.LoginModulesUnitTestCase, org.jboss.test.security.test.XMLLoginModulesUnitTestCase
Tests: testJdbc, testControlFlags
When running these tests with JBoss AS 4.0.5 on the Unisys MCP system, these tests fail as follows:
junit.framework.AssertionFailedError: Java is a role
at org.jboss.test.security.test.LoginModulesUnitTestCase.testJdbc(LoginModulesUnitTestCase.java:879)
and
junit.framework.AssertionFailedError: Role1 is a role
at org.jboss.test.security.test.LoginModulesUnitTestCase.testControlFlags(LoginModulesUnitTestCase.java:919)
There appears to be a bug in the test code. The tests testJdbc and testControlFlags use the org.jboss.security.auth.spi.DatabaseServerLoginModule to query for the roles allowed. However, the call to subject.getPrincipals(Group.class) returns a Set with two groups: "Roles" and "CallerPrincipal". Because a Set is unordered, the iterator for the set may return either "Roles" or "CallerPrincipal" first. However, the test code always just looks at the first group in the Set and assumes it is the "Roles" group. On the MCP, this first group seems to be the "CallerPrincipal" group, so the test assertions fail.
I updated the test code to find the "Roles" group first before performing the assertions. With this change, the tests pass on both the Unisys MCP and Windows systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBAS-4490) Update and document all HA Failover features for the jca datasources
by Adrian Brock (JIRA)
Update and document all HA Failover features for the jca datasources
--------------------------------------------------------------------
Key: JBAS-4490
URL: http://jira.jboss.com/jira/browse/JBAS-4490
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JCA service
Reporter: Adrian Brock
Assigned To: Adrian Brock
Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.1.CR1
There are some features (configuration properties) in the ha datasource processing that are not documented
and are not properly defined in the ra.xml
E.g. there is a configuration property "UrlSelectorStrategyClassName" that lets you control
how the choice of connection urls is made in the ha-local datasource
This needs adding to the ra.xml and documenting on the WIKI:
<config-property>
<description>The class used to determine which URL to use at failover.</description>
<config-property-name>UrlSelectorStrategyClassName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
</config-property>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBREM-705) Separate the http invoker and web container dependency
by Scott M Stark (JIRA)
Separate the http invoker and web container dependency
------------------------------------------------------
Key: JBREM-705
URL: http://jira.jboss.com/jira/browse/JBREM-705
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.0.Alpha7
Reporter: Scott M Stark
Assigned To: Tom Elrod
The remoting/2.2.0.Alpha7 release declares a dependency on apache-tomcat:
<!-- Only need the apache-tomcat jars tomcat-apr.jar, tomcat-coyote.jar, tomcat-http.jar, tomcat-util.jar
(and tomcat-apr.jar only needed if actually using APR transport). None of these are needed unless
using http server invoker -->
<import componentref="apache-tomcat">
<compatible version="5.5.15"/>
</import>
This should be broken out into a separate artifact that can be independently versioned for web container dependencies.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months