You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Jens Grivolla <j+...@grivolla.net> on 2013/11/27 10:47:42 UTC

uimaFIT: managing component configurations

Hi,

so far we were using PEARs to manage different configurations of 
components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc., 
all based on ConceptMapper but with different settings/models.

How would I do that in uimaFIT? Basically I would like to create 
components that just override the default values for parameters/resources.

In some cases, parameters are additionally overridden at the pipeline 
level (CPE/uimaFIT), e.g. when using a database CasConsumer where we 
would have several base configurations (e.g. annotation to DB column 
mappings), but then override the DB connection settings in the pipeline.

Having the full configuration at the pipeline level makes it much more 
difficult to manage configurations, so I would like to be able to point 
to a given component and automatically get the correct default settings.

Thanks,
Jens


Re: uimaFIT: managing component configurations

Posted by Eddie Epstein <ea...@gmail.com>.
Just in case you haven't considered it, version 2.4.2 has a new option for
overriding configuration parameters outside of component descriptions,
called external overrides. It is implemented via an additional settings
file. Component descriptors remain static, like code, which would work well
for PEAR packaged components.

More details at
http://uima.apache.org/d/uimaj-2.4.2/references.html#ugr.ref.xml.component_descriptor.aes.external_configuration_parameter_overrides

Eddie


On Wed, Nov 27, 2013 at 4:47 AM, Jens Grivolla <j+...@grivolla.net> wrote:

> Hi,
>
> so far we were using PEARs to manage different configurations of
> components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc.,
> all based on ConceptMapper but with different settings/models.
>
> How would I do that in uimaFIT? Basically I would like to create
> components that just override the default values for parameters/resources.
>
> In some cases, parameters are additionally overridden at the pipeline
> level (CPE/uimaFIT), e.g. when using a database CasConsumer where we would
> have several base configurations (e.g. annotation to DB column mappings),
> but then override the DB connection settings in the pipeline.
>
> Having the full configuration at the pipeline level makes it much more
> difficult to manage configurations, so I would like to be able to point to
> a given component and automatically get the correct default settings.
>
> Thanks,
> Jens
>
>

Re: uimaFIT: managing component configurations

Posted by Richard Eckart de Castilho <re...@apache.org>.
On 28.11.2013, at 07:45, Jens Grivolla <j+...@grivolla.net> wrote:

> Hi, basically I'm looking for a way to manage engine descriptions. So far I'm using createEngineDescription(...) when building a pipeline.  If my component, i.e. in the case of uimaFIT the class that implements the AE, defines good default values that is very easy and concise.
> 
> However, I also have many cases where I have different descriptors/descriptions that use the same class, and sometimes I then again override some parameters.  I would like to manage those descriptions separately from the pipeline where they are used, e.g. with Maven.  I want to avoid copy and pasting common parameter configurations from one pipeline to the other.
> 
> So far I was using different XML descriptors, each packaged in a separate PEAR as an independent component, and would build my pipeline based on those.  With uimaFIT I haven't found a good way to do this.
> 
> Basically I would like to have inheritance at the description level. This could either be through Java inheritance (i.e. CountryMapper.class extends ConceptMapper.class and overrides default parameter values) or through a way to store EngineDescriptions and reuse them, without having to resort to XML files.

Well, AnalysisEngineDescriptions are "just" in-memory representations of the XML files (or vice versa if you prefer). You can save a descriptor that you created with uimaFIT as XML. Later, you can load the descriptor again with uimaFIT and override additional parameters. (see below)

> So I would in some place define "countryMapper = createEngineDescription(ConceptMapper.class, <parameters>)" and package that as a Maven artifact, and somewhere else use it to build a pipeline using createEngineDescription(countryMapper, <additional_parameters>).

So three steps: 1) create base descriptor 2) package base descriptor 3) create derived descriptor

1) create base descriptor

desc = createEngineDescriptor(ConceptMapper.class, <parameters>);
desc.toXml(…)

2) package base descriptor

