# Transaction groups triggered expression item updating when trigger is false **URL:** \ **Category:** Ignition\ **Created:** [March 2, 2018, 3:35pm UTC](https://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196 "2018-03-02T15:35:43Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 15, 2018, 1:53pm UTC](https://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196/12 "2018-03-15T13:53:58Z")
Interesting. That means custom methods behave like custom properties in java-to-jython conversions. So, Java objects have to be wrapped in jython shells to be used within the jython interpreter. The standard java-to-jython shell exposes the methods as-is and also takes any methods that fit the NetBeans getter/setter naming conventions and exposes those as the corresponding properties. Ignition overrides the standard conversions so that its components have their custom properties and methods injected into the instance dictionary. This override must have some explicit call requirement as I’ve noted that once wrapped in a jython shell, most java methods that return a component won’t inject that component’s custom properties. So the binding’s `getTarget()` method yields a bare component instead of invoking Ignition’s extended wrapper. I may have to experiment with Jython’s `.toPy()` type registry to see if I can figure it out. Or maybe someone from IA will pipe up with a hint. @Carl.Gould ? --- _[View the full topic](https://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196)._