Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.M1
    • Fix Version/s: 3.2.0.M2
    • Component/s: SUPPORT
    • Labels:
      None

      Description

      I raised this bug as 'trivial' because the exceptions don't get logged or otherwise visible to users. However, they are mighty annoying when debugging anything in STS.

      I like to have a NPE triggered breakpoint, because, usually, NPEs are bugs that should be fixed, and browsing around their execution context is mighty useful. But since the introduction of UAA it has become very annoying that my NPE breakpoint is constantly being hammered by a UAA thread.

      Stacktrace:

      Daemon Thread [Reporting Thread-1 (Spring UAA/1.0.2)] (Suspended (exception java.lang.NullPointerException))	
      	org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).flush() line: 123 [local variables unavailable]	
      	org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).close() line: 140	
      	org.springframework.uaa.client.util.Base64$OutputStream.close() line: 2027	
      	org.springframework.uaa.client.util.Base64.encodeBytesToBytes(byte[], int, int, int) line: 929	
      	org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int, int, int) line: 831	
      	org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int) line: 760	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).saveProductUse(org.springframework.uaa.client.protobuf.UaaClient$ProductUse$Builder) line: 550	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerProductUsage(org.springframework.uaa.client.protobuf.UaaClient$Product, byte[], java.lang.String, boolean, boolean) line: 672	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerInfrastructureProducts() line: 595	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).rebuildPersistedDetails(boolean) line: 309	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 193	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension.getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 95	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeature(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 901	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeatureUseIfMatch(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 822	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$2.run() line: 187	
      	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable) line: 886	
      	java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 908	
      	java.lang.Thread.run() line: 662	
      

        Activity

        Hide
        Tomasz Zarna added a comment -

        Kris, have you tried disabling UAA in your runtime STS instance? Also, do you think it's a bug in STS or is it more an issue with UAA client (org.springframework.uaa.client) itself?

        Show
        Tomasz Zarna added a comment - Kris, have you tried disabling UAA in your runtime STS instance? Also, do you think it's a bug in STS or is it more an issue with UAA client (org.springframework.uaa.client) itself?
        Hide
        Kris De Volder (c) added a comment -

        1) Yes UAA is disabled.

        2) Not sure, but from the stacktrace I'd say it is the uaa client trying to close something that's not actually there.

        Show
        Kris De Volder (c) added a comment - 1) Yes UAA is disabled. 2) Not sure, but from the stacktrace I'd say it is the uaa client trying to close something that's not actually there.
        Hide
        Tomasz Zarna added a comment - - edited

        It's a bug in UAA client, below is snippet from org.springframework.uaa.client.util.Base64:

                    try {
                        // GZip -> Base64 -> ByteArray
                        baos = new java.io.ByteArrayOutputStream();
                        b64os = new Base64.OutputStream( baos, ENCODE | options );
                        gzos  = new java.util.zip.GZIPOutputStream( b64os );
        
                        gzos.write( source, off, len );
                        gzos.close();
                    }   // end try
                    catch( java.io.IOException e ) {
                        // Catch it and then throw it immediately so that
                        // the finally{} block is called for cleanup.
                        throw e;
                    }   // end catch
                    finally {
                        try{ gzos.close();  } catch( Exception e ){}
                        try{ b64os.close(); } catch( Exception e ){}
                        try{ baos.close();  } catch( Exception e ){}
                    }   // end finally
        

        As you can see gzos is a wrapper around b64os, which in turn wraps baos. The thing is that when gzos.close() is called for the first time (last line in the try clause) it nulls b64os's out field. Next, in the finally block we close each stream. gzos is safe as it checks if it's already closed before proceeding, mind the closed flag:

            public void close() throws IOException {
                if (!closed) {
                    finish();
                    if (usesDefaultDeflater)
                        def.end();
                    out.close();
                    closed = true;
                }
            }
        

        b64os fails as it calls super.close() (java.io.FilterOutputStream.close()) which tries to flush the stream first, but the stream is already null. Bang! You have your NPE.

        Show
        Tomasz Zarna added a comment - - edited It's a bug in UAA client, below is snippet from org.springframework.uaa.client.util.Base64 : try { // GZip -> Base64 -> ByteArray baos = new java.io.ByteArrayOutputStream(); b64os = new Base64.OutputStream( baos, ENCODE | options ); gzos = new java.util.zip.GZIPOutputStream( b64os ); gzos.write( source, off, len ); gzos.close(); } // end try catch ( java.io.IOException e ) { // Catch it and then throw it immediately so that // the finally {} block is called for cleanup. throw e; } // end catch finally { try { gzos.close(); } catch ( Exception e ){} try { b64os.close(); } catch ( Exception e ){} try { baos.close(); } catch ( Exception e ){} } // end finally As you can see gzos is a wrapper around b64os , which in turn wraps baos . The thing is that when gzos.close() is called for the first time (last line in the try clause) it nulls b64os 's out field. Next, in the finally block we close each stream. gzos is safe as it checks if it's already closed before proceeding, mind the closed flag: public void close() throws IOException { if (!closed) { finish(); if (usesDefaultDeflater) def.end(); out.close(); closed = true ; } } b64os fails as it calls super.close() ( java.io.FilterOutputStream.close() ) which tries to flush the stream first, but the stream is already null . Bang! You have your NPE.
        Hide
        Christian Dupuis added a comment -

        I fixed this bug in the UAA client lib and sent the jar to Martin for inclusion with STS.

        Christian

        Show
        Christian Dupuis added a comment - I fixed this bug in the UAA client lib and sent the jar to Martin for inclusion with STS. Christian
        Hide
        Christian Dupuis added a comment -

        Over to you Martin for inclusion in STS/Spring IDE.

        Show
        Christian Dupuis added a comment - Over to you Martin for inclusion in STS/Spring IDE.
        Hide
        Martin Lippert (c) added a comment -

        Awesome, thanks!!! Can you send me the source bundle as well?

        Show
        Martin Lippert (c) added a comment - Awesome, thanks!!! Can you send me the source bundle as well?
        Hide
        Martin Lippert (c) added a comment -

        Updated the UAA client lib to the new 1.0.3 release version.

        Show
        Martin Lippert (c) added a comment - Updated the UAA client lib to the new 1.0.3 release version.

          People

          • Assignee:
            Martin Lippert (c)
            Reporter:
            Kris De Volder (c)
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: