Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47714

Remoting should be explicit about objects serializable only over the channel

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: remoting
    • Labels:
      None
    • Similar Issues:

      Description

      I discovered the issue during JENKINS-37566. `Channel#current()` uses thread-local storage to determine the current channel. It returns null if the channel does not exist Some writeReplace/readObject/etc. serialization logic retrieves the channel in order to export the object via ExportTable. Obviously, such operations will fail if we try to serialize the object without Remoting context.

      I propose to add a new interface to verify that serialization logic is being invoked for the remoting context and hence to avoid undesired NPEs

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Oleg Nenashev
            Path:
            pom.xml
            src/main/java/hudson/remoting/Callable.java
            src/main/java/hudson/remoting/Channel.java
            src/main/java/hudson/remoting/ClassLoaderHolder.java
            src/main/java/hudson/remoting/JarLoaderImpl.java
            src/main/java/hudson/remoting/Pipe.java
            src/main/java/hudson/remoting/ProxyOutputStream.java
            src/main/java/hudson/remoting/RemoteClassLoader.java
            src/main/java/hudson/remoting/RemoteInputStream.java
            src/main/java/hudson/remoting/RemoteInvocationHandler.java
            src/main/java/hudson/remoting/RemoteOutputStream.java
            src/main/java/hudson/remoting/RemoteWriter.java
            src/main/java/hudson/remoting/Request.java
            src/main/java/hudson/remoting/forward/ForwarderFactory.java
            src/main/java/hudson/remoting/forward/PortForwarder.java
            src/main/java/org/jenkinsci/remoting/SerializableOnlyOverRemoting.java
            src/test/java/hudson/remoting/ChannelFilterTest.java
            src/test/java/hudson/remoting/ChannelTest.java
            src/test/java/hudson/remoting/ClassFilterTest.java
            src/test/java/hudson/remoting/ClassRemotingTest.java
            src/test/java/hudson/remoting/PipeTest.java
            src/test/java/hudson/remoting/PrefetchingTest.java
            src/test/java/hudson/remoting/RemoteInvocationHandlerTest.java
            src/test/java/org/jenkinsci/remoting/protocol/ProtocolStackImplTest.java
            http://jenkins-ci.org/commit/remoting/d906a333f34860dbf3a3f0771b1c1dfd1e071ca6
            Log:
            JENKINS-47714 - Introduce SerializableOnlyOverRemoting and cleanup FindBugs in Channel#current(). (#206)

            • JENKINS-47714 - Introduce SerializableOnlyOverRemoting and cleanup FindBugs in Channel#current().

            `Channel#current()` uses thread-local storage to determine the current channel. It returns null if the channel does not exist Some writeReplace/readObject/etc. serialization logic retrieves the channel in order to export the object via ExportTable. Obviously, such operations will fail if we try to serialize the object without Remoting context.
            I propose to add a new interface to verify that serialization logic is being invoked for the remoting context and hence to avoid undesired NPEs.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: pom.xml src/main/java/hudson/remoting/Callable.java src/main/java/hudson/remoting/Channel.java src/main/java/hudson/remoting/ClassLoaderHolder.java src/main/java/hudson/remoting/JarLoaderImpl.java src/main/java/hudson/remoting/Pipe.java src/main/java/hudson/remoting/ProxyOutputStream.java src/main/java/hudson/remoting/RemoteClassLoader.java src/main/java/hudson/remoting/RemoteInputStream.java src/main/java/hudson/remoting/RemoteInvocationHandler.java src/main/java/hudson/remoting/RemoteOutputStream.java src/main/java/hudson/remoting/RemoteWriter.java src/main/java/hudson/remoting/Request.java src/main/java/hudson/remoting/forward/ForwarderFactory.java src/main/java/hudson/remoting/forward/PortForwarder.java src/main/java/org/jenkinsci/remoting/SerializableOnlyOverRemoting.java src/test/java/hudson/remoting/ChannelFilterTest.java src/test/java/hudson/remoting/ChannelTest.java src/test/java/hudson/remoting/ClassFilterTest.java src/test/java/hudson/remoting/ClassRemotingTest.java src/test/java/hudson/remoting/PipeTest.java src/test/java/hudson/remoting/PrefetchingTest.java src/test/java/hudson/remoting/RemoteInvocationHandlerTest.java src/test/java/org/jenkinsci/remoting/protocol/ProtocolStackImplTest.java http://jenkins-ci.org/commit/remoting/d906a333f34860dbf3a3f0771b1c1dfd1e071ca6 Log: JENKINS-47714 - Introduce SerializableOnlyOverRemoting and cleanup FindBugs in Channel#current(). (#206) JENKINS-47714 - Introduce SerializableOnlyOverRemoting and cleanup FindBugs in Channel#current(). `Channel#current()` uses thread-local storage to determine the current channel. It returns null if the channel does not exist Some writeReplace/readObject/etc. serialization logic retrieves the channel in order to export the object via ExportTable. Obviously, such operations will fail if we try to serialize the object without Remoting context. I propose to add a new interface to verify that serialization logic is being invoked for the remoting context and hence to avoid undesired NPEs. JENKINS-47714 - Address comments from @jglick JENKINS-47714 - Add @since to new API
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I have added the interface to Remoting 3.14 and already updated some classes in the core to implement it. IMHO it's done for now

            Show
            oleg_nenashev Oleg Nenashev added a comment - I have added the interface to Remoting 3.14 and already updated some classes in the core to implement it. IMHO it's done for now

              People

              • Assignee:
                oleg_nenashev Oleg Nenashev
                Reporter:
                oleg_nenashev Oleg Nenashev
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: