Add SpelIndexResolver

[rwinch]

This request adds support for resolving indexes using SpEL expressions.

NOTE It should be noted that there is a FIXME in the code Details are in the comment. Please let me know if you see something I should do differently here, or if it is a large problem that needs fixed.

[christophstrobl]

@rwinch looking at SpelIndexResolver I was wondering if it would make sense to include the SpelExpression evaluation as a special kind of index instead of having an explicit resolver for it.

Something like:

class SpelIndex extends RedisIndex {

    private String expression;

    public SpelIndex(String keyspace, String indexName, String expression) {
        super(keyspace, indexName);
        this.expression = expression;
    }

    public String getExpression() {
        return expression;
    }
}

//...

config.addIndexDefinition(new SpelIndex("spring:session:sessions", "principalName", "getAttribute('SPRING_SECURITY_CONTEXT')?.authentication?.name"));

The above can be optionally enhanced with a path to evaluate on, if that one is not present it's only applied on root level.
How much influence do you actually need on the EvaluationContext?

[rwinch]

@christophstrobl Thanks for the feedback. I'm certainly open to implementation suggestions. My understanding of the current design was that the RedisIndex contains meta information to resolve the index, but no specific state. The IndexResolver allows some sort of state to be passed in (i.e. the object being persisted). Since the SpEL expression requires a reference to the object being persisted and there is no way to communicate that to the RedisInstance (or subclasses), I felt it was best to to do this in an IndexResolver.

In short, how would you communicate the persisted object to the index so it could be populated on the EvaluationContext?

[christophstrobl]

@rwinch the seperation still exists so there's the RedisIndex holding meta info and the IndexedData in between is the resolver that checks the settings and property values. Using sort of a IndexedDataCreator via a factory would produce the state holding IndexedData out of the metadata and the actual value. The thing is that the EvaluationContext could not be configured as easily as you did in the PR.

[rwinch]

Would I have reference to the object (i.e. HttpSession) itself? How would the object be passed into the index so the index could create the EvaluationContext with the object?

[christophstrobl]

having somthing like:

 class SpelIndexCreator implements IndexedDataCreator {

        private final SpelIndex index;
        private final SpelExpressionParser parser;

        public SpelIndexCreator(SpelIndex index, SpelExpressionParser parser) {
            this.index = index;
            this.parser = parser;
        }

        @Override
        public IndexedData createFor(Object value) {

            Expression expression = parser.parseExpression(index.getExpression());
            StandardEvaluationContext context = new StandardEvaluationContext();
            context.setRootObject(value);
            context.setVariable("this", value);
            // context.setBeanResolver(beanResolver);
            Object indexValue = expression.getValue(context);


            return new SimpleIndexedPropertyValue(index.getKeyspace(), index.getIndexName(), indexValue);
        }

    }

that is accessible via an IndexedDataCreatorFactory.

IndexData acutalIndexedValue = dataCreatorFactory.get(spelIndexDefinition).createFor(value);

[rwinch]

Thanks for the response. I'm not familiar with IndexedDataCreator...is this new? Would it be injected into the IndexResolverImpl? If IndexedDataCreator is new what is the advantage of this over a distinct IndexResolver?

NOTE I'm ok with whatever design you want so long as I can resolve SpEL expressions. I'm just not sure if I understand how you want me to modify the PR. I'm also curious to learn what advantages you see with your suggested approach.

[christophstrobl]

@rwinch no need to modify the PR. Advantage would be that you can have the normal indexing features along the SpEL based ones by just telling the IndexResolver that you want a specific expression to be evaluated.

[rwinch]

Advantage would be that you can have the normal indexing features along the SpEL based ones by just telling the IndexResolver that you want a specific expression to be evaluated.

Thanks. I'd imagine this could also be achieved by providing a CompositeIndexResolver which iterates over a collection of IndexResolver implementations. This might provide more flexibility in the end while still allowing the IndexResolver implementations the ability to be very focused on their responsibilities. Thoughts?

[christophstrobl]

@rwinch yeah thought about it - no reason why not have a CompositeIndexResolver. Still the current IndexResolverImpl is not quite the was I want it to be. But this is something to be changed in another ticket.