Aloha, just a quick response from my vacation :) > >> I've a few comments. I think we don't need constants for workspace or >> session for the login stuff. At least the workspace should/could be >> a configuration of the jcr resource resolver factory. > > One the one hand, this is true, yes. On the other hand considering, that > we might want to provide access to different workspaces (or even > repositories ?) depending on the actual request, we probably need such > runtime indication in the credentials. Hmm, not sure :) Yes, we should be able to access different workspaces and repositories. But isn't this rather a config of the JcrResourceResolverFactory? So far we have no mechanism where the request controls which factories are used. And I think we don't need this. It's rather a "static" config of the available factories.
> > Whether a ResourceProviderFactory logs in upfront or on-demand is > probably an implementation detail. Yes. > On the other hand considering, that > we might want to use ResourceProviderFactory "login" as a means to > authenticate the request as a whole, at least one > ResourceProviderFactory must log in upfront to be able to do so. Yes, definitly. > So a ResourceProviderFactory would "enhance" the credentials with - say > - a JCR Session, which may be used by other ResourceProviderFactory > instances to short cut login ? Sounds reasonable. Not sure, whether we > have to "codify" this ? Hmm, I was rather thinking that the "main" or "leading" factory is able to add any properties to the login, like a db user and password or something like that. All we need for this is that we allow "login" to modify the map and pass the modified map to other factories. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
