[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1 - SOLVED!!]
|
Good work. I'm glad to see that my incorrect suggestions didn't stop you from finding the real problem.
Adrian and Wes should make these changes. This fixes 6 failing unit tests in one configuration so is clearly above the bar.
-Jim
> -----Original Message-----
> From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
> Sent: Friday, May 09, 2003 3:25 AM
> To: aspectj-dev@xxxxxxxxxxx
> Subject: Re: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1 -
> SOLVED!!]
>
> Great sleuthing!
>
> But I'm sorry to hear that was the problem. I added the
> UserPreferencesStore(boolean) API to prevent loading from disk,
> but only updated the test case that was failing on my system.
> I should have upgraded all the ajde test code to not load old
> properties; the (uncommitted) patch below picks up the rest,
> and all tests pass with it. I think it will work in the case
> where someone uses AjBrowser (storing some properties) and
> then runs the test suite. And of course your persist patch
> will keep the test suite from {over}writing user preferences.
>
> Wes
>
> Index: testsrc/org/aspectj/ajde/BuildOptionsTest.java
> ===================================================================
> RCS file:
> /home/technology/org.aspectj/modules/ajde/testsrc/org/aspectj/ajde/BuildOp
> tionsTest.java,v
> retrieving revision 1.2
> diff -u -r1.2 BuildOptionsTest.java
> --- testsrc/org/aspectj/ajde/BuildOptionsTest.java 25 Jan 2003 01:25:30
> -0000 1.2
> +++ testsrc/org/aspectj/ajde/BuildOptionsTest.java 9 May 2003 09:40:22
> -0000
> @@ -146,7 +146,7 @@
>
> protected void setUp() throws Exception {
> super.setUp();
> - preferencesAdapter = new UserPreferencesStore();
> + preferencesAdapter = new UserPreferencesStore(false);
> buildOptions = new AjcBuildOptions(preferencesAdapter);
> }
>
> Index: testsrc/org/aspectj/ajde/NullIdeManager.java
> ===================================================================
> RCS file:
> /home/technology/org.aspectj/modules/ajde/testsrc/org/aspectj/ajde/NullIde
> Manager.java,v
> retrieving revision 1.3
> diff -u -r1.3 NullIdeManager.java
> --- testsrc/org/aspectj/ajde/NullIdeManager.java 27 Mar 2003 15:43:01
> -0000 1.3
> +++ testsrc/org/aspectj/ajde/NullIdeManager.java 9 May 2003 09:40:22
> -0000
> @@ -42,7 +42,7 @@
>
> public void init(String testProjectPath) {
> try {
> - UserPreferencesAdapter preferencesAdapter = new
> UserPreferencesStore();
> + UserPreferencesAdapter preferencesAdapter = new
> UserPreferencesStore(false);
> ProjectPropertiesAdapter browserProjectProperties = new
> NullIdeProperties(testProjectPath);
> taskListManager = new NullIdeTaskListManager();
> BasicEditor ajdeEditor = new BasicEditor();
>
>
> -------- Original Message --------
> Subject: Re: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1 -
> SOLVED!!
> Date: Fri, 9 May 2003 10:15:05 +0100
> From: "Adrian Colyer" <adrian_colyer@xxxxxxxxxx>
> Reply-To: aspectj-dev@xxxxxxxxxxx
> To: aspectj-dev@xxxxxxxxxxx
>
> George's detective work narrowed the problem down to an invalid character
> encoding used by the scanner. The bad value ("12345") was set in an
> earlier
> test, and despite a full tear-down and recreate of the environment managed
> to persist across test suites through the UserPreferenceStore. Since the
> order of junit test execution is undefined, this is a behaviour which can
> legitimately change across vms.
>
> The fix is to org.aspectj.ajde.ui.internal.UserPreferenceStore, which
> previously did not load user prefs from disk when initialised with
> "loadPrefs = null", but did save them. I changed the store so that the
> variable became "persist" and controlled both loading *and* saving.
>
> This is the small patch:
>
> Index: UserPreferencesStore.java
> ===================================================================
> RCS file:
> /home/technology/org.aspectj/modules/ajde/src/org/aspectj/ajde/ui/internal
> /UserPreferencesStore.java,v
> retrieving revision 1.3
> diff -u -r1.3 UserPreferencesStore.java
> --- UserPreferencesStore.java 30 Apr 2003 02:31:37 -0000 1.3
> +++ UserPreferencesStore.java 9 May 2003 09:12:30 -0000
> @@ -33,13 +33,15 @@
> public static final String FILE_NAME = "/.ajbrowser";
> private final String VALUE_SEP = ";";
> private Properties properties = new Properties();
> + private boolean persist = true;
>
> public UserPreferencesStore() {
> this(true);
> }
>
> public UserPreferencesStore(boolean loadDefault) {
> - if (loadDefault) {
> + persist = loadDefault;
> + if (persist) {
> loadProperties(getPropertiesFilePath());
> }
> }
> @@ -123,6 +125,8 @@
> }
> }
> public void saveProperties() {
> + if (!persist) return;
> +
> FileOutputStream out = null;
> String path = null;
> try {
>
> This has been commited and included in the rc2 build, under a presumption
> of rule 3. If there are any vetos on this change on the list we'll back it
> off again.
>
> Cheers,
> Adrian.
>
> -- Adrian.
> adrian_colyer@xxxxxxxxxx
>
>
>
>
>
> 08 May 2003 21:15
> To: George Harley1/UK/IBM@IBMGB
> cc: aspectj-dev@xxxxxxxxxxx
> From: Jim.Hugunin@xxxxxxxx
> Subject: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1
>
>
>
> George and I have been looking into the 6 ajde unit tests that are
> currently failing under the IBM-Windows JDK 1.3.1. This is an IBM
> internal
> JDK version and thus I'm not able to do any testing with that JDK, so my
> conclusions are very rough.
>
> 1. The ajde unit tests can be extremely confusing when something goes
> wrong
> because they "swallow" most error messages and even exceptions. As an
> example, modify testdata/examples/figures-coverage/all.lst to add an
> invalid filename. Many tests will now fail, but none of them will provide
> any clues as to the reason. These tests would be much more useful if
> better debugging message handling could be provided. I'd suggest that you
> (or Mik) try to improve this message handling as a first step.
>
> 2. George has observed a null source char[] in the parser (actually
> AjScanner) when running these tests on the IBM JDK. Here's my best guess
> as to what could cause this:
>
> a. Incorrect filenames are being produced by AjBuildConfig. This probably
> comes from some subtle difference in the implementation of the File class
> in the IBM JDK. Hopefully addressing issue #1 above could understand
> where
> this is coming from and if it's a real bug or just a test case weakness.
>
> b. This leads AjBuildManager.getCompilationUnits to return units that
> correspond to missing files. You should look at the CompilationUnit[]
> produced by this method to see if the CompilationUnit.getContents() method
> will return a real file contents.
>
> c. These bad CompilationUnits lead to the null source char[] that you're
> seeing.
>
> 3. This error only shows up in ajde (and possibly only in the ajde unit
> tests) and should be caught gracefully by the better error handling in the
> actual compiler.
>
> 4. If this error is too hard to track down we shouldn't delay 1.1rc2 for
> it
> since it only shows up in the test suite (we haven't seen it in actual
> use)
> and it only shows up with the IBM JDK 1.3.1 (and if it is a problem for
> actual users they can upgrade to the IBM or SUN 1.4 JVMs).
>
> -Jim
>
> PS - George, let me know how this works for you. I'm still available for
> a
> 8:30am PST call tomorrow if you need more help tracking this down.
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