Package resulting descriptor in a JAR X, e.g. as /my/package/CustomConceptMapper.xml

There is no convenient support of doing this automatically as part of a build right now. It should be possible with Maven though to first build some factory class which creates this descriptor and then later in the build call this class to have it created as part of the build. We did similar things in uimaFIT for auto-generating types in 1.4.x. It could look somewhat like this:

in 1) do desc.toXml(new FileOutputStream("target/classes/my/package/CustomConceptMapper.xml")

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <executions>
    <execution>
      <phase>process-classes</phase>
      <goals>
        <goal>java</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <mainClass>my.package.DescriptorGenerator</mainClass>
  </configuration>
</plugin>


3) create derived descriptor

Add JAR X as a dependency to your project.
desc = createEngineDescriptor("my.package.CustomConceptMapper", <parameterOverrides>)

> My problem is that I don't think I can override the default values with Java inheritance, and don't have a good way to package EngineDescriptions.  I guess I could have a class with a static method that returns the engine description and package that, but it would be nice to have something more "standard" and elegant.

There is an issue for overriding parameter values, but it has not been moved to the Apache Jira yet:
https://code.google.com/p/uimafit/issues/detail?id=69

I've been thinking about adding a new class-level annotation @OverrideParameter to do something like this:

@OverrideParameter(
  @ConfigurationParameter(name= ConceptMapper.PARAM_XXX, defaultValue="YYY"))
class CustomConceptMapper extends ConceptMapper { … }

I'd probably only use that carefully to manage descriptors as you plan to. When I was looking for such a functionality, I rather had a case with an abstract base class which I wanted to define a parameter without any default value, and then I wanted to override the parameter in a sub-class.

