Description of problem: Unable to package a JBoss ON remote client as an executable JAR due to: java.lang.NullPointerException at org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:328) at org.apache.maven.artifact.versioning.ComparableVersion.<init>(ComparableVersion.java:322) at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:495) ... 4 more Version-Release number of selected component (if applicable): 3.2.0.CR1 How reproducible: Always Steps to Reproduce: 1. Using Red Hat JBoss Developer Studio, create a Java client project that connects to a JBoss ON server. 2. Package/export the client as an Executable JAR using either "Package required libraries into generated JAR" or "Extract required libraries into generated JAR" 3. Execute the JAR: java -Drhq.client.version-check=false -jar my-jon-client.jar Actual results: Client fails to connect with one of the following exceptions: Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58) Caused by: java.lang.IllegalStateException: Cannot determine if server version is supported. at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:499) at org.rhq.enterprise.clientapi.RemoteClient.doConnect(RemoteClient.java:408) at org.rhq.enterprise.clientapi.RemoteClient.connect(RemoteClient.java:200) at com.redhat.gss.example.jboss.on.Connection.connect(Connection.java:97) at com.redhat.gss.example.jboss.on.remote.client.TestConnection.main(TestConnection.java:22) ... 5 more Caused by: java.lang.NullPointerException at org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:328) at org.apache.maven.artifact.versioning.ComparableVersion.<init>(ComparableVersion.java:322) at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:495) ... 9 more Or: Exception in thread "main" java.lang.IllegalStateException: Cannot determine if server version is supported. at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:499) at org.rhq.enterprise.clientapi.RemoteClient.doConnect(RemoteClient.java:408) at org.rhq.enterprise.clientapi.RemoteClient.connect(RemoteClient.java:200) at com.redhat.gss.example.jboss.on.Connection.connect(Connection.java:97) at com.redhat.gss.example.jboss.on.remote.client.TestConnection.main(TestConnection.java:25) Caused by: java.lang.NullPointerException at org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:328) at org.apache.maven.artifact.versioning.ComparableVersion.<init>(ComparableVersion.java:322) at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:495) ... 4 more Expected results: Client should connect without error. Additional info: The NPE is a result of checkServerSupported's blind assumption that a manifest is always in tact. In this case, it is not and therefore there is no implementation version header available due to the JAR spec itself (the client library is contained as part of an executable application). To get past the NPE, a null or undefined implementation version on the client should result in a version mismatch if rhq.client.version-check is set to true.
in master commit ff3f8116ea792b6d911b48cb058afa068c550eb7 Author: Libor Zoubek <lzoubek> Date: Fri Feb 7 17:37:43 2014 +0100
release/jon3.2.x commit 4c4ee8f5b9db078515a29dc81c74ebd6e0442fc4 Cherry-Pick master ff3f8116ea792b6d911b48cb058afa068c550eb7 Signed-off-by: Jay Shaughnessy <jshaughn>
Moving to ON_QA as available for testing in the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=336752 Note: the installed version is still JON 3.2.0.GA by design and this represents part of the payload for JON 3.2.1 also known as cumulative patch 1 for 3.2.0.GA. How this will be delivered to customers is still being discussed.
Version info: Server Version: 3.2.0.GA Server Build Number: d18651a:f535707 Client version: Same as server (required jars copied from JON server CLI client) 1) Tested with "Package required libraries into generated JAR" ------------------------------------------------------------------ [jkandasa@jkandasa java-client]$ java -Drhq.client.version-check=true -jar my-client.jar Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58) Caused by: java.lang.IllegalStateException: This client [ undefined ] does not support the remote server [3.2.0.GA] at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:512) at org.rhq.enterprise.clientapi.RemoteClient.doConnect(RemoteClient.java:408) at org.rhq.enterprise.clientapi.RemoteClient.connect(RemoteClient.java:200) at com.redhat.qe.jon.client.Client.getRemoteClient(Client.java:16) at com.redhat.qe.jon.client.Client.main(Client.java:29) ... 5 more [jkandasa@jkandasa java-client]$ java -Drhq.client.version-check=false -jar my-client.jar 0 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ undefined ] does not support the remote server [3.2.0.GA] - 'rhq.client.version-check' was not set to true so this client will be allowed to continue but expect errors 11 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ undefined ] does not support the remote server [3.2.0.GA] - 'rhq.client.version-check' was not set to true so this client will be allowed to continue but expect errors 98 [main] INFO com.redhat.qe.jon.client.Client - IsConnnected?: true 98 [main] INFO com.redhat.qe.jon.client.Client - Server Version: 3.2.0.GA 98 [main] INFO com.redhat.qe.jon.client.Client - Server Build Number: d18651a:f535707 98 [main] INFO com.redhat.qe.jon.client.Client - Subject: Subject[id=2,name=rhqadmin] ------------------------------------------------------------------ 2) Tested with "Extract required libraries into generated JAR" ------------------------------------------------------------------ [jkandasa@jkandasa java-client]$ java -Drhq.client.version-check=true -jar my-client.jar Exception in thread "main" java.lang.IllegalStateException: This client [ undefined ] does not support the remote server [3.2.0.GA] at org.rhq.enterprise.clientapi.RemoteClient.checkServerSupported(RemoteClient.java:512) at org.rhq.enterprise.clientapi.RemoteClient.doConnect(RemoteClient.java:408) at org.rhq.enterprise.clientapi.RemoteClient.connect(RemoteClient.java:200) at com.redhat.qe.jon.client.Client.getRemoteClient(Client.java:16) at com.redhat.qe.jon.client.Client.main(Client.java:29) [jkandasa@jkandasa java-client]$ java -Drhq.client.version-check=false -jar my-client.jar 0 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ undefined ] does not support the remote server [3.2.0.GA] - 'rhq.client.version-check' was not set to true so this client will be allowed to continue but expect errors 15 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ undefined ] does not support the remote server [3.2.0.GA] - 'rhq.client.version-check' was not set to true so this client will be allowed to continue but expect errors 58 [main] INFO com.redhat.qe.jon.client.Client - IsConnnected?: true 58 [main] INFO com.redhat.qe.jon.client.Client - Server Version: 3.2.0.GA 59 [main] INFO com.redhat.qe.jon.client.Client - Server Build Number: d18651a:f535707 59 [main] INFO com.redhat.qe.jon.client.Client - Subject: Subject[id=2,name=rhqadmin] ------------------------------------------------------------------ In both cases it is failing if we pass "-Drhq.client.version-check=true" and it is passing with error message if we pass "-Drhq.client.version-check=false". As we have client/server version check, we have to keep client version some where in jar file (like rhq-client.properties). Should be included while chosing the option "Package required libraries into generated JAR" or "Extract required libraries into generated JAR". We can continue as "-Drhq.client.version-check=false", however user do not know which version of remote client is he/she using after some time period. Might lead them in confusion state, like is it new version of client or old one.
This BZ is not about the way how we store client version (now in jar manifest) This BZ is about NPE in case user grabs our classes to his own jar, so our manifest gets lost. That NPE does not occur anymore. Please note that in most cases customer will depend on our jars and will not extract classes from our jars as described in repro steps (hopefully we will follow our samples). For sure we can possibly make an improvement with storing client version in property file within resources, I'd suggest filing another BZ for it.
Right. This is probably a logging issue as I do see that the error is still being displayed. But I think this is because we tend to make our remote client libraries spammy. Basically, from what I can see: (In reply to Jeeva Kandasamy from comment #4) > [jkandasa@jkandasa java-client]$ java -Drhq.client.version-check=false -jar > my-client.jar > 0 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ > undefined ] does not support the remote server [3.2.0.GA] - > 'rhq.client.version-check' was not set to true so this client will be > allowed to continue but expect errors > 11 [main] ERROR org.rhq.enterprise.clientapi.RemoteClient - This client [ > undefined ] does not support the remote server [3.2.0.GA] - > 'rhq.client.version-check' was not set to true so this client will be > allowed to continue but expect errors > 98 [main] INFO com.redhat.qe.jon.client.Client - IsConnnected?: true > 98 [main] INFO com.redhat.qe.jon.client.Client - Server Version: 3.2.0.GA > 98 [main] INFO com.redhat.qe.jon.client.Client - Server Build Number: > d18651a:f535707 > 98 [main] INFO com.redhat.qe.jon.client.Client - Subject: > Subject[id=2,name=rhqadmin] Makes me believe that the client did execute successfully but that RemoteClient was spitting some ERROR nonsense out to stdout -- Essentially, this wasn't an error because the version check is disabled and the client doesn't throw an exception. Therefore, this BZ should probably be considered verified. That is not to say that our poor design decisions and implementation shouldn't be address: 1. Use serialVersionUID to handle API version compliance or some other API static version identifier stored in the API itself. Never use property or other text files that can be modified or separated from the library classes accidentally or deliberately. 2. Not perform string literal matching as a means to handle version compatibility. Instead, use API compatibility and dependability definitions to indicate which API implementations are required. Yes, APIs are forward and backward compatible in many respects. I can still use the same version of EJB and JBoss Remoting that was in use in 2008 with JBoss EAP 6 released in 2013. No need to tightly couple these. If we actually had a quality API, no version check would even be necessary as this would all happen internally. "Oh, you are version 1... then I will talk to you using version one compatible commands/signatures." "Oh, you are version 8, great, so am I ... we can talk openly." ... but again, as Libor indicates, this bug was limited to the NPE causing premature termination of the code. I am moving to ON_QA for final acknowledgment from QE to ensure verification and test case has been documented.
Version info: Server Version: 3.2.0.GA Server Build Number: d18651a:f535707 Client version: Same as server (required jars copied from JON server CLI client) As it is not throwing NPE anymore, I am moving this bug to verified state. I have logged another bug to track "Remote API client version is 'undefined' when client is packaged as executable JAR" https://bugzilla.redhat.com/show_bug.cgi?id=1075875
JON 3.2.1 released week of 5/5/2014