January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAOP-467) Serialize container proxies out of vm

by Kabir Khan (JIRA)

Serialize container proxies out of vm ------------------------------------- Key: JBAOP-467 URL: http://jira.jboss.com/jira/browse/JBAOP-467 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.CR1 -- 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, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (HIBERNATE-75) Wrong implementation of method retainAll in PersistentSet

by Andrey Peristyy (JIRA)

Wrong implementation of method retainAll in PersistentSet --------------------------------------------------------- Key: HIBERNATE-75 URL: http://jira.jboss.com/jira/browse/HIBERNATE-75 Project: Hibernate Issue Type: Bug Reporter: Andrey Peristyy Assigned To: Steve Ebersole The method from org.hibernate.collection.PersistentSet adds all elements from coll to the current set. But it must retains only the elements in this set that are contained in the specified collection. As it stated in javadoc for java.util.Set. Method from PersistentSet: public boolean retainAll(Collection coll) { initialize( true ); if ( set.addAll( coll ) ) { dirty(); return true; } else { return false; } } Correct implementation from java.util.AbstractCollection: public boolean retainAll(Collection<?> c) { boolean modified = false; Iterator<E> e = iterator(); while (e.hasNext()) { if (!c.contains(e.next())) { e.remove(); modified = true; } } return modified; } -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-1808) Expose PreparedStatementCache via JMX

by Vicky Kak (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1808?page=all ] Vicky Kak reassigned JBAS-1808: ------------------------------- Assignee: Vicky Kak (was: Weston Price) > Expose PreparedStatementCache via JMX > ------------------------------------- > > Key: JBAS-1808 > URL: http://jira.jboss.com/jira/browse/JBAS-1808 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Scott M Stark > Assigned To: Vicky Kak > Priority: Minor > > The PreparedStatementCache cache in the JCA layer has no exposure via jmx. Info like the min, max, avg, etc. number of prepared statements are in the cache would be useful. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1445) Merge in BRMSv2 changes

by Michael Neale (JIRA)

Merge in BRMSv2 changes ----------------------- Key: JBRULES-1445 URL: http://jira.jboss.com/jira/browse/JBRULES-1445 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale Fix For: 5.0.0-M1 -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1848) Portal CAS integration does not invalidate the CAS token

by Sohil Shah (JIRA)

Portal CAS integration does not invalidate the CAS token -------------------------------------------------------- Key: JBPORTAL-1848 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1848 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: Identity-1.0, 2.6.2 Final Reporter: Sohil Shah Fix For: 2.6.4 Final, Identity-1.1 When a user logs out of Portal, the CAS token still stays alive and upon next Portal request, performs automatic authentication. End result is, user can never log out -- 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, 5 months

1
4
0 / 0

[JBoss JIRA] Updated: (JBREM-510) SSLSocketBuilder should require a SocketFactory in server mode to have a keystore.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-510?page=all ] Ron Sigal updated JBREM-510: ---------------------------- Fix Version/s: 2.4.0.CR1 (Pinto) (was: 2.4.0.Beta1 (Pinto)) > SSLSocketBuilder should require a SocketFactory in server mode to have a keystore. > ---------------------------------------------------------------------------------- > > Key: JBREM-510 > URL: http://jira.jboss.com/jira/browse/JBREM-510 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > SSLSocketBuilder needs to > 1. allow a ServerSocketFactory in client mode to not have a keystore, and > 2. require a SocketFactory in server mode to have a keystore. > Part 1 is fixed as of 6/20/06, as part of changes made for JBREM-368/JBREM-491. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-522) When Client.addListener() creates a callback Connector for an SSL transport, the SSLServerSocket should be put in client mode.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-522?page=all ] Ron Sigal updated JBREM-522: ---------------------------- Fix Version/s: 2.4.0.CR1 (Pinto) (was: 2.4.0.Beta1 (Pinto)) > When Client.addListener() creates a callback Connector for an SSL transport, the SSLServerSocket should be put in client mode. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBREM-522 > URL: http://jira.jboss.com/jira/browse/JBREM-522 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.CR1 (Pinto) > > > Just as ServerInvokerCallbackHandler configures callback client invoker SSLSocketFactorys to put their SSLSockets in server mode, Client should configure callback server invoker SSLServerSocketFactorys to put their SSLServerSockets in client mode. > This is the inverse of JBREM-368/JBREM-491. > It is also related to JBREM-521. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-521) Organize configuration of client side socket/server socket factories and server side socket/server socket factories.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-521?page=all ] Ron Sigal updated JBREM-521: ---------------------------- Fix Version/s: 2.4.0.CR1 (Pinto) (was: 2.4.0.Beta1 (Pinto)) > Organize configuration of client side socket/server socket factories and server side socket/server socket factories. > -------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-521 > URL: http://jira.jboss.com/jira/browse/JBREM-521 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.CR1 (Pinto) > > > JBREM-520 concerns organizing configuration of socket factories and sever socket factories in the context of a Connector. This issue concerns the more general problem of organizing the configuration of factories in the contexts of both Clients and Connectors. There are two aspects of configuration through the Client: > 1) configuration of socket factories used by client invokers, and > 2) configuration of server socket factories used by server invokers in callback Connectors created by calls to Client.addListener(). > and these need to be aligned with the two aspects of configuration through the Connector: > 1) configuration of server socket factories used by server invokers, and > 2) configuration of socket factories used by callback client invokers created on the server side in response to calls to Client.addListener(). > For example, there should be a Client.setServerInvoker() 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-373) clean up lease handling on server side

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-373?page=all ] Ron Sigal updated JBREM-373: ---------------------------- Fix Version/s: 2.4.0.CR1 (Pinto) (was: 2.4.0.Beta1 (Pinto)) Assignee: (was: Tom Elrod) > clean up lease handling on server side > -------------------------------------- > > Key: JBREM-373 > URL: http://jira.jboss.com/jira/browse/JBREM-373 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta1 > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > In issue JBREM-372, put in a hack for cleaning up lease map within the ServerInvoker where would pass the clientLeases variable from ServerInvoker to the constructor of Lease. Then when LeaseTimerTask fired and event that client was dead, would remove itself from the ServerInvoker's lease map (by client id). > Should not have to pass in the lease map from ServerInvoker. Maybe better approach would be to have ServerInvoker add itself as listener, so when the connection failure event fired, it would be notified and remove the lease from the clientLeases map itself. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-302) remote dynamic marshall loading not working on linux

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-302?page=all ] Ron Sigal updated JBREM-302: ---------------------------- Fix Version/s: 2.4.0.CR1 (Pinto) (was: 2.4.0.Beta1 (Pinto)) Assignee: (was: Tom Elrod) > remote dynamic marshall loading not working on linux > ---------------------------------------------------- > > Key: JBREM-302 > URL: http://jira.jboss.com/jira/browse/JBREM-302 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 beta > Environment: Linux, JDK 1.4 > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > Attachments: SocketMarshallerLoadingTestCase-out.txt > > > The following test cases fail on Linux (and not on Windows): > org.jboss.test.remoting.marshall.dynamic.remote.http.HTTPMarshallerLoadingTestCase > org.jboss.test.remoting.marshall.dynamic.remote.socket.SocketMarshallerLoadingTestCase > Test output for SocketMarshallerLoadingTestCase attached, but says that server can not find the class: > org.jboss.test.remoting.marshall.dynamic.remote.socket.TestObject > However, confirmed that this class is within the jboss-remoting-loading-tests.jar, which is being set on the classpath (as shown in the output log). -- 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, 5 months

1
0
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 January 2008