-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom injectors in resource to model mapping #16
Comments
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. |
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 |
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:
The latter is my favorit solution, since it provides decent performance and a maximum of flexibility |
I will make a suggestion... |
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. |
Pull request: #27 |
Implemented, merged, done! |
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:
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
What do you think about this change?
The text was updated successfully, but these errors were encountered: