Re: Accessing plugin-configuration changed through the GUI

[Mike Domondon]

I'm trying to do a manual add of a resource. Sorry for the confusion.

I tried out what you explained regarding ManualAddFacet and I was able to get my plugin to work properly.

Thanks for your detailed explanation, even if my initial description of the problem was not clear.

Regards,
Mike

On Mar 20, 2013, at 3:21 PM, Lukas Krejci  wrote:
> I think you are slightly misunderstanding the flow of the resources through 
> the system:
> The discovery component is invoked to discover the resources present on the
>
> system. Note that the discovery component *can* discover resources that are 
> already present in the inventory - in fact this is expected and the already 
> present resources and the discovered resources are matched using their 
> resource keys. The discovery can happen in 2 flavors:
> a) discoverResources(ResourceDiscoveryContext) method - this method is called 
> during the "autodiscovery" of resources and bases its results on the process 
> scan (ResourceDiscoveryContext.getAutoDiscoveredProcesses()). The only way to 
> access a plugin configuration here is to call 
> ResourceDiscoveryContext.getDefaultPluginConfiguration() - this will provide 
> the plugin configuration as defined in the plugin descriptor including the 
> default values, etc. I.e. in your discovery component you are discovering a 
> new resource and hence you have no prior "state" to work with.
> b) for resources that can be manually added, your discovery component needs to 
> implement the "ManualAddFacet" and implement the 
> discoverResource(Configuration, ResourceDiscoveryContext) method - the first 
> argument of that method is the plugin configuration as filled in by the user 
> when manually adding the new resource. You are using the 
> ResourceDiscoveryContext.getPluginConfigurations() which is a deprecated and 
> unsupported way of doing manual add and I strongly suggest you re-work your 
> plugin to use the ManualAddFacet (if indeed you are trying to support manual 
> add which is not clear to me).
> Once discovered, the resources that do not match (by resource key) any
>
> resource in the inventory are reported to the server and end up in the 
> discovery queue there.
>
> Given the above, your problem doesn't make much sense to me. The discovery 
> component by definition doesn't have access to the existing resources, because 
> its purpose is to discover them anew. When the discovery component discovers a 
> resource with the same resource key as an already existing resource, the fact 
> is merely acknowledged. If the discovery discovers resources that are not 
> already present in the inventory, the fact is reported to the server and you 
> get those resources in the discovery queue. If the discovery *doesn't* 
> discover a resource that is already present in the inventory, you have a 
> strong indication that the resource no longer exists, but we actually don't 
> rely on that fact but rather consult the resource component itself and check 
> for its availability.
>
> What are you trying to achieve? Could you explain your components and the way 
> you want them to interact in a bit more detail?
>
> Regards,
>
> Lukas
>
> On Wednesday, March 20, 2013 13:16:24 Mike Domondon wrote:
> > Hi,
> >
> > I have a server with a plugin-configuration defined in the plugin
> > descriptor.
> >
> > <plugin-configuration>
> >            <c:simple-property name="key" type = "string" required =
> > "true"/>
> > </plugin-configuration>
> >
> > In the server's discovery component, I want to access the plug-in
> > configuration that was changed through the UI and not the default
> > plugin-configuration in the plugin descriptor.
> >
> > This is what I tried in the discoverResources method:
> >
> > List<Configuration> configs = context.getPluginConfigurations();
> >        for (Configuration config : configs ) {
> >            Uniquekey = config .getSimpleValue("key", null);
> >            if (Uniquekey == null)
> >                throw new InvalidPluginConfigurationException("No Key
> >
> > provided");
> >            }
> >
> > What I get is that UniqueKey is not null. But it is blank.
> > getPluginConfigurations is deprecated, could it be the reason why my code
> > does not work? .
>
> getPluginConfigurations() should still work to support the old way of doing 
> manual add, but it seems you are trying to use it for different purpose.
> > Thanks,
> > Mike
>
> rhq-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/rhq-users