November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-298) Need ability to add transport specific info to invocation payload

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-298?page=all ] Tom Elrod updated JBREM-298: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Need ability to add transport specific info to invocation payload > ----------------------------------------------------------------- > > Key: JBREM-298 > URL: http://jira.jboss.com/jira/browse/JBREM-298 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 1.4.0 beta > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > Specific example would be to add ssl client cert from the ssl socket to the invocation payload. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-385) Need to pull the legacy invokers into remoting

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-385?page=all ] Tom Elrod updated JBREM-385: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Need to pull the legacy invokers into remoting > ---------------------------------------------- > > Key: JBREM-385 > URL: http://jira.jboss.com/jira/browse/JBREM-385 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott M Stark > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > The org.jboss.invocation.* package has dependencies on remoting, and it should just be moved into the remoting project as the legacy remoting impl. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ] Tom Elrod updated JBREM-480: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Insure reliable tests in socket invoker for unusable socket connections. > ------------------------------------------------------------------------ > > Key: JBREM-480 > URL: http://jira.jboss.com/jira/browse/JBREM-480 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set. > The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1. > On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1. > In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-63) Get rid of the legacy configuration that embeds xml parsing

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-63?page=all ] Tom Elrod updated JBREM-63: ---------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Get rid of the legacy configuration that embeds xml parsing > ----------------------------------------------------------- > > Key: JBREM-63 > URL: http://jira.jboss.com/jira/browse/JBREM-63 > Project: JBoss Remoting > Issue Type: Task > Affects Versions: 1.0.1 beta > Reporter: Scott M Stark > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > I see that the org.jboss.remoting.transport.Connector is using the legacy mechanism of using an Element configuration as an attribute and doing the xml parsing within the code. This needs to be removed and replaced with JBossXB constructs. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-369) For Connectors that support callbacks on SSL connections, there should be a unified means of configuring SSLServerSocket and callback Client SSLSocket.s.

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-369?page=all ] Tom Elrod updated JBREM-369: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > For Connectors that support callbacks on SSL connections, there should be a unified means of configuring SSLServerSocket and callback Client SSLSocket.s. > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-369 > URL: http://jira.jboss.com/jira/browse/JBREM-369 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.0.0.Beta1 > Reporter: Ron Sigal > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > Currently, the SSLServerSocket is configured by creating an SSLServerSocketFactory, e.g., by way of configuring an SSLSocketBuilder, and calling setServerSocketFactory() on the server invoker. The SSLSockets used by the Client that makes push callbacks are configured by passing a configuration Map to the Connector constructor, which is used to create a RemotingSSLSocketFactory. These should be unified. In particular, it would be nice to pass a single configuration Map to Connector(). -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-47) Dynamic classloading

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-47?page=all ] Tom Elrod updated JBREM-47: ---------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Dynamic classloading > -------------------- > > Key: JBREM-47 > URL: http://jira.jboss.com/jira/browse/JBREM-47 > Project: JBoss Remoting > Issue Type: Feature Request > Components: general > Affects Versions: 1.0.1 beta > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > Need ability for dynamic classloading to satisfy two needs. The first, is when an ejb lookup is done, and if do not have the class on the client, can download the client classes for remoting. This is much more efficient than having to serialize all these classes (as there may be many and may not even know what they are until runtime). Also, would like to add the ability for client or server to pass implementation for interfaces across the wire and if the other side does not have those classes, can load them. Once particular case when this might be needed is if using JMX sub-system, client could create custom QueryExp? implementation and pass to the server, and the server could load that class and perform the query. Will require security around 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-116) Create public and implementors javadoc

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-116?page=all ] Tom Elrod updated JBREM-116: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > Create public and implementors javadoc > -------------------------------------- > > Key: JBREM-116 > URL: http://jira.jboss.com/jira/browse/JBREM-116 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.0.2 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta1 (Bluto) > > > Need to produce javadoc for public API and for implementation API (which is subject to change). One idea would be to create seperate packages for the actual implementations, such as for the transports and marshallers, so will be easier to identify what is public and what is implementation. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-124) implement APR transport

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-124?page=all ] Tom Elrod updated JBREM-124: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) 3.0.0.Alpha1 (Otter) (was: 2.2.0.Alpha3 (Bluto)) > implement APR transport > ----------------------- > > Key: JBREM-124 > URL: http://jira.jboss.com/jira/browse/JBREM-124 > Project: JBoss Remoting > Issue Type: Task > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Critical > Fix For: 2.2.0.Beta1 (Bluto), 3.0.0.Alpha1 (Otter) > > > Need to add support of Apache APR based transport. The APR code (from tomcat-connector project) uses native code to manage threads and sockets. The end result is a much better performance using a NIO type approach where only have threads in use for processing data off the socket. When socket is idle, the threads are released and the native code will callback to activate a thread to process the data. > This effort has already been started in JBossRemoting on a branch called apr_transport. Will probably not be fully implemented till after 1.2.0 release. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-228) clustering

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-228?page=all ] Tom Elrod updated JBREM-228: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > clustering > ---------- > > Key: JBREM-228 > URL: http://jira.jboss.com/jira/browse/JBREM-228 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.4.0 beta > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Critical > Fix For: 2.2.0.Beta1 (Bluto) > > > Need to seperate out clustering service so can run outside of JBossAS and then integrate with remoting so can use common clustering service with remoting (and other projects). -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3807) Certify JBoss AS 4.0.2 with

by Brian Stansberry (JIRA)

Certify JBoss AS 4.0.2 with ---------------------------- Key: JBAS-3807 URL: http://jira.jboss.com/jira/browse/JBAS-3807 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry -- 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

17 years, 6 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2006