@OverrideParameter(
  @ConfigurationParameter(name= AbstractReaderBase.PARAM_FILES, defaultValue="*.txt")
class TextReader extends AbstractReaderBase { … }

The reason I think these are two different cases is, that my case is pretty much restricted to declaring parameters as part of a generic interface (realized in the abstract class), and then add default values for them in sub-classes. You appear to aim at a more general and flexible mechanism for composing descriptors, which may or may not be related to Java inheritance.

-- Richard

> Thanks,
> Jens
> 
> On 11/28/2013 12:37 AM, Richard Eckart de Castilho wrote:
>> Hi,
>> 
>> I'm not sure that I understand what you want to do. When you create a descriptor for a component e.g. using createEngineDescription(…), this descriptor is configured with the default values (unless you override them in the call to createEngineDescription).
>> 
>> You can change parameters on such a descriptor using ResourceCreationSpecifierFactory.setConfigurationParameters(…)
>> 
>> Does that help? Can you make a more vivid example of what you are trying to accomplish, maybe with a  bit if pseudo-code marking those places that remain unclear how to handle them?
>> 
>> Cheers,
>> 
>> -- Richard
>> 
>> On 27.11.2013, at 07:47, Jens Grivolla <j+...@grivolla.net> wrote:
>> 
>>> Hi,
>>> 
>>> so far we were using PEARs to manage different configurations of components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc., all based on ConceptMapper but with different settings/models.
>>> 
>>> How would I do that in uimaFIT? Basically I would like to create components that just override the default values for parameters/resources.
>>> 
>>> In some cases, parameters are additionally overridden at the pipeline level (CPE/uimaFIT), e.g. when using a database CasConsumer where we would have several base configurations (e.g. annotation to DB column mappings), but then override the DB connection settings in the pipeline.
>>> 
>>> Having the full configuration at the pipeline level makes it much more difficult to manage configurations, so I would like to be able to point to a given component and automatically get the correct default settings.
>>> 
>>> Thanks,
>>> Jens

Re: uimaFIT: managing component configurations

Posted by Jens Grivolla <j+...@grivolla.net>.
Hi, basically I'm looking for a way to manage engine descriptions. So 
far I'm using createEngineDescription(...) when building a pipeline.  If 
my component, i.e. in the case of uimaFIT the class that implements the 
AE, defines good default values that is very easy and concise.

However, I also have many cases where I have different 
descriptors/descriptions that use the same class, and sometimes I then 
again override some parameters.  I would like to manage those 
descriptions separately from the pipeline where they are used, e.g. with 
Maven.  I want to avoid copy and pasting common parameter configurations 
from one pipeline to the other.

So far I was using different XML descriptors, each packaged in a 
separate PEAR as an independent component, and would build my pipeline 
based on those.  With uimaFIT I haven't found a good way to do this.

Basically I would like to have inheritance at the description level. 
This could either be through Java inheritance (i.e. CountryMapper.class 
extends ConceptMapper.class and overrides default parameter values) or 
through a way to store EngineDescriptions and reuse them, without having 
to resort to XML files.

So I would in some place define "countryMapper = 
createEngineDescription(ConceptMapper.class, <parameters>)" and package 
that as a Maven artifact, and somewhere else use it to build a pipeline 
using createEngineDescription(countryMapper, <additional_parameters>).

My problem is that I don't think I can override the default values with 
Java inheritance, and don't have a good way to package 
EngineDescriptions.  I guess I could have a class with a static method 
that returns the engine description and package that, but it would be 
nice to have something more "standard" and elegant.

Thanks,
Jens

On 11/28/2013 12:37 AM, Richard Eckart de Castilho wrote:
> Hi,
>
> I'm not sure that I understand what you want to do. When you create a descriptor for a component e.g. using createEngineDescription(…), this descriptor is configured with the default values (unless you override them in the call to createEngineDescription).
>
> You can change parameters on such a descriptor using ResourceCreationSpecifierFactory.setConfigurationParameters(…)
>
> Does that help? Can you make a more vivid example of what you are trying to accomplish, maybe with a  bit if pseudo-code marking those places that remain unclear how to handle them?
>
> Cheers,
>
> -- Richard
>
> On 27.11.2013, at 07:47, Jens Grivolla <j+...@grivolla.net> wrote:
>
>> Hi,
>>
>> so far we were using PEARs to manage different configurations of components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc., all based on ConceptMapper but with different settings/models.
>>
>> How would I do that in uimaFIT? Basically I would like to create components that just override the default values for parameters/resources.
>>
>> In some cases, parameters are additionally overridden at the pipeline level (CPE/uimaFIT), e.g. when using a database CasConsumer where we would have several base configurations (e.g. annotation to DB column mappings), but then override the DB connection settings in the pipeline.
>>
>> Having the full configuration at the pipeline level makes it much more difficult to manage configurations, so I would like to be able to point to a given component and automatically get the correct default settings.
>>
>> Thanks,
>> Jens
>



Re: uimaFIT: managing component configurations

Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi,

I'm not sure that I understand what you want to do. When you create a descriptor for a component e.g. using createEngineDescription(…), this descriptor is configured with the default values (unless you override them in the call to createEngineDescription).

You can change parameters on such a descriptor using ResourceCreationSpecifierFactory.setConfigurationParameters(…)

Does that help? Can you make a more vivid example of what you are trying to accomplish, maybe with a  bit if pseudo-code marking those places that remain unclear how to handle them?

Cheers,

-- Richard

On 27.11.2013, at 07:47, Jens Grivolla <j+...@grivolla.net> wrote:

> Hi,
> 
> so far we were using PEARs to manage different configurations of components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc., all based on ConceptMapper but with different settings/models.
> 
> How would I do that in uimaFIT? Basically I would like to create components that just override the default values for parameters/resources.
> 
> In some cases, parameters are additionally overridden at the pipeline level (CPE/uimaFIT), e.g. when using a database CasConsumer where we would have several base configurations (e.g. annotation to DB column mappings), but then override the DB connection settings in the pipeline.
> 
> Having the full configuration at the pipeline level makes it much more difficult to manage configurations, so I would like to be able to point to a given component and automatically get the correct default settings.
> 
> Thanks,
> Jens