Laurence Rowe wrote: [snip]
I fear that if we rely on the site manager set during traversal, then applications will rely on that when looking up their session in application code, and it will be impossible to involve objects from different application instances in the same transaction.
As I pointed out earlier in the thread, all *other* getUtility calls in a typical application don't use an explicit context anyway. If you're going to call from one application into another without changing your site explicitly before you do the call, you're going to be in for a world of trouble *anyway*. Let's teach people to use manual setSite() when they have two cooperating applications and forget about explicitly setting the context. [snip]
I wouldn't consider accessing objects from /appA and /appB in the same request broken, for someone coming from a ZODB background it would seems quite reasonable.
In fact, Zope 3 hasn't supported this pattern for years now. If appA calls a method in appB which looks up a local utility that only is registered for appB, that local utility *won't be found*. You need to explicitly use setSite() before you make the call in order to make this work properly. Unless appB *only* uses explicit contexts everywhere to look up its utilities (and adapters, and views, actually, as these can also be overridden in a local site manager!), and you really can't be counting on that. I think it's a bad idea to have one pattern for ZODB use (where we use local utilities and site managers and so on) and another one for non-ZODB use. SQLAlchemy already supports much of our use case with scoped sessions. The open problem is how to set up the right engine for the current session, and we can use utility lookup for that. Local site managers are not ZODB-bound as far as I know. Regards, Martijn