Home » Eclipse Projects » Equinox » Eclipse OSGi internal APIs
|
| Re: Eclipse OSGi internal APIs [message #65558 is a reply to message #65514] |
Fri, 28 April 2006 08:34   |
 Stepan Rutz
Messages: 52
Registered: July 2009 |
Member |
|
|
Hi Samson,
I have a bundle with native-libs myself. And i cannot think of any
reason why I would want to know where my dlls/.so files are unpacked.
All i want to do with a dll/so is to load it.
What makes you want to know where the dll/so file is physically located ?
Even then if you start with -clean, the configuration area is wiped and
libs are unpacked fresh, so you couldn't save anything in there, only load.
Regards,
Stepan
Samson Wai schrieb:
> Hi,
>
> Currently I am using the following classes in my TPTP Integrated Agent
> Controller code:
>
> org.eclipse.osgi.framework.internal.core.BundleFragment
> org.eclipse.osgi.framework.internal.core.BundleHost
> org.eclipse.osgi.internal.baseadaptor.BaseStorageHook
>
> 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. One example is
> that I may need to know where the SWT DLL's are unpacked under the
> Eclipse configuration directory.
>
> I have some questions:
> 1. Is there a plan to make them public? i.e. not internal
> 2. If not, is there going to be major changes on those classes in the
> upcoming releases?
>
> I will need know the answers since any changes now will impact our TPTP
> 4.2 development plan. Thanks.
>
> Regards,
>
> Samson
|
|
|
| Re: Eclipse OSGi internal APIs [message #65578 is a reply to message #65558] |
Fri, 28 April 2006 13:51 |
Samson Wai
Messages: 46
Registered: July 2009 |
Member |
|
|
Hi Stepan,
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 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 launching.
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 FQ paths of the SWT JAR/DLL files
and add them to the CLASSPATH/PATH environment for the launched process.
I think the PDE launch capability can do somewhat similar but I couldn't
find a useful sample for my use case. Any pointers on this will be very
useful.
Regards,
Samson
Stepan Rutz wrote:
> Hi Samson,
>
> I have a bundle with native-libs myself. And i cannot think of any
> reason why I would want to know where my dlls/.so files are unpacked.
> All i want to do with a dll/so is to load it.
>
> What makes you want to know where the dll/so file is physically located ?
>
> Even then if you start with -clean, the configuration area is wiped and
> libs are unpacked fresh, so you couldn't save anything in there, only load.
>
> Regards,
> Stepan
>
> Samson Wai schrieb:
>> Hi,
>>
>> Currently I am using the following classes in my TPTP Integrated Agent
>> Controller code:
>>
>> org.eclipse.osgi.framework.internal.core.BundleFragment
>> org.eclipse.osgi.framework.internal.core.BundleHost
>> org.eclipse.osgi.internal.baseadaptor.BaseStorageHook
>>
>> 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. One
>> example is that I may need to know where the SWT DLL's are unpacked
>> under the Eclipse configuration directory.
>>
>> I have some questions:
>> 1. Is there a plan to make them public? i.e. not internal
>> 2. If not, is there going to be major changes on those classes in the
>> upcoming releases?
>>
>> I will need know the answers since any changes now will impact our
>> TPTP 4.2 development plan. Thanks.
>>
>> Regards,
>>
>> Samson
|
|
|
| Re: Eclipse OSGi internal APIs [message #65599 is a reply to message #65578] |
Fri, 28 April 2006 15:59 |
Stepan Rutz
Messages: 52
Registered: July 2009 |
Member |
|
|
Samson, thanks for clarification. I get your point now.
I use Bundle-NativeCode myself, but i see now why it is not enough.
Sorry, then the public api probably hides the OSGi configuration-area.
At least that seems reasonable to me. Also I am out of ideas :)
Regards,
Stepan
Samson Wai schrieb:
> Hi Stepan,
>
> 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 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 launching.
>
> 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 FQ paths of the SWT JAR/DLL files
> and add them to the CLASSPATH/PATH environment for the launched process.
>
> I think the PDE launch capability can do somewhat similar but I couldn't
> find a useful sample for my use case. Any pointers on this will be very
> useful.
>
> Regards,
>
> Samson
>
>
> Stepan Rutz wrote:
>> Hi Samson,
>>
>> I have a bundle with native-libs myself. And i cannot think of any
>> reason why I would want to know where my dlls/.so files are unpacked.
>> All i want to do with a dll/so is to load it.
>>
>> What makes you want to know where the dll/so file is physically located ?
>>
>> Even then if you start with -clean, the configuration area is wiped
>> and libs are unpacked fresh, so you couldn't save anything in there,
>> only load.
>>
>> Regards,
>> Stepan
>>
>> Samson Wai schrieb:
>>> Hi,
>>>
>>> Currently I am using the following classes in my TPTP Integrated
>>> Agent Controller code:
>>>
>>> org.eclipse.osgi.framework.internal.core.BundleFragment
>>> org.eclipse.osgi.framework.internal.core.BundleHost
>>> org.eclipse.osgi.internal.baseadaptor.BaseStorageHook
>>>
>>> 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. One
>>> example is that I may need to know where the SWT DLL's are unpacked
>>> under the Eclipse configuration directory.
>>>
>>> I have some questions:
>>> 1. Is there a plan to make them public? i.e. not internal
>>> 2. If not, is there going to be major changes on those classes in the
>>> upcoming releases?
>>>
>>> I will need know the answers since any changes now will impact our
>>> TPTP 4.2 development plan. Thanks.
>>>
>>> Regards,
>>>
>>> Samson
|
|
| |
| Re: Eclipse OSGi internal APIs [message #65769 is a reply to message #65599] |
Mon, 01 May 2006 19:36 |
Samson Wai
Messages: 46
Registered: July 2009 |
Member |
|
|
Thanks Stepan. Should I open a bugzilla enhancement request to make
those "internal" APIs "public" for the next release? If that's
reasonable, which component should I file the bug against?
Regards,
Samson
Stepan Rutz wrote:
> Samson, thanks for clarification. I get your point now.
>
> I use Bundle-NativeCode myself, but i see now why it is not enough.
>
> Sorry, then the public api probably hides the OSGi configuration-area.
> At least that seems reasonable to me. Also I am out of ideas :)
>
> Regards,
> Stepan
>
> Samson Wai schrieb:
>> Hi Stepan,
>>
>> 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 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 launching.
>>
>> 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 FQ paths of the SWT
>> JAR/DLL files and add them to the CLASSPATH/PATH environment for the
>> launched process.
>>
>> I think the PDE launch capability can do somewhat similar but I
>> couldn't find a useful sample for my use case. Any pointers on this
>> will be very useful.
>>
>> Regards,
>>
>> Samson
>>
>>
>> Stepan Rutz wrote:
>>> Hi Samson,
>>>
>>> I have a bundle with native-libs myself. And i cannot think of any
>>> reason why I would want to know where my dlls/.so files are unpacked.
>>> All i want to do with a dll/so is to load it.
>>>
>>> What makes you want to know where the dll/so file is physically
>>> located ?
>>>
>>> Even then if you start with -clean, the configuration area is wiped
>>> and libs are unpacked fresh, so you couldn't save anything in there,
>>> only load.
>>>
>>> Regards,
>>> Stepan
>>>
>>> Samson Wai schrieb:
>>>> Hi,
>>>>
>>>> Currently I am using the following classes in my TPTP Integrated
>>>> Agent Controller code:
>>>>
>>>> org.eclipse.osgi.framework.internal.core.BundleFragment
>>>> org.eclipse.osgi.framework.internal.core.BundleHost
>>>> org.eclipse.osgi.internal.baseadaptor.BaseStorageHook
>>>>
>>>> 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. One
>>>> example is that I may need to know where the SWT DLL's are unpacked
>>>> under the Eclipse configuration directory.
>>>>
>>>> I have some questions:
>>>> 1. Is there a plan to make them public? i.e. not internal
>>>> 2. If not, is there going to be major changes on those classes in
>>>> the upcoming releases?
>>>>
>>>> I will need know the answers since any changes now will impact our
>>>> TPTP 4.2 development plan. Thanks.
>>>>
>>>> Regards,
>>>>
>>>> Samson
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:47:00 GMT 2024
Powered by FUDForum. Page generated in 0.03535 seconds |
] 
Search
Help
Register
Login
Home
