adding getById support to resource collections that can support it#849
Conversation
…s that return a specific *Manager
|
Can one of the admins verify this patch? |
… collections via abstract method on ResourcesImpl
| * @param <ImplT> the individual resource implementation | ||
| */ | ||
| public abstract class ResourcesImpl<T, ImplT> | ||
| implements |
There was a problem hiding this comment.
ResourcesImpl or GroupableResourcesImpl ?
The items in this collection are groupable they extends from "GroupableResourceImpl"
There was a problem hiding this comment.
great point, though now in the process of addressing it I discovered that Deployments are weird - they're Groupable but they do not have a region, so they cannot inherit from GroupableResource right now. I'm looking into what should be one about that...
There was a problem hiding this comment.
Deployment is always seems a special case. just a thought, may be we can have 'DeploymentsImpl' not to inherit from 'ResourcesImpl' and have it implement getById() directly then we can impose bounding
GrouapbleResourcesImpl<T extends GroupableResource, ImplT extends GroupableResourceImpl>There was a problem hiding this comment.
yep, that's basically what I;m doing now.
I think Resource/GroupableResource may need to be rethought a little, later
adding a requirement for the other createFluentWrapper via an abstract method on the base class
…impls and into the common base class
…and into the base class
- GenericResources in Azure do not expose list across groups, and passing null fails, so removing .list() support - adding getByGroup() - adding getById() - enabling GenericResources to inherit from the same base class as other GroupableResources
…e class to remove the significant code repetition
adding getById support to resource collections that can support it
4 participants
Uh oh!
There was an error while loading. Please reload this page.