February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1183) Cache user's identity in the ServerInvocation.IDENTITY_SCOPE

by Julien Viet (JIRA)

Cache user's identity in the ServerInvocation.IDENTITY_SCOPE ------------------------------------------------------------ Key: JBPORTAL-1183 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1183 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.6.Alpha1 Reporter: Julien Viet Assigned To: Boleslaw Dawidowicz Fix For: 2.6.Beta1 -- 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

19 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-823) Refactor eviction configuration away from EvictionConfiguration interface

by Brian Stansberry (JIRA)

Refactor eviction configuration away from EvictionConfiguration interface ------------------------------------------------------------------------- Key: JBCACHE-823 URL: http://jira.jboss.com/jira/browse/JBCACHE-823 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA The EvictionConfiguration interface presumes that objects that represent a policy configuration should be able to parse their XML config themselves. We don't want that; parsing of the legacy XML configs should be handled by XmlConfigurationParser and policy config objects should be configurable by the MC without their having any internal expectation of being passed a DOM element. To do this: 1) Create interface EvictionPolicyConfig. This is used internally (e.g. in the RegionManager and Region classes) in place of EvictionConfiguration. 2) All of the config classes for the standard eviction policies now implement EvictionPolicyConfig instead of EvictionConfiguration. To support old custom policies: 1) EvictionConfiguration still exists but is deprecated. 2) EvictionConfiguration now extends EvictionPolicyConfig. So, custom impls *will* need to be modified to implement EvictionPolicyConfig's 2 methods. 3) XmlConfigurationParser when trying to configure a policy config object will check if it implements EvictionConfiguration. If it does, the legacy parseXmlConfig(Element) method will be called. Otherwise it will be configured via reflection. Need to decided exactly how to handle the old public EvictionConfiguration Region.getEvictionConfiguration() method. -- 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

19 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-822) Reconsider validation of EvictionPolicyConfig objects

by Brian Stansberry (JIRA)

Reconsider validation of EvictionPolicyConfig objects ----------------------------------------------------- Key: JBCACHE-822 URL: http://jira.jboss.com/jira/browse/JBCACHE-822 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani In the legacy code, various impls of EvictionConfiguration would validate input during calls to parseXmlConfig. Problem is that if a config was instantiated and configured programatically, no validation occurred. Further the old parseXmlConfig validations basically just tested whether a configuration element was present, not whether it had a reasonable value. The new validate() methods really should just test for reasonable values; whether the value was configured externally or was there by default is irrelevant. Main task here is to remove some old unit tests that checked whether a value was set or not during xml parsing and replace with tests that check whether the reasonable value requirement is enforced. Probably will do this after alpha. -- 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

19 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1272) improve implementation of offset/limit in LDAP searches

by Boleslaw Dawidowicz (JIRA)

improve implementation of offset/limit in LDAP searches ------------------------------------------------------- Key: JBPORTAL-1272 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1272 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.6.Beta1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.CR1 instead of current dummy implementation which is unefficient use SearchControls and batch ldap operations -- 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

19 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-416) MergeView processing fails for Multiplexer channel

by Jerry Gauthier (JIRA)

MergeView processing fails for Multiplexer channel -------------------------------------------------- Key: JGRP-416 URL: http://jira.jboss.com/jira/browse/JGRP-416 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 Reporter: Jerry Gauthier Assigned To: Bela Ban When I simulate a cluster failure and restart using a Multiplexer channel, the merge process fails in JGroups with an UnsupportedOperationException in Multiplexer.mergeServiceState(). The stack trace is as follows. ERROR [org.jgroups.mux.Multiplexer] problems handling merge view java.lang.UnsupportedOperationException at org.jgroups.util.UnmodifiableVector.retainAll(UnmodifiableVector.java:158) at org.jgroups.mux.Multiplexer.mergeServiceState(Multiplexer.java:867) at org.jgroups.mux.Multiplexer.handleMergeView(Multiplexer.java:812) at org.jgroups.mux.Multiplexer.access$200(Multiplexer.java:21) at org.jgroups.mux.Multiplexer$1.run(Multiplexer.java:287) I looked at the relevant JGroups code and it appears that JGroups uses a MergeView object that always returns an UnmodifiableVector when MergeView.getMembers() is invoked. The Multiplexer.mergeServiceState() method invokes MergeView.getMembers() followed by UnmodifiableVector(.retainAll(), causing the exception to occur. This problem can be replicated by executing DRMTestCase in JBossAS 5.0. The error occurs in DRMTestCase.isMasterReplica(). -- 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

