Bug 916438 - User should not have to enter values for Optional Parameters of a custom server plugin
Summary: User should not have to enter values for Optional Parameters of a custom serv...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin Container
Version: JON 3.1.2
Hardware: noarch
OS: Unspecified
unspecified
medium
Target Milestone: ER01
: JON 3.2.0
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-28 04:35 UTC by claudianus
Modified: 2014-01-02 20:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-02 20:43:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
plugin descriptor for my custom server plugin (9.06 KB, text/xml)
2013-02-28 04:35 UTC, claudianus
no flags Details

Description claudianus 2013-02-28 04:35:49 UTC
Created attachment 703777 [details]
plugin descriptor for my custom server plugin

Description of problem:
When entering parameters for a server plugin with optional parameters and no value is entered for optional parameters as expected, a Null Pointer Exception is thrown by the system. 
My insvestigation found that the issue is in the ServerPluginDescriptorMetadataParser when it tries to add callback data properties to the java.util.Properties object (see line 357). The reason for this is that the java.util.Properties object expects a key value pair in order to add a new element but in case of optional parameters, no value is provided and so the ServerPluginDescriptorMetadataParser tries to add a key with null value and that is what causes the NPE to be thrown. 

Version-Release number of selected component (if applicable):
I found this in 3.1.2

How reproducible:
It is easily reproducible 

Steps to Reproduce:
1.Create a new custom server plugin with some optional parameters. Alternatively you can modify an existing plugin by adding an optional parameter to it.
2.Build and Deploy the newly created or updated plugin. Make sure the plugin is not activated by default (i.e. in the plugin descriptor).
3.Navigate to the plugin page, open the plugin and enter data for the plugin parameters but don't enter any data for the optional parameters.
4. Save the plugin.
5. Activate the plugin.
  
Actual results:
You will get a NPE which does not clearly tell you what is wrong. You will need to either debug the code or evaluate the code of the ServerPluginDescriptorMetadataParser to see how this happened.

Expected results:
The plugin should be saved and start running without any issues but here even though there are no errors in the plugin you can't get it to run.

Additional info:
I have found a workaround for the time being, which basically consists in entering empty string (by way of space bar) for each optional parameter. Also note that I tried to set default values for the optional parameters but that didn't work.

The way I see this fixed is I would think that we need some utility that can first go through the value set and replace all null values by their default equivalents if there are any before passing the ScheduleJobsConfig (or nay plugin related configuration for that matter) to the ServerPluginManager [lines 442 - 444]. So this will be a ParserHelper to be used whenever configuration values are retrieved such as on lines [231 - 245] and then on line 256 of the ServerPluginDescriptorMetadataParser, thereby removing the need to hard code the default values as currently done on lines [231 - 245] referred to above. I don't know a lot about how this would affect the APIs so I am just throwing this out there. 
 I just thought that it is very inconvenient to force the user to enter value for parameters that are optional. For example for my plugin that is 15 optional parameters that I am having the user enter empty string for. Of course, I could try to merge some of them together by using a comma separated list but some of the flexibility and the semantic I am trying to provide would then be lost. Just some food for thoughts.

Finally I am adding my plugin descriptor if it will help. 
I anyone need the source code I can add here or point you to a GIT repo where is resides.

Comment 1 John Mazzitelli 2013-04-22 21:24:31 UTC
One thing needs to be clear - when the description says "create a new custom server plugin with some optional parameters" it means add optional simple properties *to a scheduled job* configuration (not to global config or in control definitions).

First, I did confirm this problem - so for sure I saw the NPE when I ran a quick test.

master commit 84137e8 fixes ServerPluginDescriptorMetadataParser in the two places where it was possible to attempt to add null to the properties object for the scheduled job config.

To test, I added two optional simple properties - one with no default defined and one with a default defined. The plugin was disabled by default. I deployed it and I can see the default value set in the one, and I can see no value with the "unset" checked for the property with no default set. I enabled the plugin, edited an unrelated property and saved the scheduled job config - the two config values remained as is (which is good).

No NPEs occurred.

For the record, to test, I just built the samples/custom-serverplugin where its descriptor got this added to its anotherJobMapHere scheduled job definition:

            <c:simple-property name="anothercustom3" type="string" required="false" summary="true" description="without default"/>
            <c:simple-property name="anothercustom3default" type="string" required="false" default="foo" summary="true" description="with default"/>

Comment 2 Larry O'Leary 2013-09-06 14:32:38 UTC
As this is MODIFIED or ON_QA, setting milestone to ER1.


Note You need to log in before you can comment on or make changes to this bug.