AFAIK this will only work if the container infoke the method.
So private and protected are not visible.
Same will be for other annotations like transaction ...
thanks for the quick reply!
Probably I'm in the wrong discussion forum, as my question is really not JBoss AS specific, but I couldn't find a better place to put it :-/
Still, I thought it might be a good place to ask it here as some JBoss members were in the expert group for JSR 250.
To be honest, I'm not familiar how JBoss AS 'decorates' or 'advises' (in AOP speak) the JSR-250 annotated classes with the security-checking aspect. My assumption was that JBoss AS uses some kind of proxying approach (e.g. JDK dynamic proxies or cglib), which - as you said - means that only external method calls going through the proxy are advised. And from external point I can call only public (or even package protected) methods, thus you could argue that the JSR-250 annotations should be applicable to public methods only.
In our case we are considering to use AspectJ to weave in the security-checking aspect into the bytecode of the JSR-250 annotated beans. When using such a weaving-based approach it makes perfect sense to allow the JSR-250 annotations to be applied to private and protected methods as well IMHO.
What do you think about it?
It's actually really a question about the specification, not JBoss AS...
1 of 1 people found this helpful
The EJB specification limits the way security annotation are applicable. See EJB 3.1 FR 17.3.2.
So it is as you say, only methods on the views are 'advised'.
If you go for another invocation mechanism you can go whichever way you want. The JSR 250 specification doesn't put up any limitations in that regard.
Carlo, thanks a lot! This definitely clarifies the situtation in the EJB case!
For the non-EJB case I was hoping to get a definite answer on whether:
(a) the JSR-250 spec does not explicitly prohibit to put the security annotations on private methods, thus it is valid according to the spec, or
(b) it is not mentioned / foreseen in the spec, thus it is not valid according to the spec and is currently a "blank spot" that might be fixed somewhen
Probably I'm asking too much to get a "definitive answer" on that. My hope was that someone of you might have more insight (even into the JSR 250 expert group) and/or background information.
For example, I could imagine that the context/mindset of the expert group was very EJB-driven. If so, there might have been an implicit expectation that the annotations make sense on public methods only at the time the spec was written? (hope not)
It's still unclear to me how it was really intended...