[JBoss JIRA] Created: (JBREM-799) Add a separate timeout parameter for callback clients, part 2
by Ron Sigal (JIRA)
Add a separate timeout parameter for callback clients, part 2
-------------------------------------------------------------
Key: JBREM-799
URL: http://jira.jboss.com/jira/browse/JBREM-799
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
This issue is a continuation of JBREM-765 "Add a separate timeout parameter for callback clients".
The changes have been applied to branches remoting_2_2_0_GA and remoting_2_x, but unit tests exist only for transports socket and bisocket. A unit test should be written for the RMI transport as well. However, no additional changes will be made to Remoting 2.2.2.GA, so this issue is introduced for 2.4.0.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBREM-851) In LeasePinger and TimerUtil replace Timer if it has shut down
by Ron Sigal (JIRA)
In LeasePinger and TimerUtil replace Timer if it has shut down
--------------------------------------------------------------
Key: JBREM-851
URL: http://jira.jboss.com/jira/browse/JBREM-851
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
When all of the TimerTasks running in a java.util.TimerTask have shut down, the TImer will also shut down, at which point it will accept no more TimerTasks. There are places in Remoting where there should be a test which will create a new Timer the attempt to schedule a TimerTask results in an exception.
Two places the problem exists:
1. org.jboss.remoting.LeasePinger, and
2. org.jboss.remoting.util.TimerUtil.
A similar problem is described in JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer"
Reported by James on Remoting forum.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBREM-804) Enable HTTPClientInvoker to accept NO_THROW_ON_ERROR configuration by way of InvokerLocator
by Ron Sigal (JIRA)
Enable HTTPClientInvoker to accept NO_THROW_ON_ERROR configuration by way of InvokerLocator
-------------------------------------------------------------------------------------------
Key: JBREM-804
URL: http://jira.jboss.com/jira/browse/JBREM-804
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.GA
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
Currently, the value for the parameter org.jboss.remoting.transport.http.HTTPMetadataConstants.NO_THROW_ON_ERROR in org.jboss.remoting.transport.http.HTTPClientInvoker is configurable only by way of the invocation metadata map passed to org.jboss.remoting.Client.invoke().
However, for EJB3 invocations, the Client is created by the EJB3 proxy (org.jboss.aspects.remoting.InvokeRemoteInterceptor, in particular) and is not accessible by application code. If HTTPClientInvoker checked the InvokerLocator for this parameter, then it could be configured declaratively in the EJB3 jboss-service.xml file.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBAS-4943) jboss-ds_1_5.dtd is wrong
by Michael Lipp (JIRA)
jboss-ds_1_5.dtd is wrong
-------------------------
Key: JBAS-4943
URL: http://jira.jboss.com/jira/browse/JBAS-4943
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation, JCA service
Affects Versions: JBossAS-4.0.5.GA
Environment: Any
Reporter: Michael Lipp
Assigned To: Norman Richards
The jboss-ds_1_5.dtd (as distributed in docs/dtd/) is wrong or not up-to-date (and there is no newer version and no out-of-date mark). As has been pointed out by Adrian Brock in JBAS-4942, it is possible to specify a loader-repository like this:
<connection-factories>
<!-- The loader repository name used by the ear -->
<loader-repository>jboss.test:loader=JavaClassIsolation</loader-repository>
<tx-connection-factory>
<!-- The "path" to the rar -->
<rar-name>some.ear#some.rar</rar-name>
<etc/>
</tx-connection-factory>
</connection-factories>
... although this is not compliant with the DTD!
Keeping the DTD up-to-date would avoid unnecessary bug reports and/or forum questions because looking at the DTD is the first step in finding out how to configure required behavior.
--
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
16 years, 11 months