Azure-sdk-for-java: [API Review] Auto-gen layer queue

• Because the value is in seconds. So why would we report it in miliseconds?
• These are generated types. We'd love to have them immutable but were told that the generator can't determine when types are supposed to be immutable.
• This is called Logging because that's the xml value the service accepts. I understand the confusion with client side logging, but I also don't think LogData is accurate. Maybe something like ServerLoggingConfigurations
• I think this can be a boolean. If metrics are enabled, it's a required parameter, so that should be ok.
• I'm fine with setName to be setQueueName. I think there's maybe a risk of "stuttering", but if Jonathan thinks it's more clear, then ok.
• I'm seeing QueueMessage is used in QueueAsyncClient (478 and 696(
• I believe this actually applies to QueueSegmentOptions, but it should be an Integer. It's optional.
• Left a comment inline about merging the StorageException types, but basically there are generator limits to this.
• This seems like it should be in line with whatever we decide for 3.
• This is the return value for getServiceStats, and this reflects how the service structures this data. Presumably if they created an object here, they are leaving space for future additions and we should do the same.

Regarding: Should these classes (e.g. EqueuedMessage) be made immutable? Remove setter and final member data.

The EnqueuedMessage model is used by post request.
It cannot be immutable under the case.

Update: Oct/15: This is no action, see above comments

Regarding: Rename Logging to LogData or ServerLoggingConfigurations?

Logging is generated from swagger

Once we agreed on renaming Logging to ServerLoggingConfigurations then we can change swagger and all languages will reflect this.

Logging Oct/15: This is addressed in the PR

Regarding: isIncludeAPIs() in Metrics return boolean instead of Boolean

Rick mentioned "I think this can be a boolean. If metrics are enabled, it's a required parameter, so that should be ok.", what if metrics is disabled (i.e. Metrics::enabled == false), is Metrics::includeAPIs set in this case as well?

• If yes, then need to update swagger required section to include the includeAPI property.

• If no, it will stay as boxed Boolean.

Update: Oct/15: This is no action, we will keep this as Boxed boolean. Rick checked the service modeling and response is:

I took another look at the xml object that the service expects. 
Because IncludeAPIs is a sibling of enabled, I think it works as follows:

if enabled = true, value is interpreted as boolean
if enabled = false, value is ignored and "should be set to null for clarity/safety"

Regarding:'m fine with setName to be setQueueName. I think there's maybe a risk of "stuttering", but if Jonathan thinks it's more clear, then ok.

Over wire service requires the property to be named “name”, but in SDKs we can rename to QueueName by applying x-ms-client-name attribute in QueueItem model. This will get reflected for all languages.
If we want to limit the change to JAVA only, then we have to change transformation layer

Update: Oct/15: the model itself is QueueItem and it will be better to continue calling this property name instead of queueName. This is the case with other Item types BlobItem, ContainerItem etc..

Regarding: QueueMessage class is not used anywhere, so moved to implementation.

A feature is there in Autorest java to address this. Now we’ve the ability to make the default models package to be in models and the custom types package implementation.models, this means we can put QueueMessage in implementation.models namespace.

Today Queue transformation has following configuration:

models-subpackage: implementation.models

custom-types: StorageError,StorageErrorException,StorageErrorCode,SignedIdentifier,EnqueuedMessage,DequeuedMessage,PeekedMessage,QueueMessage,QueueItem,StorageServiceProperties,StorageServiceStats,CorsRule,AccessPolicy,Logging,Metrics,RetentionPolicy

custom-types-subpackage: models

This will put all generated models under implementation.models except the those listed under custom-types. To move QueueMessage from models to implementation.models we just have to remove it the custom-types list.

Regarding: I'm seeing QueueMessage is used in QueueAsyncClient (478 and 696)

They are not used by clients but internally. That's why Jonathan asked to move to implementation folder.

Update: Oct/15: The QueueMessage model has been moved to implementation package in the PR.

Regarding: getMaxResults() in QueueItem return int instead of Integer?

As Rick has mentioned above, it is optional property from service perspective. So we cannot actually present it as an primitive integer in our SDK.

Update: Oct/15: This is no action, see above comments and discussion here.

Regarding: Extract StorageException to common module.

The reason StorageException exists in each package is - it transitively depends on StorageErrorCode type which is specific to each service. So it is better to leave as it is unless service decided to merge error code.

Update Oct/15: This is addressed in the PR by adding FileStorageException, BlobStorageException and QueueStorageException in each of the service specific SDK.

Regarding: setLogging in StorageServiceProperties whether can make it clear to differentiate from client-side logging.

This will be implicitly addressed once we decide on this.

Update: Oct/15: Resolved in the PR https://github.com/Azure/azure-sdk-for-java/pull/5868

Regarding: CorsRule getMaxAgeInSeconds() why not milliseconds and return long

and

Regarding: The necessity of StorageServiceStats as it only has one property field in class.

Refers Rick's response, there are no action item for SDK.

Update: Oct/15: This is no action, see above comments

All work items are addressed, issue can be closed.