[
http://jira.amdatu.org/jira/browse/AMDATU-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10407#comment-10407
]
Bram de Kruijff commented on AMDATU-177:
----------------------------------------
> There seems to be a mix of using/not using generics. ...
Yup, OSGi APIs for ManagedService and UserAdmin Entities do not use generics. I
could have dropped/duplicated the API for the internal entities but did not
think it worth the effort as it's simple internal code fully covered by junit
tests. Also I am not aware of a spec compliant suppressWarnings value for the
use of ra types? Anyway, IMHO it is minor and I propose to leave it as is.
> - In FSUserAdminStorageProvider m_logService is defined but never used. I
> would like to see some debug statements.
Done
> - In FSUserAdminStorageProvider a String hashcode is used as if it is always
> a unique identifier. Why not use the entity id?
Hashcode is easy and filesystem safe. Each store may contain multiple Role
entities for matching hashcodes but it also allows changing strategy by storing
more entities in a limited set of store (eg. using hashcode%100). I have added
the junit tests that validates that covers hashcode equality.
> In FSUserAdminStorageProvider role.USER should be Role.USER, same for other
> static variables
Fixed
> I notice many code duplication between FSUserAdmin and FSTenantStorage
> bundles. Couldn't that be moved to a shared bundle?
I'd consider that a nice improvement request. Give it some time to mature and
see how things work out when we move to clustered deployments.
> - Why is the physical file that persisted the role stored in FSRole?
> (m_internalRoleFile).
Dead code. Once I thought a FSRole.save() would by a good idea. Removed.
> - Why is the method 'removeTenantId' in FSRoleNameList named this way? Is
> this a copy-paste error?
Yea :o Fixed.
> I notice that in this implementation each access to useradmin ends up in at
> least 1 disk access, but most of the times more then 1.
> When authorization checks are added all over the code, we need some caching
> mechanism
Maybe. I did some tests resulting in keeping the FSRoleNames in memory for now.
Caching the stores with soft references in a map actually did not seem to
matter much. I guess that these frequently small accessed files will be kept
as close as possible by OS/FS and (de)serializing 1k isn't that much overhead
either. Then again, maybe.. and we could also consider non blocking writes.
> Implement filebased storage for pax useradmin
> ---------------------------------------------
>
> Key: AMDATU-177
> URL: http://jira.amdatu.org/jira/browse/AMDATU-177
> Project: Amdatu
> Issue Type: New Feature
> Components: Amdatu Core
> Reporter: Bram de Kruijff
> Assignee: Bram de Kruijff
> Fix For: 0.0.6
>
>
> Create a bundle (useradminstore-fs) that implements and publishes a filebased
> storage provider for the PAX Useradmin StorageProvider SPI (@see AMDATU-130).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
