I was talking about the use of generics internally. For example the class FSRoleStorage at line 143 specifically creates a raw typed Dictionary. IMHO using generics here would have been better. At least that reduces the number of warnings Eclipse gives me... ;->
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: vrijdag 26 november 2010 0:03 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] [JIRA] Commented: (AMDATU-177) Implement filebased storage for pax useradmin On 25 Nov 2010, at 19:39 , Bram de Kruijff (JIRA) wrote: > [ > 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. Me too. No OSGi API uses generics, because the whole framework should still run on CDC/Foundation profile. There is work within the OSGi Alliance to start using generics, but until that's part of the spec I would not bother. For our own APIs I would say generics are fine, if they help improve code readability. >> 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. In general I would say stick the common code in a library and include that library in both bundles. Creating shared bundles creates a lot of extra dependencies between components: we might end up having to restart the whole application if all stores end up sharing code and we want to update that. >> 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. File systems have great caches built into them by the operating system, so I would be surprised if you were able to get big differences in performance here. Also, if we really want a cache, we should still not stick it in this bundle (a discussion we've had before). Greetings, Marcel _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
