Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority

Hi, On Thu, Mar 12, 2015 at 12:03 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: ...and because they clearly express it, in their documentations, that they accept some annotations and they define how those annotations will be interpreted. Basically, the purpose of the javax.annotations package. I don`t find this better since it does not tell me what the macro does with that priority. @MacroExcutionPriority would have been clear, if that is what we pursue. public class ContentMacro implement Macro Honestly, I am not a big fan of annotations, specially in Java, and I try to keep them to a minimal as much as possible. It feels like a shortcut that leads to a dead end. They are not code, but configuration and, as such, modifying configuration should not require recompiling the code. Back to our particular discussion, AFAIK, we are not doing multiple roles per implementation. That, indeed, would probably not work with the javax Priority annotation due to lack of specificity. I do see the advantages of typed annotations, but also the need to be aware of more and more annotations, as they come, when our usecase is pretty simple and would be well satisfied by the javax Priority one. That is the main reason why I looked for a more generic solution instead of just making a new annotation for the document initializer use case. I find it uselessly polluting. I`d love to hear more opinions on this :)

Thanks, Eduard > >> Priorities on other behaviors that are added to a component (for example >> through interfaces like Initializable or Disposable, interfaces which are >> not components themselves) should provide their own specialized >> (behavior-driven) priority annotations (e.g. @DisposePriority, >> @InitializationPriority, etc.). >> >> Note: If we want to explore the possibility of using our own generic >> Priority annotation, we need to consider the fact that multiple > annotations >> on the same java class is only supported [1] starting with java 1.8. > Until >> then, the commonly used workaround [3] seems cumbersome to use. > > Yep, I’d really not like to use a generic annotation with the namespace > being specified. I much much prefer typed annotations. > > Thanks > -Vincent > >> Thanks, >> Eduard >> >> ---------- >> [1] http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html >> [2] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7151010 >> [3] >> > http://stackoverflow.com/questions/1554112/multiple-annotations-of-the-same… >> >> On Thu, Mar 12, 2015 at 10:41 AM, vincent(a)massol.net >> wrote: >> >>> Hi devs, >>> >>> As part of http://jira.xwiki.org/browse/XWIKI-11905, Edy has started >>> using the Java @Priority annotation. >>> >>> This seems very good and I personally didn’t know about this annotation >>> before (maybe it’s been introduced not that long ago?). So for me it > raises >>> the question of: do we want to use this annotation more and how does it >>> compare with what we’ve done so far. >>> >>> I can think of a few places that could have used it: >>> >>> * Macros.get/setPriority(). It should be possible to add support for >>> @Priority and modify MacroTransformation to use that annotation. >>> * Transformations. We have a jira issue opened for adding support for >>> Priority in Transformation’s executions (in TransformationManager). >>> * @DisposePriority (used by ECM). >>> * TranslationBundle.get/setPriority() >>> * … and probably some other places… >>> >>> However, I think there’s a namespacing problem. For example imagine > that >>> we code a Macro and set @Priority on that Macro component. The ECM > could >>> interpret it as a dispose priority while the MacroTransformation could >>> interpret it as an execution priority… >>> >>> Globally I think that use an annotation for expressing priority is > great >>> and much better than what we’ve done in the past with get/setPriority() >>> methods. It’s better because priority is not a business concept and > we’re >>> polluting the business interface with it. >>> >>> Now, in order to fix the namespacing issue, I think that the best > solution >>> is that each module requiring some priority should introduce its own >>> annotation and should NOT depend on the @Priority one from the JDK > (i.e. we >>> ban the usage of it). >>> >>> WDYT? >>> >>> Thanks >>> -Vincent >>> >>> >>> W