On Thu, Mar 12, 2015 at 3:08 PM, [email protected] <[email protected]> wrote:
> > > > > > On 12 Mar 2015 at 12:24:59, Eduard Moraru ([email protected](mailto: > [email protected])) wrote: > > > Hi, > > > > On Thu, Mar 12, 2015 at 12:03 PM, [email protected] > > wrote: > > > > > Hi Edy, > > > > > > On 12 Mar 2015 at 10:49:29, Eduard Moraru ([email protected] > (mailto: > > > [email protected])) wrote: > > > > > > > Hi, > > > > > > > > As it's documentation [1] mentions, the usage of the @Priority > annotation > > > > should be defined by the classes it is used on: > > > > > > > > "The effect of using the Priority annotation in any particular > instance > > > is > > > > defined by other specifications that define the use of a specific > class. > > > > For example, the Interceptors specification defines the use of > priorities > > > > on interceptors to control the order in which interceptors are > called." > > > > > > > > Therefore, I suggest we use the @Priority annotation on components > that > > > > need it and that like to specify the order in which they are *used* > (i.e. > > > > perform their main task). > > > > > > so what you’re suggesting is that: > > > > > > @Component > > > @Name(“content”) > > > @Priority(1000) > > > public class ContentMacro implement Macro > > > > > > has a different meaning than: > > > > > > @Component > > > @Named(“XWiki.WatchListJobClass") > > > @Priority(1000) > > > public class WatchListJobClassDocumentInitializer ... > > > > > > because one if a Macro and the other one is a Document Initializer > > > > > > right? > > > > > > > ...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. > > > > > > > (BTW note that this wouldn’t work if in the future we start supporting > > > several roles per component impl.) > > > > > > So it means that people reading the code need to understand that even > > > though it’s the same annotation, it’ll have a different meaning. > > > > > > Compare this to: > > > > > > @Component > > > @Name(“content”) > > > @MacroPriority(1000) > > > > > > > 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. > > Yes I’m fine with MacroExecutionPriority, not a problem, we can discuss > the details of the names ;) > > > public class ContentMacro implement Macro > > > > > > and > > > > > > @Component > > > @Named(“XWiki.WatchListJobClass") > > > @DocumentInitializerPriority(1000) > > > public class WatchListJobClassDocumentInitializer ... > > > > > > IMO the second one is more clear in its intent. WDYT? > > > > > > > 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. > > I do not agree with this (and I know a lot of devs don’t agree either > since this is one topic we’ve discussed in a Java podcast interview not > long ago on the LesCastCodeurs.com). > > Annotations are part of the language (contrary to Aspects!) and they are > close to the code so they are perfect to express cross-cutting concerns. > > We’re already using annotations for component metadata (@Component, > @Inject, @Named, etc). Using annotations for component priority makes a lot > of sense. > > And again, what is wrong IMO is actually what we’ve done (me being the > first to have done it in Macros…), which is the addition of > get/setPriority() methods in our component interfaces. The priority concept > is not a business concept and it fits better the concept of annotations. > > > 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. > > Yes, the intention was great: it’s always better to use something that > already exists rather than reinvent yours but in this case, as the javadoc > for Priority clearly states, the meaning of it is left to the code… If you > have only 1 concept of priority it’s not a problem. In our case it’s more > complex because we use components for lots of things and we have various > concepts of Priorities. > > TBH when I first started this thread it was a [Proposal] to use @Priority > everywhere we need a priority and then while writing the mail I discovered > the namespace issue and I rewrote the mail as a brainstorming, and as a > discussion as to whether we should (or not) use the @Priority annotation > only for the Mandatory Document Initializers (Once we release XWiki 7.0 > it’s going to be harder to change). > Just for clarification, I do not think we should use @Priority instead of @DisposePriority, for the reasons mentioned in my first reply. Thanks, Eduard > > > I`d love to hear more opinions on this :) > > Yup > > Thanks > -Vincent > > > 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-type-on-one-element > > > > > > > > On Thu, Mar 12, 2015 at 10:41 AM, [email protected] > > > > 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 > > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
