Re: [equinox-dev] The org.eclipse.equinox.security.secureStorage extension point
Hi Oleg,
I still see the problem but its a fairly complex setup. I'll try to
create something simpler that simulates the same flow.
Thanks,
Thomas Hallgren
Oleg Besedin wrote:
Hi Thomas,
It has been tested without SWT; I just re-checked it to be sure -
works fine for me.
Regarding your concerns on the optional dependency: Consider that to
get to the code you copied you need:
- Not be in a headless run (the secure storage sets an option to
suppress prompts for headless runs and JUnits), and
- Have a error in the secure storage where the master password can not
be decrypted
Next, if execution path does get to that code, it catches the
NoClassDefFoundError and eventually translates it into
StorageException(StorageException.NO_PASSWORD).
In principle, VM could be constructed to load class files eagerly.
Practically, VMs try to load as little as they can to speed up the
processing. To be on the safe side, the usual approach is to isolate
code dealing with optional bundles into a separate class. (This is not
always necessary but saves a lot of thinking.)
So, that code works without SWT. As for "been thoroughly tested" I'll
leave that to the Eclipse QA team to answer.
Back to secure storage: do you still see the problem? If you see it
with the current version of the x86 fragment, please open a bug with
steps to reproduce.
Thanks,
Oleg Besedin
*Thomas Hallgren <[EMAIL PROTECTED]>*
Sent by: [EMAIL PROTECTED]
07/03/2008 10:36 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev] The
org.eclipse.equinox.security.secureStorageextension point
Hi Oleg,
I confused the extension id with the class name. I'm using the 3.4
release of the delta pack. The fragment.xml declares:
extension id="WindowsPasswordProvider"
which should be OK since the comparison that is made when finding it is
case insensitive.
Now I'm starting to wonder, could this be caused by the optional
dependency on org.eclipse.swt? This bundle is deliberately omitted from
my setup. I found this piece of code:
try {
if (!WinCryptoUI.canRecreatePassword())
return null;
} catch (NoClassDefFoundError exception) {
return null;
}
and that makes me wonder. Does this really work? Isn't there a fair
chance that the JVM will attempt to resolve the class before it enters
the try/catch? I wouldn't be surprised if the optimizer, while doing
first pass rudimentary inlining, in fact attempts to resolve this class
too early and thus fails. Has this been thoroughly tested without swt
present?
Regards,
Thomas Hallgren
Oleg Besedin wrote:
>
> Hi Thomas,
> You are on the right path; the
> "org.eclipse.equinox.security.win32.x86" fragment provides
> "WindowsPasswordProvider". Did you by chance get an old version of the
> fragment from the incubator?
>
> The up-to-date graduated version is in the
> ":pserver:[EMAIL PROTECTED]:/cvsroot/eclipse" repository under
> Head/org.eclipse.equinox/security/bundles.
>
> As a side note, we need to discuss during the Equinox meeting if it is
> better to remove old bundles that have been graduated from the
> repository (less confusion) or keep them (more history).
>
> Thanks,
> Oleg Besedin
>
>
>
> *Thomas Hallgren <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 07/03/2008 05:17 AM
> Please respond to
> Equinox development mailing list
>
>
>
> To
> Equinox development mailing list
> cc
>
> Subject
> [equinox-dev] The
org.eclipse.equinox.security.secureStorage
> extension point
>
>
>
>
>
>
>
>
>
> When running headlessly I get an exception with the following message:
>
> "Unable to locate secure storage module
> (org.eclipse.equinox.security.windowspasswordprovider)"
>
> First I thought that I'd forgotten to include the fragment
> org.eclipse.equinox.security.win32.x86 but when I look more closely I
> see that this fragment only adds a module with the id
> "org.eclipse.equinox.internal.security.win32.WinCrypto"
>
> So what bundle is it that defines the module with id
> "org.eclipse.equinox.security.windowspasswordprovider" ?
>
> Regards,
> Thomas Hallgren
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-de
[equinox-dev] P2: Adding update sites for RCP app
Hi All, I want to install a p2-enabled RCP app from a repository and a couple of update sites should be registered at the very first startup of the app. What it the recommended procedure for this? Are there any configuration files I could deploy with my app to specify the update-site list? Thanks Kai Tödter Siemens AG Corporate Technology Architecture CT SE 2 Otto-Hahn-Ring 6 81739 Munich, Germany Phone: +49 89 636-41064 Fax: +49 89 636-45450 mailto: [EMAIL PROTECTED] Internet: www.siemens.com/corporate-technology Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Heinrich Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Juergen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Peter Y. Solmssen, Klaus Wucherer; Registered offices: Berlin and Munich; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar without OSGi framework classes?
Hey Olaf Did you try copying out the OSGi types and putting them on the JCA classloader? If the FirstChild is actually a child of the JCA loader then it should get the OSGi types from JCA and ignore the ones in the osgi.jar. Of course, if you are trying to isolate Equinox from the JCA classes this might be a problem. What is the parent of the JCA classloader? Jeff Bergner, Olaf wrote: Hi Jeff, I'm trying to integrate Equinox as a JCA adapter into WLS 9.2 which, to the best of my knowledge, is not based on OSGi, as opposed to WLS 10.0. Anyway, my goals are the following: - Keep the application's main programming model, migrate to OSGi only those very few yet very sensitive parts of the application that change very often. This application is a _massive_ J2EE app which has been in the works since 2001. We are still working on finishing the first iteration. - Statically define a set of service interfaces whose implementation will be provided at runtime by Equinox. These interfaces live in a jar which is visible to both the enclosing JCA adapter module as well as Equinox. The packages these interfaces reside in are listed among OSGi's system packages. - Keep Equinox' class space(s) almost completely isolated from that of the enclosing JCA adapter module's. - Expose the org.osgi.framework classes - and later possibly the packageadmin's classes - to the enclosing JCA adapter module so that accessing OSGi services becomes possible. The org.osgi.framework package is listed among OSGi's system packages. When bootsrapping Equinox from inside the JCA adapter, I create a new child first classloader as a child classloader of the classloader that loaded the JCA module. This child first classloader knows about the location of the org.eclipse.osgi.jar on the classpath and first tries to load classes from this jar before delegating to the parent classloader, thus isolating the Equinox implementation from the enclosing JCA adapter module. This works like a charm: JCA RAR ClassLoader -> service-interfaces.jar | | ChildFirstBootstrapClassLoader -> org.eclispe.osgi.jar Unfortunately, since the OSGi framework is included in org.eclispe.osgi.jar, this also means that the org.osgi.framework classes will be loaded by this child first classloader and will therefore not be visible to the enclosing JCA adapter module. I tried patching the child first classloader to not loading classes that start with "org.osgi.framework" - I consider this solution an ugly hack - and putting osgi_R4.jar on the JCA adapter module's classpath. This doesn't work since it gives me a NoSuchMethodError: Equinox cannot find the method Bundle.start(). I am no classloading expert but suspect that there are two Bundle classes loaded. Of course, I could be totally wrong. Anyway, after several fruitless hours of debugging I decided not to venture further down this path and opted for a solution that uses reflection to gain access to the BundleContext returned from EclipseStarter.startup(). This works yet feels a little clumsy. If someone could point me to means of achieving my original goal of sharing the OSGi API classes between Equinox and the enclosing JCA adapter module, I would be grateful. Cheers, Olaf -- Hey Olaf, The short answer is, No, such a distribution is not readily available. The question in my mind is why do you need this? If you remove the OSGi classes where will they come from? If you happen to be running on an OSGi-based JEE app server then you could in theory get the classes from the app server. To do this you should be able to play around with the framework's parent classloader. That way the OSGi classes would still be in the org.eclipse.osgi bundle but they would be ignored in favor of the ones from the parent loader. Jeff Olaf Bergner wrote: Hello, I'm currently embedding equinox into a JEE app server and would like to make the OSGi API visible to the enclosing application. Therefore, I need an org.eclipse.osgi distribution that does not include the org.osgi.framework classes. Does it exist? Cheers, Olaf ___ equinox-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
AW: [equinox-dev] Possible to obtain org.eclipse.osgi.jar withoutOSGi framework classes?
Hi Jeff, thanks for your tireless efforts. I managed to make my scenario work by repackaging org.eclipse.osgi.jar, stripping all org.osgi packages and declaring corresponding imports in the repackaged jar's Import-Package header. Now, I'm by no stretch of the imagination an expert on legal matters, let alone the arcanae of licensing issues and fully expect this rogue measure to gain me a prolonged free lunch in some state prison, yet for the time being I will live with this threat and prod happily further down this path. BTW: Pending my employer's permission, I plan to someday make this little pet project of mine open source. Do you think people would be interested? Cheers, Olaf Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jeff McAffer Gesendet: Freitag, 4. Juli 2008 15:09 An: Equinox development mailing list Betreff: Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar withoutOSGi framework classes? Hey Olaf Did you try copying out the OSGi types and putting them on the JCA classloader? If the FirstChild is actually a child of the JCA loader then it should get the OSGi types from JCA and ignore the ones in the osgi.jar. Of course, if you are trying to isolate Equinox from the JCA classes this might be a problem. What is the parent of the JCA classloader? Jeff Bergner, Olaf wrote: Hi Jeff, I'm trying to integrate Equinox as a JCA adapter into WLS 9.2 which, to the best of my knowledge, is not based on OSGi, as opposed to WLS 10.0. Anyway, my goals are the following: - Keep the application's main programming model, migrate to OSGi only those very few yet very sensitive parts of the application that change very often. This application is a _massive_ J2EE app which has been in the works since 2001. We are still working on finishing the first iteration. - Statically define a set of service interfaces whose implementation will be provided at runtime by Equinox. These interfaces live in a jar which is visible to both the enclosing JCA adapter module as well as Equinox. The packages these interfaces reside in are listed among OSGi's system packages. - Keep Equinox' class space(s) almost completely isolated from that of the enclosing JCA adapter module's. - Expose the org.osgi.framework classes - and later possibly the packageadmin's classes - to the enclosing JCA adapter module so that accessing OSGi services becomes possible. The org.osgi.framework package is listed among OSGi's system packages. When bootsrapping Equinox from inside the JCA adapter, I create a new child first classloader as a child classloader of the classloader that loaded the JCA module. This child first classloader knows about the location of the org.eclipse.osgi.jar on the classpath and first tries to load classes from this jar before delegating to the parent classloader, thus isolating the Equinox implementation from the enclosing JCA adapter module. This works like a charm: JCA RAR ClassLoader -> service-interfaces.jar | | ChildFirstBootstrapClassLoader -> org.eclispe.osgi.jar Unfortunately, since the OSGi framework is included in org.eclispe.osgi.jar, this also means that the org.osgi.framework classes will be loaded by this child first classloader and will therefore not be visible to the enclosing JCA adapter module. I tried patching the child first classloader to not loading classes that start with "org.osgi.framework" - I consider this solution an ugly hack - and putting osgi_R4.jar on the JCA adapter module's classpath. This doesn't work since it gives me a NoSuchMethodError: Equinox cannot find the method Bundle.start(). I am no classloading expert but suspect that there are two Bundle classes loaded. Of course, I could be totally wrong. Anyway, after several fruitless hours of debugging I decided not to venture further down this path and opted for a solution that uses reflection to gain access to the BundleContext returned from EclipseStarter.startup(). This works yet feels a little clumsy. If someone could point me to means of achieving my original goal of sharing the OSGi API classes between Equinox and the enclosing JCA adapter module, I would be grateful. Cheers, Olaf -- Hey Olaf, The short answer is, No, such a distribution is not readily available. The question in my mind is why do you need this? If you remove the OSGi classes where will they come from? If you happen to be running on an OSGi-based JEE app server then you could in theory get the classes from the app server. To do this you should be able to play around with the framework's parent classloader. That way the OSGi classes would still be in the org.eclipse.osgi bundle but they would be ignored in favor of the ones from the parent loader. Jeff Olaf Bergner wrote: Hello, I
[equinox-dev] Project meta data is out of date for eclipse.equinox
Jeff, Thomas, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "3.4" is in the past, but the release is not marked as completed. If it is completed, it should be marked as completed; if it has been postponed, it should be given a new target date. * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
