Unico Hommes <[EMAIL PROTECTED]> wrote: >>> A related change I need to make is described here: >>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699 this will >>> not only improve performance of querying for a specific property >>> but is prerequisite for setting properties via the >>> SourceDescriptionManager. >> >> I'm not sure. >> What exactly is the meaning of the returned Strings? >> > > They identify a property type: namespace + "#" + propname. The > previous implementation of the inspector manager's > getSourceProperty() method was looping over all registered inspectors > until it found the property it was looking for. > > In order to make this process more efficient the manager needs to > register the individual inspectors to handle specific properties. The > getExposedPropertyTypes() method enables this. > >> Is it all properties "supported" by a particular SourceInspector >> implementation? > > Yes. > >> What if it supports any within a particular namespace? >> What if it support any within any namespace? >> >> How would that be represented? > > Nothing in place for that yet, but we could add it easily. Just need a > convention. What about using wildcards for this: > > *#myprop > myns#* > *#* > > This way a simple jdbc descriptor that stores properties as key value > pairs in a database can assert it is general enough to handle any > property. The manager then looks for an inspector in order from most > specific (exact match) to least specific (*#*).
The way the manager caches the values for lookups looks to me like sacrifying a lot of flexibility. I don't really see a way to avoid the looping (Is it really that costly?). Caching the set of supported properties is ok, but it should be a concern of the individual SourceInspector implementation IMO, since it could change at runtime (think access control for instance). That might also be a reason for the above lookup mechanism to break. Guido
