Re: [p2-dev] strangeness when running p2 as web archive

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

That particular error usually indicates that there is a problem making sense of what's in eclipse.ini vs. what is on disk and in particular there was a bug for the situation you describe found late in 3.5 where we did the path math wrong and left an extra "plugins" folder in the path. We decided not to do the fix in 3.5.x because the situation was not one we ever expected someone to run into -- until now. In addition to this one path fix I know Andrew Niefer has been making other changes in HEAD to help make better sense of what's going on and we should be able to handle an empty or missing eclipse.ini better. So, I'd suggest a switch to HEAD as even if that doesn't help work out the problems that's we're going to have to do the fix.
-Simon

Scott Lewis ---10/20/2009 07:56:30 PM---I'm fussing with running p2 with a web archive (war) installation, and am getting some strangeness

From:	Scott Lewis <slewis@xxxxxxxxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	10/20/2009 07:56 PM
Subject:	[p2-dev] strangeness when running p2 as web archive
Sent by:	p2-dev-bounces@xxxxxxxxxxx

---

I'm fussing with running p2 with a web archive (war) installation, and 
am getting some strangeness RE: the equinox frameworkadmin 
implementation when trying to revert/uninstall IUs.  Before describing 
what's happening in the source, I need to say that this is on the 
R3_5_maintenance branch.

Here's what's happening:

I create/install and run (under tomcat servlet container) an Equinox 
war.  The webapp starts up/runs in Tomcat, and the OSGi console comes up 
(and the p2 console commands are present as the p2 command provider is 
present).  All is well at this point.

I can then use the p2 console commands to install a group IU (i.e. 
provaddrepo/provinstall,confapply).

But then when I try to revert to a previous profile timestamp (via new 
p2 console command I'm working on), the revert fails, because this 
fwConfigLocation.equals(fwPersistentDataLocation) fails and throws:

(EquinoxManipulatorImpl line:64)
                if (!fwConfigLocation.equals(fwPersistentDataLocation))
                    throw new IllegalStateException(message removed);

In debugging into this code, I noticed that *before* this code throws, 
there is code in EquinoxManipulatorImpl.loadWithoutFwPersistentData that 
*sets* the launcerData.fwPersistentDataLocation to a non-null value.  
That is, I can see that at 
EquinoxManipulatorImpl.loadWithoutFwPersistentData line:353, the 
contents of launcherData field is:

Class:org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxLauncherData
fwName=Equinox
fwVersion=3.3
launcherName=Eclipse.exe
launcherVersion=3.2
jvm=null
jvmArgs = null
programArgs = null
fwConfigLocation=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\configuration
fwJar=null
fwPersistentDataLocation=null
home=null
launcher=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\eclipse.exe
launcherConfigLocation=null
clean=false

But then the following code is executed (this code is in 
EquinoxManipulatorImpl.loadWithoutFwPersistentData()):

        File launcherConfigFile = 
getLauncherConfigLocation(launcherData);   <-line 353
// After this is executed, 
launcherConfigFile=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\eclipse.ini 

        if (launcherConfigFile != null && 
!launcherConfigFile.getName().endsWith(IGNORED)) {
// This block is entered, and the parser.read call is made. 
            // use launcher. -- > load from LaucnherConfig file.
            // the parameters in memory will be updated.
            EclipseLauncherParser parser = new EclipseLauncherParser();
            parser.read(launcherConfigFile, launcherData);
        }


And at this point in the code (i.e. after the parser.read), the value of 
launcherData is now:

Class:org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxLauncherData
fwName=Equinox
fwVersion=3.3
launcherName=Eclipse.exe
launcherVersion=3.2
jvm=null
jvmArgs = null
programArgs = null
fwConfigLocation=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\configuration
fwJar=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\plugins\org.eclipse.osgi_3.5.1.R35x_v20090827.jar
fwPersistentDataLocation=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\plugins\configuration
home=null
launcher=C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse\eclipse.exe
launcherConfigLocation=null
clean=false

Notice that the fwConfigLocation and the fwPersistentDataLocation are 
not equal (and now both non-null).  The fwPersistentDataLocation has 
...eclipse\plugins\configuration (incorrect) while the fwConfigLocation 
has ...eclipse\configuration.   So the !equals test succeeds and the 
IllegalStateException is now thrown.

I noticed that the eclipse.ini file that is actually read with the 
parser.read is *empty* (0 bytes).  So somehow the 
parser.read(launcherConfigFile, launcherData); line is changing the 
launcherData value for fwPersistentDataLocation even when the 
eclipse.ini is completely empty.

Then if I *delete* the eclipse.ini file from the directory above before 
doing the revert the revert then succeeds.  But here's an interesting 
part...as a side effect of the revert (or the confapply) an *empty* 
eclipse.ini file is then introduced back into the 
C:\apache-tomcat-6.0.18\work\Catalina\localhost\eclipsert102\eclipse 
directory.  I have no idea why an empty eclipse.ini is introduced...so 
the problem described above then shows up again (because the eclipse.ini 
file is present).

Scott




_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev