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

Bug 86557

Summary:

(Plat) Remote log import does not work due to runtime.jar

Product:

z_Archived

Reporter:

Dave Smith <smith>

Component:

TPTP

Assignee:

Samson Wai <samwai>

Status:

CLOSED FIXED

QA Contact:

Severity:

blocker

Priority:

CC:

paulslau, scott.schneider

Version:

unspecified

Keywords:

Documentation

Target Milestone:

---

Hardware:

OS:

Windows 2000

Whiteboard:

closed460

Attachments:

Description	Flags
serviceconfig.xml	none
pluginconfig.xml (execution)	none
pluginconfig.xml (collection framework)	none

Description Dave Smith

2005-02-24 15:48:31 EST

Remote log does not work because org.eclipse.core.runtime runtime.jar is 
included in the global classpath of the Agent controller environment.  The GLA 
code assumes runtime.jar is not on the classpath when running outside of 
Eclipse.  A different code path is followed when classes in runtime.jar are 
found which results in incorrectly behaviour in the remote import scenario.

I understand the runtime.jar file is required by some of the Test Project 
plugins.  However, runtime.jar should not be added to the global classpath 
where it is included by all applications launched by the application.  
runtime.jar should be added to the application specific classpath for the 
applications that require it.

Comment 1 Samson Wai

2005-02-25 08:03:33 EST

This jar is used by the test plugins. I recommend moving the runtime.jar to a 
local application scope instead of the RAC global scope.

Comment 2 Samson Wai

2005-02-25 08:33:22 EST

I think we should do something like this:

In the RAC's base config file (serviceconfig.xml) we set the env pointing to 
their corresponding jar files:

<Variable name="CLASSPATH_ORG_APACHE_JAKARTA_COMMONS_LOGGING".../>
<Variable name="CLASSPATH_ORG_ECLIPSE_CORE_RUNTIME".../>
<Variable name="CLASSPATH_ORG_ECLIPSE_EMF_COMMON".../>
<Variable name="CLASSPATH_ORG_ECLIPSE_EMF_ECORE".../>
<Variable name="CLASSPATH_ORG_ECLIPSE_EMF_ECORE_XMI".../>
<Variable name="CLASSPATH_ORG_JUNIT".../>

Inside each of the application definition, we set the application dependent 
classpath as:

<Variable name="CLASSPATH" value="%CLASSPATH_ORG_ECLIPSE_CORE_RUNTIME%" 
position="append"/>

and so on.

This will make sure jars are not added to the global classpath unknowingly and 
affect applications in an unknown way.

How do you guys like this idea?

Comment 3 Samson Wai

2005-02-28 08:23:49 EST

I am proposing yet another way of fixing the problem. Please see the attached 
config files.

Each plugin can push its jar files onto its own environment "CLASSSPATH_<Plugin 
Name>". Application which depends on those set of jar files can set its 
application specific CLASSPATH pointing to those environment variables. This 
way the global CLASSPATH will be a lot cleaner.

Do you agree with this approach?

Comment 4 Samson Wai

2005-02-28 08:24:32 EST

Created attachment 18355 [details]
serviceconfig.xml

Comment 5 Samson Wai

2005-02-28 08:25:11 EST

Created attachment 18356 [details]
pluginconfig.xml (execution)

Comment 6 Samson Wai

2005-02-28 08:25:57 EST

Created attachment 18357 [details]
pluginconfig.xml (collection framework)

Comment 7 Scott E. Schneider

2005-03-04 15:05:01 EST

Samson, I like this approach, making the plug-ins responsible for providing 
these constants.  This seems like a clean approach in my opinion and will 
solve the defect's issues once we modify the test application classpaths to 
point to the runtime.jar and remove it from the global classpath.

Comment 8 Dave Smith

2005-03-16 17:02:16 EST

This is blocking Log Import testcases.

Comment 9 Samson Wai

2005-03-17 08:12:00 EST

This will require some documentation on how to write this kind of plugin 
configuration.

Comment 10 Samson Wai

2005-03-17 10:29:21 EST

Fix committed to the following config generators:
- o.e.h.execution
- o.e.h.logging.core
- o.e.t.platform.agentcontroller
- o.e.t.platform.collection.framework

Comment 11 Samson Wai

2005-04-06 15:27:50 EDT

Fix already committed.

Comment 12 Paul Slauenwhite

2009-06-30 07:49:15 EDT

As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.