OK, got it now. I'd say the path to go is one level above the stores then. There are those interfaces Structure, Security, Macro, etc. with their respective default implementations StructureImpl, ACLSecurityImpl, MacroImpl, etc. All those interfaces/classes get the SlideToken in all their relevant methods. Have a look at SecurityImpl.getPrincipal to get an idea how to find the user stored in CredentialsToken accessed by SlideToken.getCredentialsToken() and what to do with it then. So, what I would propose is changing those implementations to your needs. I do not think those implementations are really configurable, but at least they are all initialized in the ctor of NamespaceAccessTokenImpl. Just change it there for now. If you get it all working, I am pretty sure we will find a way to integrate all this into Slide and make it configurable.Ok, it is looking easier. Big win was the use of the ThreadLocal to store the TxId, yea!
Oliver
That means that in AbstractWebdavMethod I can patch it to add
/**
* ThreadLocal containing referenceable activeTransactionBranch
*/
protected ThreadLocal activeTransactionBranch = new ThreadLocal();then in run(...)
public void run(HttpServletRequest req, HttpServletResponse resp)
throws WebdavException {
Object TxId = null; //transaction Id
OllieTransactionTracker ott = OllieTransactionTracker.getSingleton();
this.req = req;
this.resp = resp;
this.slideToken = WebdavUtils.getSlideToken(req);
this.requestUri = WebdavUtils.getRelativePath(req, config);
parseRequestHeaders();
boolean transactionIsStarted = false;
try {
parseRequest();
if (methodNeedsTransactionSupport()) {
token.begin();
TxId = this.activeTransactionBranch.get();
ott.put(TxId, this);
transactionIsStarted = true;
}// clear expired lock-tokens
try {
UnlockListener listener =
new UnlockListenerImpl( slideToken, token, config, req, resp );
lock.clearExpiredLocks( slideToken, requestUri, listener );
}
catch (SlideException e) {}
executeRequest();
if (methodNeedsTransactionSupport()) {
token.commit();
ott.remove(TxId);
transactionIsStarted = false;
}
} catch (WebdavException ex) {
// Ignore the WebDav Exception and assume that the response code
// is already set.
} catch (Exception ex) {
token.getLogger().log(ex,LOG_CHANNEL,Logger.ERROR);
int statusCode = WebdavStatus.SC_INTERNAL_SERVER_ERROR;
sendError( statusCode, ex );
throw new WebdavException( statusCode );
} finally {
if (transactionIsStarted && methodNeedsTransactionSupport()) {
// Something went wrong, we are here and the TA is still open
try {
token.rollback();
ott.remove(TxId);
} catch (Exception e) {
}
}
}
}
Since the TxId is stored in the ThreadLocal variable when the TxId is generated in start() and I can get the TxId in any of the Stores....my OllieTransactionTracker (not really what I will call it...;) will have the reference to the instance of AbstractWebdavMethod with all its goodies available to my Custom Stores....
Only question now is how to implement this, AbstractJ, or apply a patch to AbstractWebdavMethod?
As a suggestion, perhaps Slide would be able to subclass ThreadLocal to make the whole ThreadLocal map accessible and store some useful references in there like
in AbstractWebdavMethod:
SlideLocal sl = new SlideLocal();
Map slideMap = sl.getMap();
slideMap.put("AbstractWebdavMethod", this);and instead of
ThreadLocal activeTransactionBranch = new ThreadLocal(); ... activeTransactionBranch.set(txId);
it would be
SlideLocal activeTransactionBranch = new SlideLocal();
...
activeTransactionBranch.getMap().put("TxId", txId);I think this would be clean and easy.
Ollie
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
