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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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