LogMojo: Change access modifiers to protected for use in XML configuration

[rohanKanojia]

Description

In #868, we changed variable names of these configuration options for log goal. Now that the variable names are correct, we can expose their access so that they can be used in plugin configuration:
https://github.com/eclipse/jkube/blob/85f507ef25ed5c3b9284db893032eaec0c963451/kubernetes-maven-plugin/plugin/src/main/java/org/eclipse/jkube/maven/plugin/mojo/develop/LogMojo.java#L36-L41

• Change access modifier from private to protected
• Test modifiers are working when used in plugin XML configuration

Second part can be tested by deploying some quickstart(for example quickstarts/maven/spring-boot to some Kubernetes Cluster and then adding these configuration options to plugin configuration. For example, this plugin configuration should not tail logs(default behavior is to follow logs) when mvn k8s:log/mvn oc:log is run:

<plugins>
   <plugin>
      <groupId>org.eclipse.jkube</groupId>
      <artifactId>kubernetes-maven-plugin</artifactId>
      <version>1.5.0-SNAPSHOT</version>

      <configuration>
          <logFollow>false</logFollow>
      </configuration>
   </plugin>
</plugins>

For testing on Kubernetes/OpenShift cluster, you can use minikube or Red Hat Developer Sandbox for OpenShift instance.

[yraydhitya]

May I take this?

[yraydhitya]

I have changed the access modifier and deployed the quickstart/maven/spring-boot in minikube. Added <logFollow>false</logFollow> above this line https://github.com/eclipse/jkube/blob/e212da5881cf25a64afa49b84132ab7aff6ed225/quickstarts/maven/spring-boot/pom.xml#L127 and execute mvn k8s:log -Pkubernetes, but the plugin still follow logs. Is the configuration placement correct? How do I know I am using the modified plugin code in my local?

[manusa]

The placement is fine, however you're probably testing with the released version and not the SNAPSHOT. Try running the following command mvn k8s:log -Pkubernetes -Djkube.version=1.5.0-SNAPSHOT

[yraydhitya]

I missed installing the plugin after changing the code. The goal now logs the deployment and terminates with below exception.

javax.net.ssl.SSLException: Socket closed
    at sun.security.ssl.Alert.createSSLException (Alert.java:127)
    at sun.security.ssl.TransportContext.fatal (TransportContext.java:349)
    at sun.security.ssl.TransportContext.fatal (TransportContext.java:292)
    at sun.security.ssl.TransportContext.fatal (TransportContext.java:287)
    at sun.security.ssl.SSLSocketImpl.handleException (SSLSocketImpl.java:1591)
    at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:989)
    at okio.Okio$2.read (Okio.java:140)
    at okio.AsyncTimeout$2.read (AsyncTimeout.java:237)
    at okio.RealBufferedSource.request (RealBufferedSource.java:68)
    at okio.RealBufferedSource.require (RealBufferedSource.java:61)
    at okio.RealBufferedSource.readByte (RealBufferedSource.java:74)
    at okhttp3.internal.ws.WebSocketReader.readHeader (WebSocketReader.java:117)
    at okhttp3.internal.ws.WebSocketReader.processNextFrame (WebSocketReader.java:101)
    at okhttp3.internal.ws.RealWebSocket.loopReader (RealWebSocket.java:274)
    at okhttp3.internal.ws.RealWebSocket$2.onResponse (RealWebSocket.java:214)
    at okhttp3.RealCall$AsyncCall.execute (RealCall.java:203)
    at okhttp3.internal.NamedRunnable.run (NamedRunnable.java:32)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    at java.lang.Thread.run (Thread.java:829)
Caused by: java.net.SocketException: Socket closed
    at java.net.SocketInputStream.socketRead0 (Native Method)
    at java.net.SocketInputStream.socketRead (SocketInputStream.java:115)
    at java.net.SocketInputStream.read (SocketInputStream.java:168)
    at java.net.SocketInputStream.read (SocketInputStream.java:140)
    at sun.security.ssl.SSLSocketInputRecord.read (SSLSocketInputRecord.java:478)
    at sun.security.ssl.SSLSocketInputRecord.readHeader (SSLSocketInputRecord.java:472)
    at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket (SSLSocketInputRecord.java:70)
    at sun.security.ssl.SSLSocketImpl.readApplicationRecord (SSLSocketImpl.java:1364)
    at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:973)
    at okio.Okio$2.read (Okio.java:140)
    at okio.AsyncTimeout$2.read (AsyncTimeout.java:237)
    at okio.RealBufferedSource.request (RealBufferedSource.java:68)
    at okio.RealBufferedSource.require (RealBufferedSource.java:61)
    at okio.RealBufferedSource.readByte (RealBufferedSource.java:74)
    at okhttp3.internal.ws.WebSocketReader.readHeader (WebSocketReader.java:117)
    at okhttp3.internal.ws.WebSocketReader.processNextFrame (WebSocketReader.java:101)
    at okhttp3.internal.ws.RealWebSocket.loopReader (RealWebSocket.java:274)
    at okhttp3.internal.ws.RealWebSocket$2.onResponse (RealWebSocket.java:214)
    at okhttp3.RealCall$AsyncCall.execute (RealCall.java:203)
    at okhttp3.internal.NamedRunnable.run (NamedRunnable.java:32)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    at java.lang.Thread.run (Thread.java:829)

The exception confused me a little bit. I thought there was some problem with the execution. Is this the expected behavior?