Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On Thu, Mar 12, 2015 at 10:41 AM, vinc...@massol.net vinc...@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). We could also define a generic Priority annotation that has a role (namespace) besides the value. @Priority(role = org.xwiki.rendering.macro.Macro.class, value = 210) The advantage I see is that we can write a generic component to retrieve the instance list sorted by priority, for a given role. Thanks, Marius WDYT? Thanks -Vincent W ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
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 ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
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). 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. 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, vinc...@massol.net vinc...@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 ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On 12 Mar 2015 at 10:30:50, Marius Dumitru Florea (mariusdumitru.flo...@xwiki.com(mailto:mariusdumitru.flo...@xwiki.com)) wrote: On Thu, Mar 12, 2015 at 10:41 AM, vinc...@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). We could also define a generic Priority annotation that has a role (namespace) besides the value. @Priority(role = org.xwiki.rendering.macro.Macro.class, value = 210) Yes, I thought about it too, but discarded it because it’s less nice than having a strongly typed annotation IMO. The advantage I see is that we can write a generic component to retrieve the instance list sorted by priority, for a given role. Retrieving a given annotation is a one liner in java so it’s not really an issue. Thanks -Vincent Thanks, Marius WDYT? Thanks -Vincent W ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On Thu, Mar 12, 2015 at 11:45 AM, vinc...@massol.net vinc...@massol.net wrote: On 12 Mar 2015 at 10:30:50, Marius Dumitru Florea (mariusdumitru.flo...@xwiki.com(mailto:mariusdumitru.flo...@xwiki.com)) wrote: On Thu, Mar 12, 2015 at 10:41 AM, vinc...@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). We could also define a generic Priority annotation that has a role (namespace) besides the value. @Priority(role = org.xwiki.rendering.macro.Macro.class, value = 210) Yes, I thought about it too, but discarded it because it’s less nice than having a strongly typed annotation IMO. The advantage I see is that we can write a generic component to retrieve the instance list sorted by priority, for a given role. Retrieving a given annotation is a one liner in java so it’s not really an issue. Sorting by priority is not a one liner, but neither too complex. Thanks -Vincent Thanks, Marius WDYT? Thanks -Vincent W ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On Thu, Mar 12, 2015 at 3:08 PM, vinc...@massol.net vinc...@massol.net wrote: On 12 Mar 2015 at 12:24:59, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) wrote: Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com (mailto: enygma2...@gmail.com)) 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
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On 03/12/2015 07:24 AM, Eduard Moraru wrote: Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) 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. 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. 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 :) For your love, here's another opinion. 1. I spent a while looking for javax.annotations.Priority, since I didn't see it at http://docs.oracle.com/javase/7/docs/api/javax/annotation/package-summary.html ... Turns out it's a JEE class that's not in JSE. AFAIK, we're not really using JEE yet, just JSE with a few JEE modules. Am I wrong? If not, do we want to require JEE from now on, or is that annotation available in a Maven Central library that doesn't bring in the whole JEE? 2. I agree with you that this is configuration, not code, thus changing it shouldn't require recompiling code. I'm -0.5 for the original proposal because of this. 3. I'd like to resurect http://markmail.org/thread/mrbmbn45cltfvh57 and enhance/build on top of it. Since we're already using an external file for listing components, and since we already have a kind of priority in that file, why not use that file to also give components priorities. If someone wants to change the priority of a component, all that's required is to add a new file in WEB-INF/classes with the new priority of the component. Before we discuss a syntax, anybody wants to veto 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.
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
On 12 Mar 2015 at 12:24:59, Eduard Moraru (enygma2...@gmail.com(mailto:enygma2...@gmail.com)) wrote: Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) 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). I`d love to hear more opinions on this :) Yup Thanks -Vincent Thanks, Eduard Priorities on other behaviors that are added to
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
Hi Sergiu, On 12 Mar 2015 at 20:45:41, Sergiu Dumitriu (ser...@xwiki.org(mailto:ser...@xwiki.org)) wrote: On 03/12/2015 07:24 AM, Eduard Moraru wrote: Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) 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. 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. 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 :) For your love, here's another opinion. 1. I spent a while looking for javax.annotations.Priority, since I didn't see it at http://docs.oracle.com/javase/7/docs/api/javax/annotation/package-summary.html ... Turns out it's a JEE class that's not in JSE. AFAIK, we're not really using JEE yet, just JSE with a few JEE modules. Am I wrong? If not, do we want to require JEE from now on, or is that annotation available in a Maven Central library that doesn't bring in the whole JEE? I’ll let Edy answer this but it doesn’t change the possibility to use typed annotations for Priorities. 2. I agree with you that this is configuration, not code, thus changing it shouldn't require recompiling code. I'm -0.5 for the original proposal because of this. If you check all existing Macros for example, we already use harcoded priorities everywhere (1000 by default) and some Macros have higher and lower values, and these values are static and require re-compilation if you change them. That’s ok because the priorities are not supposed to change (neither are the hints for components for the Threading model - singleton, per thread). Actually they should not change because the macros are coded to work with the defined priority. I really don’t see the difference between hardcoding in java vs hardcoding in an annotation. However (an again since nobody commented on that :)), I really don’t think that adding get/setPriority methods to business interfaces is a good thing. So typed annotations still win for me. 3. I'd like to resurect http://markmail.org/thread/mrbmbn45cltfvh57 and enhance/build on top of it. Since we're already using an external file for listing components, and since we
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
Hi, On Thu, Mar 12, 2015 at 9:44 PM, Sergiu Dumitriu ser...@xwiki.org wrote: On 03/12/2015 07:24 AM, Eduard Moraru wrote: Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) 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. 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. 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 :) For your love, here's another opinion. Always appreciated :) 1. I spent a while looking for javax.annotations.Priority, since I didn't see it at http://docs.oracle.com/javase/7/docs/api/javax/annotation/package-summary.html ... Turns out it's a JEE class that's not in JSE. AFAIK, we're not really using JEE yet, just JSE with a few JEE modules. Am I wrong? If not, do we want to require JEE from now on, or is that annotation available in a Maven Central library that doesn't bring in the whole JEE? Just an individual library: http://mvnrepository.com/artifact/javax.annotation/javax.annotation-api/1.2 2. I agree with you that this is configuration, not code, thus changing it shouldn't require recompiling code. I'm -0.5 for the original proposal because of this. 3. I'd like to resurect http://markmail.org/thread/mrbmbn45cltfvh57 and enhance/build on top of it. Since we're already using an external file for listing components, and since we already have a kind of priority in that file, why not use that file to also give components priorities. If someone wants to change the priority of a component, all that's required is to add a new file in WEB-INF/classes with the new priority of the component. Re 2) and 3): I also thought about externalizing all of this into a file, but I do not think this is the right situation where this applies. For instance, in JPA annotations, I would agree: That stuff belongs in a configuration file, not in class annotations. However, for components, it's not really something you get to configure that often. Also, if for JPA you had control over the DB to change things so a config file would be handy to just fix the config without a recompile,
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto:enygma2...@gmail.com)) 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? (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) 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? 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, vinc...@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 ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority
Hi, On Thu, Mar 12, 2015 at 12:03 PM, vinc...@massol.net vinc...@massol.net wrote: Hi Edy, On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2...@gmail.com(mailto: enygma2...@gmail.com)) 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. 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. 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-type-on-one-element On Thu, Mar 12, 2015 at 10:41 AM, vinc...@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
