[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] strangeness when running p2 as web archive

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

Inactive hide details for Scott Lewis ---10/20/2009 07:56:30 PM---I'm fussing with running p2 with a web archive (war) installaScott 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


GIF image

GIF image