Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 126038

Summary:	Generic Recording framework classpath needs to use absolute classpaths
Product:	z_Archived	Reporter:	Ashish Mathur <ashishkumarmathur>
Component:	TPTP	Assignee:	Mark D Dunn <mddunn>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P1	CC:	mddunn, paulslau
Version:	unspecified	Keywords:	plan
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	111346
Bug Blocks:

Description Ashish Mathur

2006-02-01 11:46:47 EST

In trying to extend the generic recording framework to create a recorder, it seems that when the recorder is kicked off with the classpath provided by the extended recorder, the gicen classpath is not converted to absolute path, although the API to do that is being called. As a result, the recorder fails to start when it doesn't find the RecorderAgent in the classpath.

The jars in the classpath are of the for 
Recorder_deploy/myrecorder.jar
and are copied into the $user.home folder. However, the current working directory of the recorder is not $user.home.

This path need sto be an absolute path to the jars.

Jeff Nevicosi has more information about this

Comment 1 Mark D Dunn

2006-02-01 11:50:55 EST

Changed priority to p1 and set milestone to 4.2 iteration 1.

Comment 2 Mark D Dunn

2006-02-01 17:10:31 EST

Jeff N. tells me this only occurs when using the IAC . the absolute path function was added to the file transfer system used in the RAC only.  This capability is supposed to be included in the IAC during 4.2 . I will find the associated bugzilla that covers this functionality being added to the IAC and include it in this bugzilla.

Comment 3 Mark D Dunn

2006-02-02 16:10:37 EST

The resolution of this problem is actually to incorporate the new file systems services into the IAC (it is already in the RAC).  This is covered with bugzilla 111346.  I will make this bug dependent on 111346 .

Comment 4 Mark D Dunn

2006-02-10 10:22:16 EST

Since this is for the IAC and the downstream product that reported this problem will not use the IAC, this is downgraded to major.

Comment 5 Mark D Dunn

2006-02-17 10:57:00 EST

Set target to 'future' since the bugzilla that actually covers this (111346) has a target of future.

Comment 6 Mark D Dunn

2007-01-17 11:42:16 EST

added estimate to include integration testing.

Comment 7 Paul Slauenwhite

2007-01-26 08:45:11 EST

Will be included in the 4.4 plan.  

Please target to a 4.4 iteration.

Comment 8 Mark D Dunn

2007-03-14 17:25:13 EDT

The defect this depends on is targeted for future.  Therefore, I am targeting this to future.

Comment 9 jkubasta

2007-04-04 19:40:50 EDT

Added plan just to track

Comment 10 Paul Slauenwhite

2007-04-05 10:01:09 EDT

Fixing the priority.

Comment 11 Paul Slauenwhite

2007-05-04 11:46:27 EDT

Mark, we cannot defer in-plan defects until we make a request to the PMC.

Comment 12 Paul Slauenwhite

2007-05-18 16:18:24 EDT

This defect is a candidate for deferral from the 4.4 release.  If the originator has opposition, please provide an argument against this deferral.

Comment 13 Valentina Popescu

2007-05-28 14:59:29 EDT

can you assign this defect to a valid iteration

Comment 14 Paul Slauenwhite

2007-05-28 15:08:15 EDT

Assigning to i4 but this defect belongs to a block of in-plan 4.4 defects that are candidates for deferral.

Comment 15 Joe Toomey

2007-06-05 12:28:03 EDT

Based on the comments in this defect, I assert that this defect is fixed by virtue of https://bugs.eclipse.org/bugs/show_bug.cgi?id=173330 [new IAC implementation uses new AC technology, and thus the file transfer behavior is now the same.]

Marking as fixed -- submitter, please validate and close.

Comment 16 Paul Slauenwhite

2008-06-27 08:52:14 EDT

Closing by default since not closed by the originator in the 7+ months since being resolved.  

Please reopen if the issue is still present in the latest TPTP release or the resolution is not correct.