12 Mar
2015
12 Mar
'15
11:03 a.m.
Hi Edy,
On 12 Mar 2015 at 10:49:29, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@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…
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