Re: [equinox-dev] Is the P2 installer supposed to work?
On Wed, May 21, 2008 at 5:20 AM, Jeff McAffer [EMAIL PROTECTED] wrote: I should have mentioned... - Please enter a bug for this with your good steps. Thanks! - We have been running the installer on windows and the Mac quite regularly and even via JNLP. This must be a quirk in the build as the product definition file looks fine. Yeah, I was going to - I just wanted to check that it wasn't already a known problem. https://bugs.eclipse.org/bugs/show_bug.cgi?id=233159 It looks like it's not consulting the p2installer.ini file, but that doesn't matter since the p2installer.ini file doesn't contain the URL anyway. And the documentation is still wrong on the Wiki. Still, using the right URL and the command line args to set the system property, it finally did work; at least in the sense of getting to another error. This time, it complains 'No repository found at http://download.eclipse.org/eclipse/updates/3.4milestones/' ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox lazy bundle start and deadlocks
The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom From: Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/21/2008 07:19 AM Subject:[equinox-dev] Equinox lazy bundle start and deadlocks I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at http://wiki.eclipse.org/Lazy_Start_Bundles. This page suggests that these were only occurring in 3.2, but I'm running with Equinox 3.3. What is the status of resolving these issues? I should mention as well that I'm using Declarative Services, and that this is involved in the deadlocks I've seen so far. The problems relate to the declarative services code being registered as a bundle listener hence getting callbacks when bundles are lazily started. It then synchronously proceeds to read component specifications and activating services (hence calling out into client code). Having all this happening synchronously on a callback essentially sourced from within a classloader seems like a recipe for problems! I'm working on a server-side application so I actually don't care about lazy start at all. So to work around the problem, I tried disabling the EclipseLazyStarter hook using the osgi.hook.configurators.exclude system property. This caused problems when starting some Equinox bundles that would look for services that hadn't been registered. Presumably because the bundles providing these services depend on being started via the lazy start mechanism. I then tried working around this by ensuring I listed all necessary bundles in my config.ini with the right start level, but I found it difficult to come up with a working configuration here. Does anyone have any other suggestions for how I can run Equinox with lazy start disabled? Regards, Jan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox lazy bundle start and deadlocks
I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs you mention though (we saw those earlier before we got patches for those). Specifically, those bugs don't involve lazy bundle starting. It seems to me that there's an inherent problem with the lazy bundle starting. What we're seeing is that one thread goes through the steps: Bundle is activated - DS is notified, gets lock - enters class loader as part of activating a service, gets lock. Whereas a second thread does: Enters class loader, gets lock - bundle is lazily loaded - DS is notified, gets lock. So in one thread, a lock in DS is held before the classloader lock is acquired, in the other thread the classloader lock is held then it calls out to DS which will acquire a lock. Maybe it would be possible to work around this specific case by juggling locks inside the DS implementation. But it just seems to me that it would be very difficult to guard against future errors along this line. Basically, the lazy bundle loading means that any innocent-looking line of code like: Widget = new Widget(); anywhere in my code can cause a very long chain of synchronous events including calling back out to my code through bundle and service listener interfaces. Ensuring that locking is correct in all situations seems completely impossible, so I'd much rather just turn lazy loading off. Any suggestions for what is the best way to do this? Regards, Jan 2008/5/21 Thomas Watson [EMAIL PROTECTED]: The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom [image: Inactive hide details for Jan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle s]Jan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at From: Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/21/2008 07:19 AM Subject: [equinox-dev] Equinox lazy bundle start and deadlocks -- I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at *http://wiki.eclipse.org/Lazy_Start_Bundles*http://wiki.eclipse.org/Lazy_Start_Bundles. This page suggests that these were only occurring in 3.2, but I'm running with Equinox 3.3. What is the status of resolving these issues? I should mention as well that I'm using Declarative Services, and that this is involved in the deadlocks I've seen so far. The problems relate to the declarative services code being registered as a bundle listener hence getting callbacks when bundles are lazily started. It then synchronously proceeds to read component specifications and activating services (hence calling out into client code). Having all this happening synchronously on a callback essentially sourced from within a classloader seems like a recipe for problems! I'm working on a server-side application so I actually don't care about lazy start at all. So to work around the problem, I tried disabling the EclipseLazyStarter hook using the osgi.hook.configurators.exclude system property. This caused problems when starting some Equinox bundles that would look for services that hadn't been registered. Presumably because the bundles providing these services depend on being started via the lazy start mechanism. I then tried working around this by ensuring I listed all necessary bundles in my config.ini with the right start level, but I found it difficult to come up with a working configuration here. Does anyone have any other suggestions for how I can run Equinox with lazy start disabled? Regards, Jan ___ 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 ecblank.gifgraycol.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] How to use p2.generator in PDE build
Thanks John and Andrew,
I was able to create metadata that looks sane. There was some issues with a
trailing \n\ following the license in my feature.properties that ended up
as illegal XML characters in the content.xml though. I was as suggested using
the following properties in the build settings:
generate.p2.metadata=true
p2.metadata.repo = file:${buildDirectory}/repo
p2.artifact.repo = file:${buildDirectory}/repo
p2.metadata.repo.name = Meta Repo Name
p2.artifact.repo.name = Artifact Repo Name
p2.flavor = tooling
p2.publish.artifacts=true
So now I'm attempting to create an installation using the repository and the
p2 director, I've tried both the ANT task and calls from the command line but
not much happens. Since all my build scripts are designed to run using xvfb
(because of the GUI tests at the end) it took a while before I noticed that
the director actually has a splash screen and shows error messages in a
dialog. What about headless builds? Anyways I finally got it to run and it
creates a p2 folder inside my install location containing:
* org.eclipse.equinox.p2.core
* org.eclipse.equinox.p2.engine
* org.eclipse.equinox.p2.director
The process continues to do apparently nothing. The splash screen does not
disappear and the process never exits. I checked the log file from launching
the director and it states:
!ENTRY org.eclipse.core.net 4 0 2008-05-21 14:57:20.894
!MESSAGE No password provided.
!STACK 0
org.eclipse.equinox.security.storage.StorageException: No password provided.
at
org.eclipse.equinox.internal.security.storage.SecurePreferences.get(SecurePreferences.java:264)
at
org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.get(SecurePreferencesWrapper.java:106)
at
org.eclipse.core.internal.net.ProxyType.loadProxyAuth(ProxyType.java:495)
at
etc...
So could it be that it fails because I'm behind a password protected proxy? Is
there a way of not connecting to the Internet when resolving bundle
dependencies (which I'm guessing that it's doing)?
--
Torkild Ulvøy Resheim
Senior Design Engineer
Atmel Norway AS
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Is the P2 installer supposed to work?
Open a bug with the errors you are getting. | | From: | | --| |Alex Blewitt [EMAIL PROTECTED] | --| | | To:| | --| |Equinox development mailing list equinox-dev@eclipse.org | --| | | Date: | | --| |05/20/2008 07:47 PM | --| | | Subject: | | --| |[equinox-dev] Is the P2 installer supposed to work? | --| I only ask because I downloaded the installer from: http://download.eclipse.org/eclipse/equinox/drops/S-3.4 RC1-200805161333/index.php#Provisioning and when running it, it doesn't install the SDK as the documentation suggests: http://wiki.eclipse.org/Equinox_p2_Installer * Get the installer for your platform from the equinox download page. * Unzip the installer anywhere on your local disk * Run the p2installer executable * In the install wizard, select where you want to install the software Shows a dialog with Where do you want to install null? I had a look at the p2installer.ini: -showsplash org.eclipse.platform -vmargs -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Xms40m -Xmx256m -XX:MaxPermSize=256m -Dorg.eclipse.swt.internal.carbon.smallFonts No mention of the org.eclipse.equinox.p2.installDescription that the page suggests it looks for. I try adding it, and get a new message saying the error is invalid. That's maybe because the URL that that page points to is invalid: http://update.eclipse.org/eclipse/testUpdates/sdk-installer.properties - 404 not found * When finished, you can delete the installer I deleted it. At least that worked ... Alex ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox lazy bundle start and deadlocks
I'm not sure why you cannot just activate every bundle at launch if you don't care about lazy activation. Is that what you tried to do but it failed? A testcase would really help here. You mention lots of locks below but I'm not sure if these are class loader locks established by the vm or framework locks associated with Bundle lifecycles or DS impl locks. I suggest you open a bug against Equinox-Framework to track dead lock issues you are seeing with lazy activation. If class loading locks are causing the issue then I suspect you are running into a flavor of https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737. Locking the class loader at the VM level is blocked by a long standing Sun http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071. It would be interesting to know if the VM args mentioned at https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737#c8 help solve your problem. Tom From: Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/21/2008 08:09 AM Subject:Re: [equinox-dev] Equinox lazy bundle start and deadlocks I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs you mention though (we saw those earlier before we got patches for those). Specifically, those bugs don't involve lazy bundle starting. It seems to me that there's an inherent problem with the lazy bundle starting. What we're seeing is that one thread goes through the steps: Bundle is activated - DS is notified, gets lock - enters class loader as part of activating a service, gets lock. Whereas a second thread does: Enters class loader, gets lock - bundle is lazily loaded - DS is notified, gets lock. So in one thread, a lock in DS is held before the classloader lock is acquired, in the other thread the classloader lock is held then it calls out to DS which will acquire a lock. Maybe it would be possible to work around this specific case by juggling locks inside the DS implementation. But it just seems to me that it would be very difficult to guard against future errors along this line. Basically, the lazy bundle loading means that any innocent-looking line of code like: Widget = new Widget(); anywhere in my code can cause a very long chain of synchronous events including calling back out to my code through bundle and service listener interfaces. Ensuring that locking is correct in all situations seems completely impossible, so I'd much rather just turn lazy loading off. Any suggestions for what is the best way to do this? Regards, Jan 2008/5/21 Thomas Watson [EMAIL PROTECTED]: The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom Inactive hide details for Jan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle sJan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at From:Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date:05/21/2008 07:19 AM Subject: [equinox-dev] Equinox lazy bundle start and deadlocks I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at
[equinox-dev] Equinox Contribution
The map file has been updated for the following Bug changes: + Bug 232159. Can't access update site with 3.4.0 I20080502-0100 (FIXED) The following projects have changed: org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] p2 bundles tagged for build
The map file has been updated for the following Bug changes: + Bug 218532. [ui] IUs below the root that have licenses need to be surfaced to user (FIXED) + Bug 228542. [ui] Check for updates presents wrong licenses to be accepted (FIXED) + Bug 231642. [ui] [repo] I can add the same repo twice (FIXED) + Bug 232315. Uninstall of the director application should not require repo (FIXED) + Bug 232992. [ui] Incorrect update plan when changing selection in update wizard (FIXED) + Bug 233052. Shared bundle pool shows up as non-system repository (FIXED) + Bug 233210. Translation Clarification - org.eclipse.equinox.p2.extensionlocation (FIXED) + Bug 233226. BundleDescriptionFactory log is useless (FIXED) + Bug 233250. Mirror sorted in wrong order (FIXED) The following projects have changed: org.eclipse.equinox.p2.artifact.repository org.eclipse.equinox.p2.extensionlocation org.eclipse.equinox.p2.ui org.eclipse.equinox.p2.metadata.generator org.eclipse.equinox.p2.metadata.repository org.eclipse.equinox.p2.tests org.eclipse.equinox.p2.director.app___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
