Hi,

I have not had the time to look at the details of simpleconfigurator, but I 
think it worth asking on the equinox-dev ml as to why the fragments are being 
refreshed.

Pascal


From: [email protected] [mailto:[email protected]] On Behalf 
Of Chip Downs
Sent: November-02-12 8:39 AM
To: [email protected]
Subject: Re: [p2-dev] Automated bundle installation and startup without 
platform restart

With a lot of prayer and some reverse-engineering, I found a couple of 
workarounds that should do the trick.

I couldn't avoid the need for classloading logic based on HookConfigurators 
(osgi.hook.configurators.include). Although framework extensions wouldn't work, 
my logic had to be in the framework classpath for the HookRegistry to 
instantiate their implementations.

Since our app includes a JRE customized with various things (e.g., 
accessibility), the classpath would work if I included my HookConfigurator jars 
in the JRE's lib/ext directory. However, that's a messy way to go, especially 
since a copy of the org.eclipse.osgi jar had to be colocated with them to avoid 
NoClassDefFound errors. I also needed to set 
osgi.frameworkParentClassloader=current in my config.ini.

The better way involved the osgi.frameworkClassPath property. After converting 
my HookConfigurators' fragments into regular plug-in bundles (or regular jars 
for that matter), the HookRegistry could "see" them if the property simply 
pointed to them by relative path. Here's what the necessary properties looked 
like in the config.ini file:

    
osgi.hook.configurators.include=com.cma.ssl..SsslHookConfigurator,weblogic.osgi.adapterhooks.ClassLoadingHookConfigurator

    osgi.frameworkClassPath=., 
../plugins/com.bea.weblogic.osgi.adapterhooks_2.1.0.201211011922.jar, 
../plugins/com.cma.ssl.adapterhooks_2.1.0.201211011922.jar, 
../org.eclipse.equinox.servletbridge.extensionbundle_1.2.0.v20100503.jar
Chip

-----Original Message-----
From: Chip Downs <[email protected]<mailto:[email protected]>>
To: p2-dev <[email protected]<mailto:[email protected]>>
Sent: Wed, Oct 31, 2012 2:02 pm
Subject: Re: [p2-dev] Automated bundle installation and startup without 
platform restart
Pascal,

Still trying to work this problem. Getting much closer, but still not there yet.

It looks like my platform is restarting due to 2 framework extension fragments 
we have in our product. As far as I can tell, no bundles or features depend on 
them, aside from my "management" application, (which I've tried to make as 
absolutely small as possible).

I've watched the content of the bundles.info file very closely during 
installation, but the fragments are not being updated (or downloaded at all) 
from my p2 repository. Although I cannot see any reason why the fragments would 
be refreshed, the PackageAdmin is doing it nonetheless when called by the 
simple configurator.
Can I force them from being refreshed? I like what you said below about making 
sure "that the 'management' application (the one that installs the other apps) 
and all its dependencies are not changeable." Is there some kind of "magic" 
configuration option that makes a bundle (or set of bundles) not changeable?

Thanks,
Chip


-----Original Message-----
From: Pascal Rapicault <[email protected]<mailto:[email protected]>>
To: P2 developer discussions <[email protected]<mailto:[email protected]>>
Sent: Fri, Oct 19, 2012 8:49 pm
Subject: Re: [p2-dev] Automated bundle installation and startup without 
platform restart
So far, I've got an IApplication implementation that successfully works through 
Step #5. However, everything after Step 5 is giving me problems. As you know, 
the p2 logic only installs the IUs. It doesn't start the plugins, much less 
make their extension points available for creating executable extensions.

I tried to mimic the p2 UI logic by looking up the SimpleConfigurator and 
invoking its applyConfiguration() method. However, it caused the 
org.eclipse.core.runtime plugin to stop, kill the running Platform, and stop my 
IApplication instance and its plugin.
    For this to happens means that the bundles you are installing are not the 
same than those that you have been running since step #2.
I understand that the point is to try to have a new application running, but 
what I'm getting at is that the installation of your application is causing a 
new version of the runtime (and maybe other bundles) to be brought in. 
Consequently, when you invoke applyConfiguration() on simpleconfigurator, the 
runtime bundles are stopped and uninstalled to get the new ones to run.
The easiest way to know if this is really the problem is to look at the content 
of the bundles.info before and after the install and see if some key bundles 
like runtime, osgi, equinox.app, and friends have not changed. 
simpleconfigurator does not do anything fancy, it just makes sure that all the 
bundles and only those listed in this file are indeed installed in the fwk and 
started accordingly.

One side note, from what I understand or your system, I would say that you may 
even want to ensure that the "management" application (the one that installs 
the other apps) and all its dependencies are not changeable since otherwise the 
install of an app could actually cause your management to be restarted while it 
is installing the new one :)

HTH

Pascal




After that I tried to initialize my installed plugins manually, such as using 
the PlatformAdmin to set start levels, resolve, etc. However, I kept running 
into NoClassDefFound errors since some plugins didn't lazily initialize as 
expected.

I also tried to set up a separate profile, install my "heavyweight" features to 
the dropins directory, and use the reconciler APIs to initialize my plugins. 
Unfortunately, the app still tried to restart the org.eclipse.core.runtime 
plugin and kill the running Platform.

Any advice? This is a crucial step in making my RCP app lightweight and easier 
to deploy and update.

Thanks,
Chip
_______________________________________________
p2-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________

p2-dev mailing list

[email protected]<mailto:[email protected]>

https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev

Reply via email to