Support custom injectors in resource to model mapping

[huberchrigu]

In a NEBA-based project we have a resource model post processor that searches for fields annotated with @x and injects a value in those. So basically it does the same as NEBA does, but for an AEM-based property.
Performance measurements and profiling showed that this post processor produces a big overhead, even for resource models that do not have any @x at all! The java reflection is just quite slow, to go through all the fields of the current or a super class.
So I did the following test:

• Instead of iterating through all fields of getAllFields, which is the collection of all fields of the current and subclasses, I used https://github.com/ronmamo/reflections/, which offers indexing the classes once, and then uses this indices to iterate through all fields with the annotations.
• I measured the time for both approaches for the same request and summed up those times for some seconds (see log below)
• The "reflections" method takes some more startup time, because the indices are computed the first time when they are needed (this could be improved). Afterwards it clearly wins. because it does not need to parse all the class hierarchy and its fields every time anymore.

30.10.2014 08:47:49.963 DEBUG [0:0:0:0:0:0:0:1 [1414655269869] GET x.html HTTP/1.1] ...TagReferencePostProcessor Time after getAllFields(): 1ms, time after reflections: 45ms
30.10.2014 08:47:53.578 DEBUG [0:0:0:0:0:0:0:1 [1414655269869] GET x.html HTTP/1.1] ...TagReferencePostProcessor Time after getAllFields(): 606ms, time after reflections: 113ms

But using reflections in an OSGi context is quite cumbersome, because we'd have to care about bundle changes and the resource model implementations are actually not exported, so we cannot even use Sling's global class loader.
On the other hand, NEBA already creates such an "index" of resource models. In NEBA this is called ResourceModelMetadata. So what about extending NEBA, such that the metadata can be extended dynamically such that

• The metadata also stores the customized annotation
• Post processors (or maybe they are called differently then) receive a set of fields annotated with the custom annotation, which is also based on the cached metadata

What do you think about this change?

[DaniRey]

I think that's a nice idea. How would you control which annotations NEBA should record and provide information upon? I see two options - either it simply records all annotations available or it might be configured in the Spring context.
What do you think?

[huberchrigu]

The PostProcessor-like service should provide the annotations it is looking for I'd say. Also depends on the NEBA implementation, which I don't know in detail

[olaf-otto]

I do not think it is safe to make any assumptions what the desired behavior of a post processor is, and specifying what annotation(s) must apply to a model is likely to be insufficient in some situations. Remember that post processors may alter the entire model, e.g. return a proxy instread of the original model and so forth. Besides, it could be relatively cumbersome to specify the desired annotations - what if one is interested in a combination of annotations or wants to filter on specific annotation attributes?

However, I see two different solution approaches:

• No change. The applications must maintain a cache of the types they reflect on
• We provide the post processors with metadata by means of a public interface, and they can use that meta data instead of reflecting on the model.

The latter is my favorit solution, since it provides decent performance and a maximum of flexibility

[huberchrigu]

I will make a suggestion...

[olaf-otto]

I have re-named this issue. In this use case, Post-Processors are employed to achieve injecting custom values based on custom annotations. Thus, we are not talking about a post processor but about supporting custom injectors.

[olaf-otto]

Pull request: #27

[olaf-otto]

Implemented, merged, done!