ODE
  1. ODE
  2. ODE-751

FindBugs Patches for ODE Runtime

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-beta3
    • Component/s: BPEL Runtime
    • Labels:
      None
    • Environment:
      linux

      Description

      Running FindBugs (http://findbugs.sourceforge.net/) against the bpel-api project, the following error:

      Equals method for org.apache.ode.bpel.iapi.Endpoint assumes the argument is of type Endpoint

      Will attach a patch to correct these issues.

      1. ode-npecheck-patch.txt
        11 kB
        David Carver
      2. ode-staticinner-patchv2.txt
        20 kB
        David Carver
      3. ode-valueOf-patch.txt
        5 kB
        David Carver

        Activity

        Hide
        David Carver added a comment -

        Patch to fix possible classcastexceptions when checking for equals on an object.

        Show
        David Carver added a comment - Patch to fix possible classcastexceptions when checking for equals on an object.
        Hide
        David Carver added a comment -

        Here are the fixes for bple-api for the issues that FindBugs found. Most are fairly minor changes.

        Show
        David Carver added a comment - Here are the fixes for bple-api for the issues that FindBugs found. Most are fairly minor changes.
        Hide
        David Carver added a comment - - edited

        In ode.apache.org.utils.StreamUtils the following code is getting some FindBugs errors reported.

        public static void extractJar(File dest, InputStream is) throws IOException {
        JarInputStream jis = new JarInputStream(is);
        JarEntry je;
        while ((je = jis.getNextJarEntry()) != null) {
        File outputFile = new File(dest, je.getName());
        if (je.isDirectory())

        { outputFile.mkdirs(); }

        else

        { outputFile.getParentFile().mkdirs(); BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(outputFile)); copy(bos, jis); bos.flush(); bos.close(); }

        jis.closeEntry();
        }
        }

        The above code does not check to see if mkdirs() method returns true or false. FindBugs is complaining because the return value is not checked. It could lead to some issues and possible IOException erros being tossed. This may actually be the desired behavior but thought I'd check here.

        The exact error message from FindBugs is:

        message org.apache.ode.utils.StreamUtils.extractJar(File, InputStream) ignores exceptional return value of java.io.File.mkdirs()

        The same issue happens in FileUtilsTest, TempFileManager.getTemporaryDirectory() as well

        Show
        David Carver added a comment - - edited In ode.apache.org.utils.StreamUtils the following code is getting some FindBugs errors reported. public static void extractJar(File dest, InputStream is) throws IOException { JarInputStream jis = new JarInputStream(is); JarEntry je; while ((je = jis.getNextJarEntry()) != null) { File outputFile = new File(dest, je.getName()); if (je.isDirectory()) { outputFile.mkdirs(); } else { outputFile.getParentFile().mkdirs(); BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(outputFile)); copy(bos, jis); bos.flush(); bos.close(); } jis.closeEntry(); } } The above code does not check to see if mkdirs() method returns true or false. FindBugs is complaining because the return value is not checked. It could lead to some issues and possible IOException erros being tossed. This may actually be the desired behavior but thought I'd check here. The exact error message from FindBugs is: message org.apache.ode.utils.StreamUtils.extractJar(File, InputStream) ignores exceptional return value of java.io.File.mkdirs() The same issue happens in FileUtilsTest, TempFileManager.getTemporaryDirectory() as well
        Hide
        David Carver added a comment -

        FindBugs has also found a possible Deadlock situation that can occur:

        message org.apache.ode.utils.ProcessMutex.lock() calls Thread.sleep() with a lock held

        This occurs around line 72. It suggests using the wait method instead of sleep as wait releases the lock and allows other threads to continue.

        Show
        David Carver added a comment - FindBugs has also found a possible Deadlock situation that can occur: message org.apache.ode.utils.ProcessMutex.lock() calls Thread.sleep() with a lock held This occurs around line 72. It suggests using the wait method instead of sleep as wait releases the lock and allows other threads to continue.
        Hide
        David Carver added a comment -

        Patch with several "bug" fixes for the utils project. Waiting on answers for what should be the correct way to handle the delete and mkdir values when they return false.

        Show
        David Carver added a comment - Patch with several "bug" fixes for the utils project. Waiting on answers for what should be the correct way to handle the delete and mkdir values when they return false.
        Hide
        David Carver added a comment -

        A few minor fixes for bple-dao.

        Show
        David Carver added a comment - A few minor fixes for bple-dao.
        Hide
        David Carver added a comment -

        Patches for schedule-simple project.

        Show
        David Carver added a comment - Patches for schedule-simple project.
        Hide
        David Carver added a comment -

        in org.apache.ode.bpel.compiler.bom.* there are several places with the compile methods like the following:

        public void compile(OActivity dest, Activity source) {
        OAssign oassign = (OAssign) dest;
        AssignActivity ad = (AssignActivity) source;

        FindBugs is reporting that this could cause possible ClassCastExceptions because an Class implementing the Activity and Oactivity interfaces may not necessarily be able to be cast to the corresponding classes. This is fairly simple to fix, but the question I have is what Exception should be tossed. We don't want to toss a ClassCastException but I would suspect some sort of compilation exception should be thrown.

        There are about 31 bugs like this being reported in this particular package.

        Show
        David Carver added a comment - in org.apache.ode.bpel.compiler.bom.* there are several places with the compile methods like the following: public void compile(OActivity dest, Activity source) { OAssign oassign = (OAssign) dest; AssignActivity ad = (AssignActivity) source; FindBugs is reporting that this could cause possible ClassCastExceptions because an Class implementing the Activity and Oactivity interfaces may not necessarily be able to be cast to the corresponding classes. This is fairly simple to fix, but the question I have is what Exception should be tossed. We don't want to toss a ClassCastException but I would suspect some sort of compilation exception should be thrown. There are about 31 bugs like this being reported in this particular package.
        Hide
        David Carver added a comment -

        Patch for ode-bpel-compile minus the unchecked casting issues that were detected.

        Show
        David Carver added a comment - Patch for ode-bpel-compile minus the unchecked casting issues that were detected.
        Hide
        David Carver added a comment -

        Here is a patch for the runtime. This patch is mostly about hashCode and equals implementations. This fixes several possible problems with both the hashCode calculations and the equal comparison for those subclasses that weren't overriding their parent classes equals (when the parent also overrode the default implementation).

        Show
        David Carver added a comment - Here is a patch for the runtime. This patch is mostly about hashCode and equals implementations. This fixes several possible problems with both the hashCode calculations and the equal comparison for those subclasses that weren't overriding their parent classes equals (when the parent also overrode the default implementation).
        Hide
        David Carver added a comment -

        Patch to fix possible deadlock situation.

        Show
        David Carver added a comment - Patch to fix possible deadlock situation.
        Hide
        David Carver added a comment -

        various minor fixed for ode-jca-ra.

        Show
        David Carver added a comment - various minor fixed for ode-jca-ra.
        Hide
        David Carver added a comment -

        patch for ode-jbi including nullpointer exception if the code was ever hit.

        Show
        David Carver added a comment - patch for ode-jbi including nullpointer exception if the code was ever hit.
        Hide
        David Carver added a comment -

        Various patches for ode-jacob. Many dealing with equals and hashcodes. One fix for converting an array to a string.

        Show
        David Carver added a comment - Various patches for ode-jacob. Many dealing with equals and hashcodes. One fix for converting an array to a string.
        Hide
        David Carver added a comment -

        Minor fixes for ode-il-common.

        Show
        David Carver added a comment - Minor fixes for ode-il-common.
        Hide
        David Carver added a comment -

        In the ode-engine project, in BpelDAOConnectionImpl.compareInstanceUsingKey method, there is a possiblity that both s1 and s2 can be null, in which case a Nullpointer exception can occur at the end of the method. Ideally there should be a default value returned from this method if they are null. For s2 if comparing to s1 I would assume a -1 would be returned since s2 < s1 when s2 is null.

        the opposite would be true when comparing s1 to s2 when s1 is null.

        I can make this change if you guys agree.

        Show
        David Carver added a comment - In the ode-engine project, in BpelDAOConnectionImpl.compareInstanceUsingKey method, there is a possiblity that both s1 and s2 can be null, in which case a Nullpointer exception can occur at the end of the method. Ideally there should be a default value returned from this method if they are null. For s2 if comparing to s1 I would assume a -1 would be returned since s2 < s1 when s2 is null. the opposite would be true when comparing s1 to s2 when s1 is null. I can make this change if you guys agree.
        Hide
        David Carver added a comment -

        Patch for ode-engine with out comment 16's item to be addressed.

        Show
        David Carver added a comment - Patch for ode-engine with out comment 16's item to be addressed.
        Hide
        David Carver added a comment -

        A few small patches for the hibernate project.

        Show
        David Carver added a comment - A few small patches for the hibernate project.
        Hide
        David Carver added a comment -

        Some minor patches for bpel-store

        Show
        David Carver added a comment - Some minor patches for bpel-store
        Hide
        Rafal Rusin added a comment -

        This is a very good work.
        Could you just clean up a few things, so I could apply it and test easily:

        • prepare a single patch ODE-751.patch and grant Apache license (and delete current attachments)
        • note which version you have used (ODE-1.X or trunk 2.X)

        Regards

        Show
        Rafal Rusin added a comment - This is a very good work. Could you just clean up a few things, so I could apply it and test easily: prepare a single patch ODE-751 .patch and grant Apache license (and delete current attachments) note which version you have used ( ODE-1 .X or trunk 2.X) Regards
        Hide
        David Carver added a comment -

        Sure let me see what I can work on later today. And this was against Trunk (2.x)

        Show
        David Carver added a comment - Sure let me see what I can work on later today. And this was against Trunk (2.x)
        Hide
        David Carver added a comment -

        This is the combined patch. This applies cleanly against the Trunk version of SVN.

        Show
        David Carver added a comment - This is the combined patch. This applies cleanly against the Trunk version of SVN.
        Hide
        Rafal Rusin added a comment -

        I tried this patch. It applied fine.
        However I see two problems with this patch:

        • tests don't pass, so basicly it doesn't work - you can at least try "buildr clean test" from bpel-test and jbi subdirectories
        • there's a lot of new methods "equals" and "hashcode", which are scarry to commit, because they will be hard to maintain and not nedded actually. So I suggest to delete them. Additionally they throw exceptions, like below.

        [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764)
        [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557)
        [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198)
        [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217)
        [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764)
        [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557)
        [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198)
        [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217)
        [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764)
        [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557)
        [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198)
        [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217)
        [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764)
        [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557)
        [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198)
        [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217)

        Show
        Rafal Rusin added a comment - I tried this patch. It applied fine. However I see two problems with this patch: tests don't pass, so basicly it doesn't work - you can at least try "buildr clean test" from bpel-test and jbi subdirectories there's a lot of new methods "equals" and "hashcode", which are scarry to commit, because they will be hard to maintain and not nedded actually. So I suggest to delete them. Additionally they throw exceptions, like below. [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764) [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557) [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198) [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217) [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764) [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557) [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198) [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217) [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764) [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557) [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198) [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217) [junit] at java.util.HashMap$Entry.hashCode(HashMap.java:764) [junit] at java.util.AbstractMap.hashCode(AbstractMap.java:557) [junit] at org.apache.ode.bpel.rtrep.v2.OScope.hashCode(OScope.java:198) [junit] at org.apache.ode.bpel.rtrep.v2.OPartnerLink.hashCode(OPartnerLink.java:217)
        Hide
        Rafal Rusin added a comment -

        Could you also delete those messy, no longer needed attachments?

        Regards

        Show
        Rafal Rusin added a comment - Could you also delete those messy, no longer needed attachments? Regards
        Hide
        David Carver added a comment -

        Sure, I can clean up the attachments. Here is a suggestion. Download and install FindBugs...

        http://findbugs.sourceforge.net/

        Many of the patches for the equals and hashcode actually should be done because with out them, you are depending on the parent's equal or hashcode to determine if something is equal or not. If the parent overrides the Object equal method, then the Child also needs to override the method and provide it's own implementation.

        There were also several issues with various equal statements, in particular this bug:

        http://findbugs.sourceforge.net/bugDescriptions.html#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

        Which the equal statements were automatically doing Casts to a specific object type, which would have tossed a ClassCastException instead of returning false, if the cast wasn't successful.

        I had originally wanted to do smaller patches for specific bugs, to make it easier to test, and implement in general. Plus this would allow for easier debugging when a test case fails. One large patch doesn't allow this type of testing.

        Also many of the patches fix issues with:

        http://findbugs.sourceforge.net/bugDescriptions.html#HE_EQUALS_NO_HASHCODE
        http://findbugs.sourceforge.net/bugDescriptions.html#HE_INHERITS_EQUALS_USE_HASHCODE
        http://findbugs.sourceforge.net/bugDescriptions.html#HE_HASHCODE_USE_OBJECT_EQUALS
        http://findbugs.sourceforge.net/bugDescriptions.html#HE_HASHCODE_NO_EQUALS

        The best thing to do though is to install FindBugs, run it against the code, and we can determine which are the critical bugs to fix, and which are ones we can safely ignore.

        Show
        David Carver added a comment - Sure, I can clean up the attachments. Here is a suggestion. Download and install FindBugs... http://findbugs.sourceforge.net/ Many of the patches for the equals and hashcode actually should be done because with out them, you are depending on the parent's equal or hashcode to determine if something is equal or not. If the parent overrides the Object equal method, then the Child also needs to override the method and provide it's own implementation. There were also several issues with various equal statements, in particular this bug: http://findbugs.sourceforge.net/bugDescriptions.html#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS Which the equal statements were automatically doing Casts to a specific object type, which would have tossed a ClassCastException instead of returning false, if the cast wasn't successful. I had originally wanted to do smaller patches for specific bugs, to make it easier to test, and implement in general. Plus this would allow for easier debugging when a test case fails. One large patch doesn't allow this type of testing. Also many of the patches fix issues with: http://findbugs.sourceforge.net/bugDescriptions.html#HE_EQUALS_NO_HASHCODE http://findbugs.sourceforge.net/bugDescriptions.html#HE_INHERITS_EQUALS_USE_HASHCODE http://findbugs.sourceforge.net/bugDescriptions.html#HE_HASHCODE_USE_OBJECT_EQUALS http://findbugs.sourceforge.net/bugDescriptions.html#HE_HASHCODE_NO_EQUALS The best thing to do though is to install FindBugs, run it against the code, and we can determine which are the critical bugs to fix, and which are ones we can safely ignore.
        Hide
        Rafal Rusin added a comment -

        OK. So please start with a simple patch first and get it working. It may contain just a few fixes. Give me a sign when it's done and I'll test it. Then if it works, I'll apply it.
        Actually I don't think creating a lot of issues for every findbugs bug and applying them separately makes sense. Testing a single contribution just takes some amount of time, which I don't have a lot. So lets' just start with small, working contribution, which solves a few of them.

        BTW. Your work is very valuable, I saw a few important improvements in this patch. But please just make this contribution higher quality. This is very important. It may be small, but high quality.

        Regards

        Show
        Rafal Rusin added a comment - OK. So please start with a simple patch first and get it working. It may contain just a few fixes. Give me a sign when it's done and I'll test it. Then if it works, I'll apply it. Actually I don't think creating a lot of issues for every findbugs bug and applying them separately makes sense. Testing a single contribution just takes some amount of time, which I don't have a lot. So lets' just start with small, working contribution, which solves a few of them. BTW. Your work is very valuable, I saw a few important improvements in this patch. But please just make this contribution higher quality. This is very important. It may be small, but high quality. Regards
        Hide
        David Carver added a comment -

        Patch that takes care of some inner classes that should be static inner. I ran the unit tests for the affect projects and they all seemed to pass.

        Once this patch is approved and applied, I'll do another round of fixes. Otherwise we have to deal with merges, and can't isolate the changes if problems occur.

        Again this is against 2.0 trunk.

        Show
        David Carver added a comment - Patch that takes care of some inner classes that should be static inner. I ran the unit tests for the affect projects and they all seemed to pass. Once this patch is approved and applied, I'll do another round of fixes. Otherwise we have to deal with merges, and can't isolate the changes if problems occur. Again this is against 2.0 trunk.
        Hide
        Rafal Rusin added a comment -

        Two small comments on this patch:

        • let's not modify equals and hashcode methods for now, since it adds messy code
        • please use 4 spaces code indenting instead of tabs

        After those fixes, it looks good to apply.

        Regards

        Show
        Rafal Rusin added a comment - Two small comments on this patch: let's not modify equals and hashcode methods for now, since it adds messy code please use 4 spaces code indenting instead of tabs After those fixes, it looks good to apply. Regards
        Hide
        David Carver added a comment -

        This patch should only have the inner static changes. Not sure what happened with the last patch. Also, I made sure that any spacing was set to 4 spaces instead of tabs.

        Show
        David Carver added a comment - This patch should only have the inner static changes. Not sure what happened with the last patch. Also, I made sure that any spacing was set to 4 spaces instead of tabs.
        Hide
        Rafal Rusin added a comment -

        Perfect, applied, thanks!
        Now you can move on.

        As for me, I liked this one (actually jbiMex.getExchangeId() should be displayed in warn here):

        Index: src/main/java/org/apache/ode/jbi/OdeConsumer.java
        ===================================================================
        — src/main/java/org/apache/ode/jbi/OdeConsumer.java (revision 908691)
        +++ src/main/java/org/apache/ode/jbi/OdeConsumer.java (working copy)
        @@ -144,7 +144,7 @@
        private void outFailure(final InOut jbiMex) {
        PartnerRoleMessageExchange pmex = (PartnerRoleMessageExchange) _ode._server.getMessageExchangeByForeignKey(jbiMex.getExchangeId());
        if (pmex == null)

        { - __log.warn("Received a response for unknown partner role message exchange " + pmex.getMessageExchangeId()); + __log.warn("Received a response for unknown partner role message exchange."); return; }

        Regards

        Show
        Rafal Rusin added a comment - Perfect, applied, thanks! Now you can move on. As for me, I liked this one (actually jbiMex.getExchangeId() should be displayed in warn here): Index: src/main/java/org/apache/ode/jbi/OdeConsumer.java =================================================================== — src/main/java/org/apache/ode/jbi/OdeConsumer.java (revision 908691) +++ src/main/java/org/apache/ode/jbi/OdeConsumer.java (working copy) @@ -144,7 +144,7 @@ private void outFailure(final InOut jbiMex) { PartnerRoleMessageExchange pmex = (PartnerRoleMessageExchange) _ode._server.getMessageExchangeByForeignKey(jbiMex.getExchangeId()); if (pmex == null) { - __log.warn("Received a response for unknown partner role message exchange " + pmex.getMessageExchangeId()); + __log.warn("Received a response for unknown partner role message exchange."); return; } Regards
        Hide
        Hudson added a comment -

        Integrated in ODE-trunk #252 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk/252/)
        : FindBugs Patches for ODE Runtime (static inner classes - thanks to David Carver)

        Show
        Hudson added a comment - Integrated in ODE-trunk #252 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk/252/ ) : FindBugs Patches for ODE Runtime (static inner classes - thanks to David Carver)
        Hide
        Hudson added a comment -

        Integrated in ODE-trunk-jdk6 #245 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk-jdk6/245/)
        : FindBugs Patches for ODE Runtime (static inner classes - thanks to David Carver)

        Show
        Hudson added a comment - Integrated in ODE-trunk-jdk6 #245 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk-jdk6/245/ ) : FindBugs Patches for ODE Runtime (static inner classes - thanks to David Carver)
        Hide
        David Carver added a comment -

        Yeah, I liked that possible null pointer one as well.

        I'll synchronize and provide the next patch.

        Show
        David Carver added a comment - Yeah, I liked that possible null pointer one as well. I'll synchronize and provide the next patch.
        Hide
        David Carver added a comment -

        Patch for performance, using valueOf can be 3.5 times faster because the values can be cached by the compiler and JVM.

        Show
        David Carver added a comment - Patch for performance, using valueOf can be 3.5 times faster because the values can be cached by the compiler and JVM.
        Hide
        Hudson added a comment -

        Integrated in ODE-trunk #253 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk/253/)
        : FindBugs valueOf patch (By David Carver)

        Show
        Hudson added a comment - Integrated in ODE-trunk #253 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk/253/ ) : FindBugs valueOf patch (By David Carver)
        Hide
        Hudson added a comment -

        Integrated in ODE-trunk-jdk6 #246 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk-jdk6/246/)
        : FindBugs valueOf patch (By David Carver)

        Show
        Hudson added a comment - Integrated in ODE-trunk-jdk6 #246 (See http://hudson.zones.apache.org/hudson/job/ODE-trunk-jdk6/246/ ) : FindBugs valueOf patch (By David Carver)
        Hide
        David Carver added a comment -

        Fixes several possible null pointer exceptions in various equals methods. Also makes use of a valueOf cacheing performance enhancements in a few places that were missed in the last patch.

        Show
        David Carver added a comment - Fixes several possible null pointer exceptions in various equals methods. Also makes use of a valueOf cacheing performance enhancements in a few places that were missed in the last patch.
        Hide
        Rafal Rusin added a comment -

        I see there are still tabs in this patch. Could you check it out?

        Show
        Rafal Rusin added a comment - I see there are still tabs in this patch. Could you check it out?
        Hide
        David Carver added a comment -

        The Tabs must be there in the original file as well, as my eclipse project wide settings are set to use spaces. If you have specific setting that you need for contributors to use, then I would suggest making sure that the various IDE's project settings are available.

        I've verified that my settings are set only to 4 spaces instead of the default of tabs.

        Show
        David Carver added a comment - The Tabs must be there in the original file as well, as my eclipse project wide settings are set to use spaces. If you have specific setting that you need for contributors to use, then I would suggest making sure that the various IDE's project settings are available. I've verified that my settings are set only to 4 spaces instead of the default of tabs.
        Hide
        Rafal Rusin added a comment -

        Thanks David!

        r942159 | rr | 2010-05-07 10:48:55 -0700 (pią) | 1 linia

        FindBugs Patches for ODE Runtime (thanks to David Carver)

        Show
        Rafal Rusin added a comment - Thanks David! r942159 | rr | 2010-05-07 10:48:55 -0700 (pią) | 1 linia FindBugs Patches for ODE Runtime (thanks to David Carver)

          People

          • Assignee:
            Unassigned
            Reporter:
            David Carver
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development