2013/3/4 Felix Meschberger <fmesc...@adobe.com>: > Hi, > > I have been looking into this some time ago. And I am also somewhat unhappy > with the read/write nature of the ResourceMetadata. > > While I think in general we can make the ResourceMetadata read-only, we have > a problem with code like: > >> resource.getResourceMetadata().setResolutionPathInfo(rpi); > > which is in ResourceResolverImpl.resolveInternal (line 805). This would break.
Yepp. > > We could see, whether it would be possible to make the ResourceMetadata > read-only after resource resolution has completed, e.g. > ResourceMetadata.lock(). But I am not really convinced. Yes, that's why I suggest that the resource resolver calls this method before returning the resource object. > > I am also not sure, what client application we would break with this change ? We will never know - so far I don't know any code putting stuff in here outside of the resource resolver. > > What happens in the Sling Launchpad Testing build if this would be read-only ? I couldn't find a reference to metadata in that module Carsten > > Regards > Felix > > > Am 01.03.2013 um 17:48 schrieb Carsten Ziegeler: > >> Hi, >> >> while looking into some issues, I realized that ResourceMetadata is >> not only extending a HashMap (which makes handling easier), but we >> have absolutely no information if this map can be changed by client >> code or is a read-only map. > >> >> I think we should add this to the documentation and make this >> read-only. We could either just document it or add a "make read-only" >> method to ResourceMetadata which is called by the resource resolver >> before the resource object is returned to the client code. >> >> But I think we should not allow client code to change/add/remove to >> ResourceMetadata. >> >> WDYT >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > -- Carsten Ziegeler cziege...@apache.org
