Red Hat Bugzilla – Bug 786224
DriftManager is not in CLI API doc, nor the getDriftFileAsByteArray()
Last modified: 2013-09-01 15:21:37 EDT
+++ This bug was initially created as a clone of Bug #756086 +++ It is for the API documentation to include these methods mentioned in the BZ loggers repro steps ... DriftManager is not in CLI API doc, nor the getDriftFileAsByteArray() method.
Description of problem:
When running the CLI in interactive mode, the console throws a ClassCastException when calling a method that returns a byte array. Based on the exception, it looks like we might get the exception with any primitive array. Here is the exception:
java.lang.ClassCastException: [B cannot be cast to [Ljava.lang.Object;
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into the CLI console
2. Call a method that returns a Java byte array (I produced this by calling DriftManager.getDriftFileAsByteArray)
--- Additional comment from email@example.com on 2011-11-22 13:20:47 EST ---
cli only. does not affect drift-ui.
--- Additional comment from firstname.lastname@example.org on 2011-11-22 13:35:48 EST ---
cli only. does not affect drift-ui.
--- Additional comment from email@example.com on 2011-11-22 14:11:52 EST ---
And to further clarify, this bug is **not** related to drift. It is CLI-specific bug that I happened to stumble on while making some drift API calls. A user should be able to reproduce this exception by calling any method that returns a byte array and quite possibly an array of any other primitive type.
--- Additional comment from firstname.lastname@example.org on 2011-11-28 23:15:00 EST ---
(9:49:31 PM) ccrouch: jsanda: none of the normal drift use cases are impacted
by https://bugzilla.redhat.com/show_bug.cgi?id=756086# correct?
(9:50:02 PM) ccrouch: because otherwise we would have hit it before presumably?
(9:50:36 PM) ccrouch: i also doubt this is a regression from jon2.4
(9:51:12 PM) jsanda: looking...
(9:51:51 PM) jsanda: i don't think that this impacts drift use cases
(9:52:04 PM) jsanda: i also agree about it not being a regression
(9:52:25 PM) jsanda: the class in question has had problems since the inception
of the CLI
(9:52:33 PM) jsanda: these types of parsing problems that is
(9:53:41 PM) ccrouch: ok, given this is the first time we're hitting this, I'm
presuming this datatype is not very common in the api
(9:54:13 PM) jsanda: in the drift api or the cli api in general?
(9:55:21 PM) jsanda: i'd have to review the remote apis to see where we have
return type of byte array
(9:55:23 PM) ccrouch: the cli api in general
(9:55:39 PM) jsanda: we might in a few place
(9:55:40 PM) jsanda: s
(9:56:25 PM) ccrouch: ok, i'll assign it to lukas to take a look
--- Additional comment from email@example.com on 2011-11-28 23:15:05 EST ---
Lukas, can you have a quick investigate here. I'm particularly interested to
know if this is a regression from JON2.4. Also is a fix feasible? Small? Safe?
I'm suspicious of any changes in this area right before the release, since its
sounds like a fundamental aspect of the CLI
--- Additional comment from firstname.lastname@example.org on 2011-11-28 23:15:11 EST ---
(9:56:58 PM) jsanda: i think we have more places that take a byte array as a
param as opposed to having it as a return type
(9:57:27 PM) jsanda: also keep in mind that this is limited to the interactive
--- Additional comment from email@example.com on 2011-11-29 15:31:54 EST ---
this is not a regression and it has small impact, only because few APIs actually return arrays. note that this is a problem for both primitive and object arrays.
Will be writing unit tests in TabularWriterTest.
--- Additional comment from firstname.lastname@example.org on 2011-11-29 17:18:44 EST ---
committed to master: 756086
The DriftManager class is in the remote API:
Now, I can't find getDriftFileAsByteArray() in the API doc or in the 3.0 new/changed classes list for DriftManager. It looks like it was added on 11/19/2011. I could have sworn I didn't do the API generation until after Thanksgiving, but I may be mistaken. If I regen the API, that should get pulled in.
The method is in the regenerated docs:
And also in the 3.1 docs.
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.