[Zope-dev] Running methods on Zope startup.

Toby Dickenson tdickenson@geminidataloggers.com
Thu, 25 Apr 2002 10:02:25 +0100


On Wed, 24 Apr 2002 21:56:52 -0600 (MDT), grahamd@dscpl.com.au wrote:

>Imagine a situation similar to database connections. With database =
connections
>when you create it you can indicate that you want the connection =
established.
>Now when Zope is restarted, those database connections will be =
automatically
>restarted when Zope restarts. Although, I am not sure whether this is =
when
>Zope actually starts or when the next request using that database =
happens.

The connection is made when the next request comes in, and the
connection is broken when ZODB decides it is time to deactivate the DA
object; which is hopefully only happens if the connection has not been
used for a while.

>I can't rely on
>the connection only starting when someone tries to access the resource, =
I
>want it to happen straight away upon Zope restart.

I think you will have to fight ZODB if you need:
* The connection to always stay up
* one connection per instance of a class stored in ZODB
  (like database adapters)

>Can anyone point me to such a Zope product. I have started looking at =
how
>to do it myself and have some of the bits in place. The first issue is =
that
>when the "initialize()" method in the product "__init__.py" file is =
called
>not all Zope startup has occured, so it is too early to trigger things =
from
>that point.

Initialize looks like the right place to me. What do you think this is
too early for?

One thing that might be nice to add is *dependencies* between product
initialization. Today you have to rely on Zope sorting product names
alphabetically before initialization, which slightly sucks.

>The next problem is getting an appropriate context to be able to start =
making
>calls into Zope objects. The "initialize()" method gets a product =
context,
>but doesn't have public access to the application context. Is there some=
 way
>of accessing the Zope application context and thus root folder where you
>don't otherwise have a handle to it?

Public access? no. currently you have to hack through the jar.

I agree there should be an API for this.



Toby Dickenson
tdickenson@geminidataloggers.com