March 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1110) InvokerLocator.getParameters() should not return null

by Ron Sigal (JIRA)

InvokerLocator.getParameters() should not return null ----------------------------------------------------- Key: JBREM-1110 URL: https://jira.jboss.org/jira/browse/JBREM-1110 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 Currently, org.jboss.remoting.InvokerLocator.getParameters() will return null if the URL has no parameters. It's safer to return an empty Map than null. -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1081) Fix NPE in ServerInvokerCallbackHandler

by Ron Sigal (JIRA)

Fix NPE in ServerInvokerCallbackHandler ---------------------------------------- Key: JBREM-1081 URL: https://jira.jboss.org/jira/browse/JBREM-1081 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.callback.ServerInvokerCallback is shut down by a call to ServerInvokerCallbackHandler.destroy(), the variables callBackClient and callbackStore are set to null. If ServerInvokerCallbackHandler.handleCallback() is called subsequently (which can happen if destroy() is called by ServerInvokerCallbackHandler.handleConnectionException() and the application has not yet been informed about a connection failure), then, since callbackClient == null, it looks like pull callbacks are configured, but, since callbackStore == null, a NullPointerException is thrown in ServerInvokerCallbackHandler.persistCallback(). -- 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

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1085) Reduce log level of ServerSocketWrapper.close() log messages

by Ron Sigal (JIRA)

Reduce log level of ServerSocketWrapper.close() log messages ------------------------------------------------------------ Key: JBREM-1085 URL: https://jira.jboss.org/jira/browse/JBREM-1085 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The log messages "wrote CLOSING" and "unable to writing CLOSING byte" in org.jboss.remoting.transport.socket.ServerSocketWrapper.close() are too noisy and should be reduced to TRACE level. -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBREM-139) need automated test for servlet server invoker

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-139?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-139: ---------------------------- Fix Version/s: 2.5.0.SP3 (Flounder) (was: 2.5.0.SP2 (Flounder) ) > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: https://jira.jboss.org/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final, 2.5.0.SP2 (Flounder) , 2.2.2.SP11 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1039) Release 2.2.2.SP11

by Ron Sigal (JIRA)

Release 2.2.2.SP11 ------------------ Key: JBREM-1039 URL: https://jira.jboss.org/jira/browse/JBREM-1039 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1072) Synchronize access to static maps in MarshalFactory

by Ron Sigal (JIRA)

Synchronize access to static maps in MarshalFactory --------------------------------------------------- Key: JBREM-1072 URL: https://jira.jboss.org/jira/browse/JBREM-1072 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP10 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11, 2.5.0.SP3 (Flounder) Users have experienced the exception org.jboss.remoting.marshal.InvalidMarshallingResource: Can not find a valid marshaller for data type: serializable at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:79) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107) This is strange, since a marshaller for the datatype "serializable" is hardcoded in org.jboss.remoting.marshal.MarshalFactory. However, access to the static Map marshallers is not synchronized, so it's possible that one subsystem is adding a marshaller (e.g., EJB2, JBossMessaging) at the same time that EJB3 is trying to extract a marshaller. The same observation applies to unmarshallers. -- 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

15 years, 2 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2009