No error/warning when parameters do not apply to component

[GoogleCodeExporter]

Richard:
Currently there is no check if parameters actually match the instantiated
component:

createPrimitive(A.class, tsd, B.PARAM_A, "lala")

Now it would be helpful for users to get some indication that B.PARAM does
not actually apply to A. 
It may be prudent to add issue a warning if a parameter is specified for a
component, which the 
component does not make use of.

Philip:
This is a bit problematic for us.  We are fond of dynamically loading
classes that
implement various interfaces at runtime that configure themselves using a
UimaContext.  In this scenario it is impossible whether the component makes
use of a
particular configuration parameter or not.  

that said, what did you have in mind?

Richard:
A user brought it to my attention today that he spend some time not seeing
that he was configuring A with 
parameters from B and wondering why it didn't work and asked if it would be
possible to help avoiding that. 
My first reaction was to say, that there is no way to properly detect or
handle this. My second thought was 
that it may at least be possible to warn. I also have been thinking of the
dynamic scenario you describe, but 
so far have not implemented it in any of our components.

I think that when a component allows dynamically configured plugins, this
is probably a design-time decision 
for that component. Turning that observation around, it's probably also a
decision that a component does not 
support such plugins. It may be possible to annotate either components
supporting dynamic plugins (e.g. 
@Strict) or components not supporting dynamic plugins (e.g. @Dynamic) and
have InitializeUtil barf if a strict 
component has extraneous parameters in its context. The annotations may be
called differently or be 
conflated with @AnalysisComponent.

I think this issue may be related in spirit to  issue 19 : asking for a
stricter sanity checks.

Original issue reported on code.google.com by pvogren@gmail.com on 1 May 2010 at 3:01

[GoogleCodeExporter]

These issues are candidates for version 1.3.0.

Original comment by richard.eckart on 7 May 2011 at 5:31

• Added labels: Milestone-1.3.0

[GoogleCodeExporter]

Original comment by richard.eckart on 4 Jan 2012 at 10:51

• Added labels: Milestone-1.4.0

[GoogleCodeExporter]

I think I understand better now what this issue means for ClearTK. I am not 
sure though what I should think about your approach. It seems to me that UIMA's 
External Resources might be a better approach. Have you ever considered that?

Original comment by richard.eckart on 4 Jan 2012 at 10:57

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Milestone-1.4.0, Priority-Medium, Type-Defect

[GoogleCodeExporter]

I'm not sure how External Resources would solve this problem. Let me give you 
an example, and maybe you can elaborate.

A CleartkAnnotator has a parameter, dataWriterFactoryClassName, which specifies 
a class that allows you to configure whether you want SVMlight-style data, 
Mallet-style data, OpenNLP-style data, etc. CleartkAnnotator reads that 
parameter, and creates the class from it via uimaFIT's 
InitializableFactory.create, which calls initialize on the data writer factory 
object passing it the UimaContext. This call to initialize is crucial because, 
for example, the libSVM data writer takes a cutoff parameter (which trims 
low-frequency features) that it reads from the UimaContext. So there's no way 
to tell from CleartkAnnotator.class that the data writer factory is going to 
take some additional parameters.

How would you solve this problem using External Resources?

Original comment by steven.b...@gmail.com on 6 Jan 2012 at 1:27

[GoogleCodeExporter]

Currently I would write something like this in ClearTK:

createPrimitiveDescription(
    ExamplePosAnnotator.class,
    ExamplePosAnnotator.PARAM_DATA_WRITER_FACTORY_CLASS_NAME, ViterbiDataWriterFactory.class.getName(),
    ViterbiDataWriterFactory.PARAM_OUTPUT_DIRECTORY, modelDir.getAbsolutePath(),
    ViterbiDataWriterFactory.PARAM_DELEGATED_DATA_WRITER_FACTORY_CLASS, DefaultMaxentDataWriterFactory.class.getName());

When using external resources, you would write it like this:

createPrimitiveDescription(
    ExamplePosAnnotator.class,
    ExamplePosAnnotator.PARAM_DATA_WRITER_FACTORY, createExternalResourceDescription(
        ViterbiDataWriterFactory.class,
        ViterbiDataWriterFactory.PARAM_OUTPUT_DIRECTORY, modelDir.getAbsolutePath(),
        ViterbiDataWriterFactory.PARAM_DELEGATED_DATA_WRITER_FACTORY, createExternalResourceDescription(
            DefaultMaxentDataWriterFactory.class.getName())));

Mind though that the latter form uses nested external resources that are 
currently not supported in this form by uimaFIT at this moment, but will be 
once issue 109 is complete. I have a working prototype already.

With the current version of uimaFIT in trunk (revision 721) only the following 
form without the nested createExternalResourceDescription() would be possible:

createPrimitiveDescription(
    ExamplePosAnnotator.class,
    ExamplePosAnnotator.PARAM_DATA_WRITER_FACTORY, createExternalResourceDescription(
        ViterbiDataWriterFactory.class,
        ViterbiDataWriterFactory.PARAM_OUTPUT_DIRECTORY, modelDir.getAbsolutePath(),
        ViterbiDataWriterFactory.PARAM_DELEGATED_DATA_WRITER_FACTORY_CLASS, DefaultMaxentDataWriterFactory.class.getName()));

Original comment by richard.eckart on 7 Jan 2012 at 9:34

[GoogleCodeExporter]

And with the external resource descriptions, you could tell if the user forgot 
to specify ViterbiDataWriterFactory.PARAM_DELEGATED_DATA_WRITER_FACTORY_CLASS?

Assuming so, is there any way we (ClearTK) can easily support both syntaxes for 
backwards compatibility? We'd then deprecate the old syntax and anyone still 
using it would also get the warning you've proposed here, and encourage 
everyone to use the new syntax.

Original comment by steven.b...@gmail.com on 12 Jan 2012 at 2:20

[GoogleCodeExporter]

Checking if the user forgot to specify a parameter is a different check than 
the one suggested in this issue. Checking for presence of settings is normally 
done by UIMA itself when the component is instantiated. uimaFIT would only need 
to do that if UIMA itself would not already throw an error at instantiation 
time.  It is a check that cannot be done when creating a descriptor, because 
the the parameters or resource bindings of the descriptor might still be 
changed after it has been created.

Regarding to support both syntaxes: in principle yes, but that would disable 
the checking if the user has forgotten to specify a resource, because all the 
resources would need to be declared as optional - they might not be present if 
a user chooses to use the current syntax instead of the external resources.

Original comment by richard.eckart on 12 Jan 2012 at 8:49

[GoogleCodeExporter]

So basically if we went the backwards compatibility route, we'd get warnings 
from uimaFIT if the user specified a parameter that didn't apply to the 
annotator or any of its external resources, but we'd lose the UIMA errors for a 
missing required parameter (so we'd have to manually inspect the two variables 
and throw an appropriate exception in initialize). Is that right? 

Original comment by steven.b...@gmail.com on 12 Jan 2012 at 2:51

[GoogleCodeExporter]

Original comment by richard.eckart on 7 Jan 2013 at 4:51

• Added labels: ASFJira-No