# Ignition 8 ExtensibleComponents without Extension Functions **URL:** \ **Category:** 3rd Party Modules\ **Tags:** vision, ignition81, ignition80\ **Created:** [November 10, 2020, 5:59pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499 "2020-11-10T17:59:59Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![kevin.cheong](https://avatars.discourse-cdn.com/v4/letter/k/b9e5f3/32.png) [@kevin.cheong](https://forum.inductiveautomation.com/u/kevin.cheong)\ **Post date:** [November 10, 2020, 5:59pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/1 "2020-11-10T17:59:59Z")
Hello IA, When developing a Vision Component that implements the ExtensibleComponent interface on ignition 8 (8.0 and 8.1), at least 1 valid Extension Function must be provided, or else the customization Window will throw Console NPEs whenever the user clicks OK or APPLY. The main issue this introduces is brining Ignition 7 components into Ignition 8. Now with that being said- Refactoring is far from impossible; developers can simply provide 1 Extension Function for all ExtensibleComponents, or remove the unused ExtensibleComponent inheritances. Unfortunately, this is easier said than done, and I wanted to ask about the possibility of continuing support for “Extension-Functionless ExtensibleComponents” for Vision in Ignition 8. For example, if a developer creates a Vision component in Ignition 7, extends IA’s PMITable, and provides no extension functions, this is fine. Users can open up the scripting customization window on the component, without the NPE being thrown. If this same code is brought to Ignition 8, it is a problem, because the PMITable innately inherits ExtensibleComponent, and the lack of Extension Functions will cause the NPE to be thrown in the Scripting window. Since PMITables are in the SDK, we cannot directly control its inheritance hierarchy. Refactoring our Vision component so that it stops extending the PMITable (turning the PMITable into a reference field) is certainly possible- it just appears to generate a lot of refactoring work. We anticipate the refactoring work to be a non-trivial use of time and resources, so I thought I’d at least try my luck at seeing if we could potentially acquire some support on IA’s side, before committing our resources for this job. [NPE.txt](https://forum.inductiveautomation.com/uploads/short-url/qkt9M0ObmisygBZ1U6P93bTuL1E.txt) (3.1 KB) ---
**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:** [November 10, 2020, 6:40pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/2 "2020-11-10T18:40:11Z")
Sounds like you are not copying your superclass' BeanInfo's list of extension functions. See this example: > [@Adding Data & selectedRow Properties to Custom Module](http://forum.inductiveautomation.com/t/adding-data-selectedrow-properties-to-custom-module/38223/4): > > I guess I can share how NoteChart does this with the Classic Chart–you’ll have to adapt for the Power Table: public class NoteChartBeanInfo extends CommonBeanInfo { public NoteChartBeanInfo() { super(NoteChart.class, new CustomizerDescriptor[] { ChartCustomizer.VALUE\_DESCRIPTOR }); getBeanDescriptor().setValue("dbl-click-customizer", ChartCustomizer.VALUE\_DESCRIPTOR.getValueName()); } @Override protected void initProperties() throws IntrospectionException { // Adds common proper… ---
**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:** [November 10, 2020, 6:46pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/3 "2020-11-10T18:46:36Z")
And if you really don’t want the table’s extension functions to show through, I suspect that setting that property to an empty list will fix your NPE. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [November 10, 2020, 6:57pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/4 "2020-11-10T18:57:49Z")
That you’re getting an NPE appears to be a bug we introduced during a big refactoring effort to support JDK 11 back in Feb 2019… we’ll get it fixed in an upcoming 8.1.x release. ---
**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:** [November 10, 2020, 7:25pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/5 "2020-11-10T19:25:57Z")
What if you just return an empty map from `getExtensionFunctions()`? ---
**Author:** ![kevin.cheong](https://avatars.discourse-cdn.com/v4/letter/k/b9e5f3/32.png) [@kevin.cheong](https://forum.inductiveautomation.com/u/kevin.cheong)\ **Post date:** [November 10, 2020, 9:08pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/6 "2020-11-10T21:08:11Z")
Hello everyone, thank you for taking the time to look at this; It’s good news for my side to hear that it is an (alleged) bug that has been spotted for a fix. To answer PGriffith and pturmel’s suggestion: Unfortunately, returning empty or null Extension Function collections still seems to cause the NPE to propagate. With all that being said, I do personally like the idea of Exposing/Inheriting the parent Extension Functions. However, as pturmel alluded to, this will expose functions we may have intentionally wanted to suppress. ---
**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:** [November 10, 2020, 9:38pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/7 "2020-11-10T21:38:52Z")
> [@kevin.cheong](#): > > However, as pturmel alluded to, this will expose functions we may have intentionally wanted to suppress. If you look carefully at my linked example, you'll see that I _ **am** _ suppressing a superclass extension function. ---
**Author:** ![kevin.cheong](https://avatars.discourse-cdn.com/v4/letter/k/b9e5f3/32.png) [@kevin.cheong](https://forum.inductiveautomation.com/u/kevin.cheong)\ **Post date:** [November 10, 2020, 10:18pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/8 "2020-11-10T22:18:50Z")
I do like (in the snippet example) that I can pick-and-choose functions to inherit; I see that “getXTraceLabel” was filtered out, and allows the other Extension Function(s) from PMIChart to come through- But in the case where I want my hypothetical PMIChart-extending component to feature 0 Functions, I may be out of luck because an empty list of Extension Functions does not avoid the NPE (as far as what I can tellf from tests- please correct me if I am mistaken about this). I can think up a couple of different ways to refactor components to work for Ignition 8, but before I commit (what I think will be a significant amount of) time into doing so, I wanted to double-check to see if this would be declared a bug, or if this was purposeful enforcement of ExtensibleComponent’s intended use. ---
**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:** [November 10, 2020, 10:22pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/9 "2020-11-10T22:22:23Z")
> [@kevin.cheong](#): > > because an empty list of Extension Functions does not avoid the NPE Have you tried it? In your BeanInfo? The designer runs off the BeanInfo, not the getExtensionFunctions() method of the actual component. These two lines in initDesc(): ```auto List extensionFunctionList = new ArrayList(); bean.setValue("vision-extension-functions", extensionFunctionList); ``` ---
**Author:** ![kevin.cheong](https://avatars.discourse-cdn.com/v4/letter/k/b9e5f3/32.png) [@kevin.cheong](https://forum.inductiveautomation.com/u/kevin.cheong)\ **Post date:** [November 10, 2020, 10:26pm UTC](https://forum.inductiveautomation.com/t/ignition-8-extensiblecomponents-without-extension-functions/40499/10 "2020-11-10T22:26:10Z")
Yes, I have tried returning the Extension Functions in the component class, the BeanInfo class, and both at the same time. I have also tried these combinations with both null and empty collections, but have not had success in avoiding the NPE.