Preprocessing demo throws NPE

[Horsmann]

The demo org.dkpro.tc.examples.single.document.WekaTwentyNewsgroupsPreprocessing is supposed to show how to use a varying preprocessing. Demo fails with a NPE at the moment.

The receiving lab-variable is null. I am not sure when this broke.

[Horsmann]

@reckart I think I have Lab issue in this demo here. It tries to show how to use various preprocessing settings and does this:

A dimension to iterate the preprocessing components is provided Dimension<String> dimSegmenter = Dimension.create("segmenter", "break", "opennlp");

but when the if-statement is reached the receiving variable is (still?) null. How would that have too look like to work? I am not sure when this demo broke probably quite some time ago. Any ideas?

ExperimentCrossValidation batch = new ExperimentCrossValidation(
                "TwentyNewsgroupsCV-preprocessing", WekaClassificationAdapter.class, NUM_FOLDS)
        {
            @Discriminator
            String segmenter;

            @Override
            public AnalysisEngineDescription getPreprocessing()
            {

                try {
                    if (segmenter.equals("break")) {
                        return createEngineDescription(BreakIteratorSegmenter.class);
                    }
                    else if (segmenter.equals("opennlp")) {
                        return createEngineDescription(OpenNlpSegmenter.class);
                    }
                    else {
                        throw new RuntimeException("unexpected discriminator value: " + segmenter);
                    }
                }
                catch (ResourceInitializationException e) {
                    throw new RuntimeException(e);
                }

            }
        };

[reckart]

Could it be that there is no dimension called "segmenter" anymore?

[reckart]

Ah, no you say it is there.

[Horsmann]

It is this example: https://github.com/dkpro/dkpro-tc/blob/master/dkpro-tc-examples/src/main/java/org/dkpro/tc/examples/single/document/WekaTwentyNewsgroupsPreprocessing.java

[Horsmann]

@reckart do you have a suggestion how to find out what could be wrong with this demo case? Any pointer where I could start to look?

[reckart]

Check where LifeCycleManager.configure(TaskContext, Task, Map<String, Object>) is called and why it is not called before your batch.

[Horsmann]

@reckart I just had a look and the getPreprocessing() is called already during initialize() of the DefaultLifeCycleManager long before the configure method is called. I don't see why this has ever worked. Has there been many changes regarding the execution order?

[reckart]

There was a change to the lifecycle in 0.12.0: https://github.com/dkpro/dkpro-lab/issues/85

[Horsmann]

Hm, ok. Sorry for my keep asking, but how open is Lab to configurations from outside i.e. before a task runs? I basically need to have configure called by the time the CrossValidationTask runs, right? Is there a way to do that.

By the way I don't think this is a particular sever problem. I would be fine with simply deleting the test case and giving up on this feature which seemingly has been broken since 0.7.0 with nobody noticing it. (@daxenberger any objections :o?)

[reckart]

What do you mean "open to configurations from the outside"? What do you need to configure?

[Horsmann]

For this to work:

ExperimentCrossValidation batch = new ExperimentCrossValidation(
                "TwentyNewsgroupsCV-preprocessing", WekaClassificationAdapter.class, NUM_FOLDS)
        {
            @Discriminator
            String segmenter;

I need to have configure called before the preprocessing is executed. How things are at the moment this is not happening anymore which seems to be the problem. I somehow needs to have configure called. This is what I meant with configuring from the outside e.g. hack-in this information to make it available when needed during the initialization.

[reckart]

The order in which the lifecycle events are triggered is defined in the BatchTaskEngine. If you change that, other things may stop working.

The order is:

• ctx.getLifeCycleManager().initialize(ctx, aConfiguration)
• ctx.getLifeCycleManager().begin(ctx, aConfiguration)
• ctx.getLifeCycleManager().configure(aContext, task, aConfig)
• either: ctx.getLifeCycleManager().fail(ctx, aConfiguration, e)
• or: ctx.getLifeCycleManager().complete(ctx, aConfiguration)

If I remember correctly these events are only called for subtasks of a batch task. These are the only ones that live in a parameter space. The root task cannot have discriminators and cannot have a parameter space affecting itself.

[Horsmann]

I think I will delete this test case then. This is something I don't want to touch at least not for a functionality like this one. Thx for the info.