# Adding listeners to Ignition

**URL:** <https://forum.inductiveautomation.com/t/adding-listeners-to-ignition/53997>\
**Category:** Ignition\
**Created:** [December 10, 2021, 4:45pm UTC](https://forum.inductiveautomation.com/t/adding-listeners-to-ignition/53997 "2021-12-10T16:45:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\
**Post date:** [December 10, 2021, 4:45pm UTC](https://forum.inductiveautomation.com/t/adding-listeners-to-ignition/53997/1 "2021-12-10T16:45:16Z")

</div>

> [@Global objects in Perspective Scope](https://forum.inductiveautomation.com/t/global-objects-in-perspective-scope/53688/5):
>
> but would include anywhere you’ve added a listener into Ignition’s infrastructure.

Something I have been thinking about since you wrote this, how would one do this? I didnt realize this was possible with the way Ignition orchestrates the jython unless I am overcomplicating how I would think this worked. Do you have a link to a forum example of this?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [December 10, 2021, 4:56pm UTC](https://forum.inductiveautomation.com/t/adding-listeners-to-ignition/53997/2 "2021-12-10T16:56:03Z")

</div>

There’s a _lot_ of places you could theoretically add a listener to Ignition code. A very common pattern in Ignition (and Java overall, for that matter) is for there to be some central ‘manager’ for a subsystem, and for it to manage a list of ‘listener’ classes. The manager will automatically invoke the appropriate method on every listener it has ‘registered’ when the matching event fires.

So, you could get an instance of the `ProjectManager` from the gateway context, then [add a `ProjectListener`](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.12/com/inductiveautomation/ignition/gateway/project/ProjectManagerBase.html#addProjectListener(com.inductiveautomation.ignition.common.project.ProjectListener)). You call `addProjectListener` with your own instance of the [`ProjectListener`](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.12/com/inductiveautomation/ignition/common/project/ProjectListener.html) interface (in Java, it’s very easy to make anonymous classes; it’s somewhat more awkward from Python/Jython).  
Then you just do whatever action you need to in the methods defined by the interface; e.g. if you need to trigger some cleanup when a project is deleted, you could do that accordingly.

The complication when doing things like this from scripting, rather than through a module, is that Jython’s compilation process is _complicated_. There’s lots of references and caching and various other layers involved. It’s very easy to add a listener to some persistent object on the gateway - but if you don’t take steps, when you next make an update to your script library, the entire Jython interpreter will be removed and recreated. Normally that can happen and be cleaned up by the garbage collector - but your custom listener class can have a backreference _to the the entire Jython instance_ - meaning a large chunk of memory is unable to be released.

_That_ is why adding listeners is very fraught and Phil cautions against it so much.