Description of problem: Currently, plug-in configuration default values are hard-coded in the plug-in's manifest rhq-plugin.xml or set to hard-coded values within the discovery code inside the plug-in. This applies to just about all plug-ins/resource types. For example, the JBossCache plug-in contains a hard coded objectName default = "*:cache-interceptor=CacheMgmtInterceptor,*|*:treecache-interceptor=CacheMgmtInterceptor,*" which may make sense in a default installation but not if the user's JBoss Cache instances are using a derived CacheMgmtInterceptor with a different name such as MyCustomerCacheMgmtInterceptorImpl. The JBoss AS 5 plug-in attempts to read the JMX principal/credential from the AS configuration but if it fails, it sets these values to null. In many cases, especially a development environment, the user has a well defined development admin user and password that should be used instead of null/null. The result would be the reduction in the manual effort necessary to set this for each resource that is added to inventory which follows the business' default user/password scheme for the development instance. The JMX plug-in contains a property for the Logging service named manageConfigurationEnabled which is set to false by default. In some instances, a user may want this enabled for all resources which utilize the Logging service. The problem with these being hard-coded in the plug-in descriptor is that the only option to override the defaults is to create custom plug-ins that override these values or hack the distributed plug-ins. This does not work for environments in which the user is receiving support from a downstream provider for a shipped binary distribution. The purpose of this RFE is to highlight the need to make it possible for the user to override these values from an integration perspective. Either via some UI element such as templates or via a property file that can be provided to an agent to override the values. Or even a page in the JON UI that allows configuration of agent plug-ins as they exist in the server, allowing these default values to be specified and updates to them being pushed to the agents so that newly discovered resources utilize the new defaults. Obviously this can be made even more complex by adding the ability to push changes out to existing resources for values that have were not explicitly set in the first place. But again, this RFE is to start that discussion and perhaps track the work necessary to make user-defined defaults a possibility as opposed to the current hard-coded values. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: