April 2010 - jboss-remoting-issues

[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, 11 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, 11 months

1
9
0 / 0

[JBoss JIRA] Created: (JBREM-1219) Update remoting guide for "generalizeSocketException"

by Justin Bertram (JIRA)

Update remoting guide for "generalizeSocketException" ----------------------------------------------------- Key: JBREM-1219 URL: https://jira.jboss.org/jira/browse/JBREM-1219 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: docs Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Justin Bertram Per https://jira.jboss.org/jira/browse/JBREM-1146 the remoting guide needs to be updated to document the "generalizeSocketException" parameter. -- 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, 5 months

2
4
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, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1191) Support org.jboss.security.ssl.JaasSecurityDomainSocketFactory for SSL protocols when the client is a JBoss Application Server

by Ben Schofield (JIRA)

Support org.jboss.security.ssl.JaasSecurityDomainSocketFactory for SSL protocols when the client is a JBoss Application Server ------------------------------------------------------------------------------------------------------------------------------ Key: JBREM-1191 URL: https://jira.jboss.org/jira/browse/JBREM-1191 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Affects Versions: 2.5.2.SP2 (Flounder) Environment: Server and Client are instances of JBoss EAP 5.x or above. Reporter: Ben Schofield The JBoss Application Server uses JaasSecurityDomains for creating KeyManager and TrustManagers. When one JBoss instance is making a call to another JBoss instance which uses remoting such as a remote EJB3 call, then JaasSecurityDomains could be used to load key and trust stores on the client when negotiation SSL. The JBoss code base already defines a SSLSocketFactory to do this. (org.jboss.security.ssl.JaasSecurityDomainSocketFactory) The solution could be as simple as supporting something similar to Remoting.SOCKET_FACTORY_CLASS_NAME which instantiates a SocketFactory on the client side. A new flag Remoting.SSLSOCKET_FACTORY_CLASS_NAME could be used to instantiate a javax.net.ssl.SSLSocketFactory like org.jboss.security.ssl.JaasSecurityDomainSocketFactory. Supporting this feature would free JBoss from having to share key and trust stores with enterprise applications that use the standard javax.net.ssl.* properties to locate and load their key and trust stores. -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1218) ConnectionValidator.isValid should be volatile

by Ron Sigal (JIRA)

ConnectionValidator.isValid should be volatile ---------------------------------------------- Key: JBREM-1218 URL: https://jira.jboss.org/jira/browse/JBREM-1218 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP2 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP3 (Flounder), 2.2.3.SP3 org.jboss.remoting.ConnectionValidator's variable isValid is set in run(), which runs in one thread, and is read in ConnectionValidator.WaitOnConnectionCheckTimerTask.run(), which runs in another thread. After ConnectionValidator.run() sets isValid, is calls notifyAll() on a lock, which wakes up WaitOnConnectionCheckTimerTask.run(), which then looks at the value of isValid. It's possible for the most recent value of isValid to not yet be visible to WaitOnConnectionCheckTimerTask.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

14 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1187) Release 2.2.3.SP2

by Ron Sigal (JIRA)

Release 2.2.3.SP2 ----------------- Key: JBREM-1187 URL: https://jira.jboss.org/jira/browse/JBREM-1187 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2 -- 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] Commented: (JBREM-827) Define a management interface for JBoss Remoting

by Trustin Lee (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] Trustin Lee commented on JBREM-827: ----------------------------------- I've just checked in the revised interfaces. ServiceInfo has been replaced with ServiceMXBean. Each registered services will have its own ServiceMXBean. I added requestCounter to it so that the number of requests can be tracked in per-service manner. EndpointMXBean now has connectionCounter as proposed previously. It also exposes the list of ObjectNames of services and connections. ConnectionMXBean and ServiceMXBean also exposes the ObjectName of the EndpointMXBean they belong to. For IP-based transports, we could include the endpoint address in the MBean object name? > Define a management interface for JBoss Remoting > ------------------------------------------------ > > Key: JBREM-827 > URL: https://jira.jboss.org/jira/browse/JBREM-827 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: r3 core > Reporter: David Lloyd > Assignee: Trustin Lee > Fix For: 3.1.0.Beta3 > > -- 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
0
0 / 0

[JBoss JIRA] Created: (JBREM-1217) Provide a Remoting context which can be retrieved statically

by David Lloyd (JIRA)

Provide a Remoting context which can be retrieved statically ------------------------------------------------------------ Key: JBREM-1217 URL: https://jira.jboss.org/jira/browse/JBREM-1217 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core, r3 core: api Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.1.0.Beta3 The context should be usable for determining the current connection and/or endpoint during marshalling operations. -- 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
0
0 / 0

[JBoss JIRA] Created: (JBREM-1216) Connection should be accessible from Client

by David Lloyd (JIRA)

Connection should be accessible from Client ------------------------------------------- Key: JBREM-1216 URL: https://jira.jboss.org/jira/browse/JBREM-1216 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: api Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.1.0.Beta3 In some cases (particularly, proxy serialization), it is desirable to get the Connection associated with a Client. It logically follows that all Clients must have Connections. Thus, a getter (getConnection) should be added to Client, and the methods which allow a Client which bypasses a Connection should be removed (these cases should be ported to use the "local:" protocol). -- 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
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2010