19 years, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1274) in identity classes correct usage of 'JNDI' in property names (instead of 'Jndi')

by Boleslaw Dawidowicz (JIRA)

in identity classes correct usage of 'JNDI' in property names (instead of 'Jndi') --------------------------------------------------------------------------------- Key: JBPORTAL-1274 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1274 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.Beta1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Priority: Trivial Fix For: 2.6.CR1 in identity classes correct usage of 'JNDI' in property names (instead of 'Jndi') + update config files + update documentation -- 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

19 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1289) plug in dtd files for identity-config.xml and profile-config.xml

by Boleslaw Dawidowicz (JIRA)

plug in dtd files for identity-config.xml and profile-config.xml ---------------------------------------------------------------- Key: JBPORTAL-1289 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1289 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.Alpha2 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.CR1 those files are made but not referenced in config files. Put dtd into jars and use them -- 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

19 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-348) UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other

by Bela Ban (JIRA)

UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other ------------------------------------------------------------------------------------------------- Key: JGRP-348 URL: http://jira.jboss.com/jira/browse/JGRP-348 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Mail from David Foregt: Hi Bela, Still have an issue with JGroup 2.4 with UNICAST after applying your recommended settings. We spent more time analyzing the issue and found the exact scenario that cause the problem: - We have multiple nodes running on machine A (a1, a2, a3, a4...a15) an one node running on machine B (b1). - b1 node is started first (coord) then all a's nodes are started. When all nodes are active in the group we disconnected machine A from the network. - After ~10 sec all a's see b1 as dead and a new view is propagated to all a's nodes and connection table for b1 entry is cleared for all a's nodes. - b1 start seeing a's node as dead one by one every ~10 sec (as define by FD / VERIFY_SUSPECT) after 30 sec b1's view is (a4, a5...a15) and we reconnected the network cable on machine A. (b1 connection table was cleared for only a1...a3) - After A reconnect to the network a merge was done and all nodes are back in the group and are able to exchange Multicast message. - Because b1 did not detect a4...a15 as dead when it send a unicast message to those nodes the seqno has not been reset to 1. When a4 receive the first unicast message from b1 (because its connection table was cleared for b1) it create at line 453 of UNICAST a new AckReceiverWindow with initial_seqno = 1 and add the received message (that has a seqno > 1) in the new AckReceiverWindow then all subsequent unicast message received from b1 are added in this new AckReceiverWindow and when remove is called at line 470 of UNICAST it always return null because the AckReceiverWindow::next_to_remove is equal to 1 and the message that we are adding to AckReceiverWindow have a seqno > 1. The result is that a4...a15 will never be able to receive any other unicast msg from b1. This is reproducible all the time. Our quick fix that look to work fine is to change UNICAST line 453 as following (I am not sure about potential bug introduce by this): entry.received_msgs=new AckReceiverWindow(seqno); -- 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

19 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-3777) Cannot get client cerfiticate when using IIS 6

by Tomaz Cerar (JIRA)

Cannot get client cerfiticate when using IIS 6 ---------------------------------------------- Key: JBAS-3777 URL: http://jira.jboss.com/jira/browse/JBAS-3777 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.3 SP1 Environment: Windows 2003 SP1, IIS 6, Tomcat connector 1.2.19 Reporter: Tomaz Cerar Assigned To: Remy Maucherat We have an application where user can authenticate himself with Client certificate. SSL and authentication is done by IIS 6. The problem is that after auth is successful but I don't get client certificate in servlet. request.getAttribute("javax.servlet.request.X509Certificate") returns null The same application with same configuration works ok on IIS 5(old production box) and IIS 5.1 (development) I have tried with various versions of JK and JK2 and same result, doesn't work in IIS 6. I have tried to run IIS in IIS 5 isolation mode and without, and results are same. -- 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

19 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1273) add role recurention in LDAP membership modules

by Boleslaw Dawidowicz (JIRA)

add role recurention in LDAP membership modules ----------------------------------------------- Key: JBPORTAL-1273 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1273 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.Beta1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.CR1 Add role recurention handling in LDAP - role that contains a role that contains a role that.... This is possible using nested "member" attributes. -- 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

19 years, 4 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007