12 Mar
2015
12 Mar
'15
2:24 p.m.
On Thu, Mar 12, 2015 at 3:08 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 12 Mar 2015 at 12:24:59, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
...and because they clearly express it, in their documentations, that they
Just for clarification, I do not think we should use @Priority instead of
@DisposePriority, for the reasons mentioned in my first reply.
Thanks,
Eduard
Hi,
On Thu, Mar 12, 2015 at 12:03 PM, vincent(a)massol.net
wrote:
> Hi Edy,
>
> On 12 Mar 2015 at 10:49:29, Eduard Moraru (enygma2002(a)gmail.com
(mailto:
> enygma2002(a)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?
accept some annotations and they define how those
annotations will be
interpreted. Basically, the purpose of the javax.annotations package.
with
(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 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
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.
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.
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 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
> > >
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs