June 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-186) Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support

by Scott Marlow (JIRA)

Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support ------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBCLUSTER-186 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-186 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss as 4.0.4, although this seems to happen in 4.5 + 5.x as well. Reporter: Scott Marlow Assigned To: Scott Marlow Priority: Minor Part of how JRMPInvokerProxyHA handles fail-over includes removing the reference to the node that left the cluster. However, the dead node is not removed as an equality check is not implemented by certain Invoker implementations. The relevant code in JRMPInvokerProxyHA is protected void removeDeadTarget(Object target) { if (this.familyClusterInfo != null) this.familyClusterInfo.removeDeadTarget (target); } The code in familyClusterInfo is: public ArrayList removeDeadTarget(Object target) { synchronized (this) { ArrayList tmp = (ArrayList) targets.clone(); tmp.remove (target); this.targets = tmp; this.isViewMembersInSyncWithViewId = false; } return this.targets; } Since, we didn't include an equals test in many of the different Invoker implementations, the above "tmp.remove(target)" operation fails. The reason for the failure is due to the "targets" ArrayList changing on every invocation (to reflect the current cluster server membership list), a new "targets" is created (so of course comparing references later will not work.) A similar problem occurs with the EJB2 load balancers after a cluster membership changes. I think that these issues will be solved by implementing an equals test in the different invokers that can handle equality testing. PooledInvokerProxy should implement equals based on ServerAddress. -- 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

11 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-371) TCP_NIO with SSL

by Bela Ban (JIRA)

TCP_NIO with SSL ---------------- Key: JGRP-371 URL: http://jira.jboss.com/jira/browse/JGRP-371 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Attachments: ssl-nio.jar >From Hal Hildebrand: Attached are the sources to allow a new protocol stack which uses SSL over NIO. This protocol stack element provides security and authentication (using client side authentication) for a JGroups TCP stack using NIO. This required two minor modifications in the ConnectionTableNIO class. These modifications allow one to subclass to create a connection table which uses SSL for the connections. Finally, there is a new protocol stack element, SSL_NIO, which one can add to a stack to make use of it. Regardless of whether this makes it into the codeline of JGroups, it would be nice to have the changes to ConnectionTableNIO make it into the mainline, as I currently have to overwrite the original class to easily implement this - the last thing I want to do is fork ConnectionTableNIO ;) I'd rather just subclass it. The mods are simple and innocuous (marked with "HSH"). Right now, the SSL_NIO needs to be configured with an SSLSocketFactory. I didn't bother with integrating with the normal JGroups mechanism using properties from the configuration because I consider it inherently insecure to ensconce my passwords in configuration files. But the changes to enable this are straight forward. Currently, to configure the factory for the protocol layer, do something like the following before connecting your channel: // Construct your Jchannel JChannel jchannel = ... // Access your protocol stack ProtocolStack protocolStack = jchannel.getProtocolStack(); // Retrieve the SSL_NIO protocol layer SSL_NIO protocol = (SSL_NIO) protocolStack.findProtocol("SSL_NIO"); // Create your SSLSocketFactory SSLSocketFactory socketFactory = .... // Set up the protocol protocol. SetSocketFactory(socketFactory); // Connect your channel jchannel.connnect("my-group"); Cheers. -- 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

11 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JGRP-320) ConnectionTable/ConnectionTableNIO have leftover threads after stop()

by Bela Ban (JIRA)

ConnectionTable/ConnectionTableNIO have leftover threads after stop() --------------------------------------------------------------------- Key: JGRP-320 URL: http://jira.jboss.com/jira/browse/JGRP-320 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Unit test ConnectionTableTest shows this. -- 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

11 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1275) Multiple moves win a step (moves without direct tabu property relations)

by Geoffrey De Smet (JIRA)

Multiple moves win a step (moves without direct tabu property relations) ------------------------------------------------------------------------ Key: JBRULES-1275 URL: http://jira.jboss.com/jira/browse/JBRULES-1275 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Currently only one move can win a step. If moves are evaluated not on their score, but on "the difference in score", it probably won't be a bad idea to take a low number of improving moves that have not tabu property's in common and do a step of all of them instead of just one, especially in the beginning. -- 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

11 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1328) SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured

by Geoffrey De Smet (JIRA)

SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured -------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-1328 URL: http://jira.jboss.com/jira/browse/JBRULES-1328 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Because AbstractAccepter references LocalSearchSolver references the drools RuleBase references stuff that isn't Serializable... -- 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

11 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (SECURITY-129) Client Delegation

by Darran Lofthouse (JIRA)

Client Delegation ----------------- Key: SECURITY-129 URL: http://jira.jboss.com/jira/browse/SECURITY-129 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Web browser can delegate to the server being called so same credentials can be used for further calls. Delegation using GSSAPI, WS-Kerberos, credential propagation for EJB calls etc.. -- 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

11 years, 9 months

2
13
0 / 0

[JBoss JIRA] Created: (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

Watch org.jboss.test.remoting.stream.StreamingTestCase for failures ------------------------------------------------------------------- Key: JBREM-988 URL: http://jira.jboss.com/jira/browse/JBREM-988 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.1.Beta org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- 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

11 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (SECURITY-145) Review supported Mech types - currently only Kerberos V5

by Darran Lofthouse (JIRA)

Review supported Mech types - currently only Kerberos V5 -------------------------------------------------------- Key: SECURITY-145 URL: http://jira.jboss.com/jira/browse/SECURITY-145 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse e.g. Should and could we support Kerberos V5 legacy? -- 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

11 years, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (SECURITY-356) Log a meaningful error when browser uses Kerberos5 GSSAPI and not SPNEGO

by Darran Lofthouse (JIRA)

Log a meaningful error when browser uses Kerberos5 GSSAPI and not SPNEGO ------------------------------------------------------------------------ Key: SECURITY-356 URL: https://jira.jboss.org/jira/browse/SECURITY-356 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2.0.3.GA Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2.0.4.GA This can be identified by checking the OID parsed in NegTokenInitDecoder.decode() and verifying that it is the OID for SPNEGO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5

by Matt Wringe (JIRA)

jars are not loaded from the lib directory of a sar in JBoss AS 5 ----------------------------------------------------------------- Key: JBAS-5900 URL: https://jira.jboss.org/jira/browse/JBAS-5900 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.CR2 Reporter: Matt Wringe Assignee: Scott M Stark Attachments: testsar.tar.gz In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar. On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5. Steps to reproduce: 1) take zip attached to this report. 2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException 3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue. test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

5
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2009