[JBoss JIRA] Updated: (JBREM-238) JBossRemoting testsuite needs to generate artificats in the output folder
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-238?page=all ]
Ron Sigal updated JBREM-238:
----------------------------
Fix Version/s: 2.4.0.CR1 (Pinto)
(was: 2.4.0.Beta1 (Pinto))
Assignee: Ron Sigal
> JBossRemoting testsuite needs to generate artificats in the output folder
> -------------------------------------------------------------------------
>
> Key: JBREM-238
> URL: http://jira.jboss.com/jira/browse/JBREM-238
> Project: JBoss Remoting
> Issue Type: Task
> Components: general
> Reporter: Adrian Brock
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> The JBossRemoting testsuite is dumping its artifacts in the root of the project rather than output.
> e.g. cvs diff:
> ? MultiThreadPerformanceTestCase_benchmark.txt
> ? MultiThreadedRMIPerformanceTestCase_benchmark.txt
> ? PerformanceClientSideTestCase_benchmark.txt
> ? PerformanceServerSideTestCase_benchmark.txt
> ? PerformanceTestCase_benchmark.txt
> ? RMIPerformanceTestCase_benchmark.txt
> ? data
> ? debug_output.log
> ? start_1132237128739.txt
> ? start_1132237129627.txt
> etc.
> Eventually somebody is going to commit these to cvs by mistake.
--
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
18 years, 3 months
[JBoss JIRA] Updated: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ]
Ron Sigal updated JBREM-167:
----------------------------
Fix Version/s: 2.4.0.CR1 (Pinto)
(was: 2.4.0.Beta1 (Pinto))
Assignee: (was: Tom Elrod)
> RMI Invoker does not use true remoting marshalling/unmarshalling
> ----------------------------------------------------------------
>
> Key: JBREM-167
> URL: http://jira.jboss.com/jira/browse/JBREM-167
> Project: JBoss Remoting
> Issue Type: Bug
> Components: transport
> Affects Versions: 1.2.0 final
> Reporter: Tom Elrod
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server.
--
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
18 years, 3 months
[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
18 years, 3 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
18 years, 3 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
18 years, 3 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
18 years, 3 months