September 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1163 URL: https://jira.jboss.org/jira/browse/JBREM-1163 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- 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

12 years, 4 months

1
11
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

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- 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

13 years

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-1074) Config Guide should clarify the HTTP transport vs Servlet

by Andrew Oliver (JIRA)

Config Guide should clarify the HTTP transport vs Servlet --------------------------------------------------------- Key: JBREM-1074 URL: https://jira.jboss.org/jira/browse/JBREM-1074 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andrew Oliver http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html describes changing to use HTTP as a transport. Meaning JBoss remoting launches its own HTTP server. This is probably a pretty esoteric configuration and most people are probably looking for this: http://www.jboss.org/community/docs/DOC-9632 instead. The guide should clarify WHAT that is and where to find what you're probably REALLY looking for. (you probably don't want to run on some weird port if you're using HTTP and most installs probably run WITH tomcat which means you need to run through TC or have a totally separate IP which is pretty hard to do in most environments) -- 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

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1144) Extend connection identity to server side

by Ron Sigal (JIRA)

Extend connection identity to server side ----------------------------------------- Key: JBREM-1144 URL: https://jira.jboss.org/jira/browse/JBREM-1144 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client. In other words, clients were assigned an identity. This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced. -- 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

13 years, 10 months

1
9
0 / 0

[JBoss JIRA] Created: (JBREM-981) CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator

by Ron Sigal (JIRA)

CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator ------------------------------------------------------------------------------------------------------------- Key: JBREM-981 URL: http://jira.jboss.com/jira/browse/JBREM-981 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.GA >From Galder: Consider <servlet> <servlet-name>Ejb3ServerInvokerServlet</servlet-name> <description>The ServerInvokerServlet receives requests via HTTP protocol from within a web container and passes it onto the ServletServerInvoker for processing. </description> <servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class> <init-param> <param-name>locatorUrl</param-name> <param-value>servlet://${jboss.bind.address}:8080/unified-invoker/Ejb3ServerInvokerServlet</param-value> <description>The servlet server invoker</description> </init-param> <load-on-startup>1</load-on-startup> </servlet> Now, let's say you bind to 0.0.0.0. You'll get an exception like this: 13:39:26,856 ERROR [ContainerBase] Servlet /unified-invoker threw load() exception javax.servlet.ServletException: Can not find servlet server invoker with same locator as specified (servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.getInvokerFromInvokerUrl(ServerInvokerServlet.java:198) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.init(ServerInvokerServlet.java:66) The problem arises from the fact that Remoting is trying to compare: servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet with servlet://localhost.localdomain:8080/unified-invoker/Ejb3ServerInvokerServlet So either, ServerInvokerServlet should call ServerInvoker.validateLocator() with locatorUrl, take the return of that and compare that with the list of locators. Or validateLocator() is modified to have the real original host passed to the InvokerLocator constructor, rather than the transformed or newHost. -- 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

14 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1080) Add support for future tasks to RequestContext

by David Lloyd (JIRA)

Add support for future tasks to RequestContext ---------------------------------------------- Key: JBREM-1080 URL: https://jira.jboss.org/jira/browse/JBREM-1080 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Fix For: 3.1.0.Beta1 Right now, the RequestContext keeps track of tasks and threads being used to process a request. If all tasks complete and no reply is sent, it makes sure that the requesting party receives an exception indicating that a reply was never sent. However, if the request listener may wish interact with another framework which uses some asynchronous callback mechanism, from which a reply is to be sent. In this case, all tasks terminate but the reply might still be sent. To solve this problem, RequestContext needs a method which can wrap a Runnable (or similar) with some type of cancellable Runnable or task object, which can then be called by other frameworks as needed later on. The RequestContext wouldn't consider a request "dead" until all tasks completed and all such wrapped Runnables have also been completed or GC'd. -- 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

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1016) Increase Basic Protocol Version

by David Lloyd (JIRA)

Increase Basic Protocol Version ------------------------------- Key: JBREM-1016 URL: https://jira.jboss.org/jira/browse/JBREM-1016 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA Increase the protocol version by one. Clone this issue for every minor release. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-929) Secure remote classloading

by David Lloyd (JIRA)

Secure remote classloading -------------------------- Key: JBREM-929 URL: http://jira.jboss.com/jira/browse/JBREM-929 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it. Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came. -- 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

14 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-994) Modify JRPP to run over SSH

by David Lloyd (JIRA)

Modify JRPP to run over SSH --------------------------- Key: JBREM-994 URL: http://jira.jboss.com/jira/browse/JBREM-994 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA -- 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

14 years, 9 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues September 2009