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