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

Bug 141417

Summary:	Provide public APIs for obtaining Bundle and StorageHook
Product:	[Eclipse Project] Equinox	Reporter:	Samson Wai <samwai>
Component:	Framework	Assignee:	equinox.framework-inbox <equinox.framework-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	karla.callaghan, simon_kaegi, suwanda
Version:	3.2
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	126585

Description Samson Wai

2006-05-11 16:27:18 EDT

The Integrated Agent Controller (IAC) from the TPTP project is using the below classes:

org.eclipse.osgi.framework.internal.core.BundleFragment
org.eclipse.osgi.framework.internal.core.BundleHost
org.eclipse.osgi.internal.baseadaptor.BaseStorageHook

Some of the methods used are:
- getBundleData() from AbstractBundle class, which is used to resolve plugin inter-dependencies
- getBundleStore() from BaseStorageHook class, which is used to locate the directory which the DLLs from plugins are unpacked

These are marked as "internal" classes and I am discouraged to use them in my code. However, I cannot find the "public" correspondence of those classes. I need the above classed for resolving the JAR ad DLL files provided by a bundle as well as its dependent bundles.

The reason I wanted to locate the DLL (such as the SWT ones) is that the IAC is going to launch an external program (such as java.exe, or any arbitrary native executables) which will eventually trying to load the DLL's. The IAC itself does have some DLL's packaged under its own plugin/fragment and use the "Bundle-NativeCode" keyword in the manifest file for locating them during plugin load time. But when IAC launches another executable, it needs to know where physically these DLL's are in order to populate the PATH environment for the launched process.

One example is the TPTP manual test client, which requires the TPTP Execution Framework and the SWT plugins and thus also requires their DLL's in the PATH environment when launched. The IAC is currently using those internal APIs for resolving the fully-qualified paths of the SWT JAR/DLL files and add them to the CLASSPATH/PATH environment for the launched process.

TPTP bug 126585 is depending on this.

Comment 1 Simon Kaegi

2006-05-11 17:07:22 EDT

Tom suggested an approach for at least the on disk DLL locating portion here.
http://www.eclipse.org/newsportal/article.php?id=1751&group=eclipse.technology.equinox#1751

Did that approach work?

For the other issue where you're using BundleData to help resolve bundle inter-dependencies, are you just referring to accessing data in the manifest?

Comment 2 Samson Wai

2006-05-11 17:36:36 EDT

Regarding Tom's approach of getting on-disk files, I haven't tried it in my code but it looks promising. I will give that a shot.

For the BundleData, on top of getting the plugin dependencies, I will need the fully qualified path pointing to all the jars which a plugin provides. For example, I am using the "getBundleFile()" and the "getClassPath()" methods from the BaseData (BaseData implements BundleData, which I can get from calling "getBundleData()" from BundleFragment or BundleHost). The "getBundleFile()" method is used if the plugin is a jar, whlie "getClassPath()" is used when the plugin is a directory. Accessing the manifest in the plugin-as-jar case may or maynot be able to get the jar name out of it, especially the jar name now contains Bundle-Version as well.

I think accessing the manifest is the first step of getting those jar names.

Comment 3 Thomas Watson

2007-03-29 17:21:58 EDT

Exposing these as API will lock us into a particular implementation of the OSGi Framework.

For locating DLLs you should be able to use the approach I outlined in the newsgroup link from comment 1.

You should also be able to use a similar approach to finding the jar files that are from the Bundle-ClassPaths.

Comment 4 Paul Slauenwhite

2009-06-30 09:35:18 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 originator of this enhancement/defect has an inactive Bugzilla account 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.

Comment 5 Paul Slauenwhite

2009-06-30 09:51:22 EDT

This enhancement/defect was mistaken closed as part of the TPTP 4.6 Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes) since the originator of this enhancement/defect has an inactive Bugzilla account.  If this enhancement/defect is still unresolved and reproducible, please re-open.