On Jan 12, 2009, at 1:09 AM, Marcin Kwapisz wrote:
Hi,
I think this property should be set in System, not in
InitialContext.
System
.setProperty("log4j.category.OpenEJB.startup.attributes","DEBUG");
I'm not sure if you're stating a preference or reporting that setting
via InitialContext didn't work. Both approaches should work in the
current release.
[Marcin Kwapisz]
p.setProperty("log4j.category.OpenEJB.startup.attributes", "DEBUG");
ctx = new InitialContext(p);
It does not work. That’s why I have set that value as a system
property.
Thanks for reporting that. I thought I had testing it as both. Looks
like the logging initialization was happening just before the
InitialContext properties were getting seen. I've fixed things up so
that logging is reinitialized and the logging overrides in the
InitialContext properties get picked up as they should.
The fix should be in the 3.1.1-SNAPSHOT jars.
We achieve this by translating the annotation into their *exact* xml
equivalent and processing them together as if everything had been
declared in xml.
[Marcin Kwapisz]
Thanks David for very extensive and exhaustive explanation. More
precise method description helps to override the security
annotation. Glassfish accepts such deployment descriptor also so
there is no problem now.
No problem, it needed to be documented. Just need to get that text
into the wiki.
I am curious how other application servers process security
annotations and if OpenEJB is distinguished by that.
It seems to be the case as far as I can tell. The same rules apply to
the way we process transaction annotations and the new singleton @Lock
annotation which have identical rules for annotation inheritance.
I take as a common rule that any value set in a deployment
descriptor overrides an annotation value. I think, that rule comes
from JEE specification so I was a little surprised when it did not
work in OpenEJB.
Right, it does in concept, but the actual semantics of overriding are
not covered in detail. The goal in EJB 3.0 was to create annotations
that could express what the xml could do in the goal of replacing the
xml. In the case of the transaction and security annotations, the
annotations actually have *more* expressive power than the equivalent
xml as the annotations can be applied to super classes resulting in
pretty complex layering that you can't do the same way in xml. We
made it possible in our impl, but as far as I know were the only one
to do so.
-David
