I actually expected all along that it was mounted storage objects
causing the error (this happens with any mounted storage, not just the
one defined in CST).    At least now we know it's the case.  I'm
surprised no one thought of doing this earlier.  ;-)

I suspect this has something to do with the _p_jar attribute of the
mounted storage object becoming None at some point after a commit.  That
said, I'm in over my head, and I'm going to need some help from others
at DC.  Since this error rarely gets raised at the user level, it hasn't
been a priority, and probably still won't be for some time, at least
until we get the steam up to put CST into Zope in some fashion.  Is it
causing you problems other than the error in the log?

- C

Chris Withers wrote:
> Chris McDonough wrote:
> >
> > python
> > import Zope
> > app = Zope.app()
> > ob = app._p_jar['\000\000\000\000\000(\347\026']
> > print ob.id
> > print ob.__class__
> Thanks, that worked, and sorry Chris, but I'm about to ruin your day :-S
> >>> app = Zope.app()
> >>> ob = app._p_jar['\000\000\000\000\000(\347\026']
> >>> print ob.id
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> AttributeError: id
> >>> print ob.__class__
> <extension class
> Products.CoreSessionTracking.SessionDataContainer.SessionDataContainerMount at
> 00BBDE10>
> >>>
> So it seems that even though I'm not actually using any CST stuff right now,
> it's still causing these errors...
> Any ideas?
> cheers,
> Chris

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to