On Jul 15, 2010, at 7:42 PM, Karan Malhi wrote: > The key persistenceContextRef.noMatches is also not used. Should i just > start deleting these keys from Messages.properties, or probably comment them > out?
If it is something worth checking and not covered, we should just add checks for it if possible. Fine to comment it out with a TODO in the meantime. -David > > On Thu, Jul 15, 2010 at 9:23 PM, David Blevins <[email protected]>wrote: > >> >> On Jul 15, 2010, at 5:26 PM, David Jencks wrote: >> >>> I think that particular one's xml element/jee tree class got renamed to >> ConcurrencyManagementType late in the spec. I don't know if it's being >> handled in code yet...so this may be of no use :-\ >> >> Renamed and relocated from assembly descriptor to under <session> >> >> Anyway, here's the code that drives concurrency-attribute: >> >> /* >> * @Lock >> */ >> if (sessionBean.getConcurrencyManagementType() == >> ConcurrencyManagementType.CONTAINER) { >> processAttributes(new >> ConcurrencyAttributeHandler(assemblyDescriptor, ejbName), clazz, >> inheritedClassFinder); >> } else { >> checkAttributes(new ConcurrencyAttributeHandler(assemblyDescriptor, >> ejbName), ejbName, ejbModule, classFinder, "invalidConcurrencyAttribute"); >> } >> >> It uses the same abstraction for method based processing as transaction >> attribute does (and also revealing of why it's hard to change that code to >> the different element) >> >> /* >> * TransactionAttribute >> */ >> if (bean.getTransactionType() == TransactionType.CONTAINER) { >> processAttributes(new >> TransactionAttributeHandler(assemblyDescriptor, ejbName), clazz, >> inheritedClassFinder); >> } else { >> checkAttributes(new TransactionAttributeHandler(assemblyDescriptor, >> ejbName), ejbName, ejbModule, classFinder, "invalidTransactionAttribute"); >> } >> >> >> On the assembler side, the code for the above and security attributes all >> uses the same algorithm (MethodAttributeInfo + >> MethodInfoUtil.resolveAttributes). >> >> Anyway, skip that message key because the relating code will greatly change >> at some painful point :) >> >> >> -David >> >> >>> >>> On Jul 15, 2010, at 4:40 PM, Karan Malhi wrote: >>> >>>> What needs to be done with keys which are listed in Messages.properties >> but >>>> are not used anywhere in the java code.? For example, >>>> xml.invalidConcurrencyAttribute cannot be found in any .java file in the >>>> ejb-core project, so I am assuming that there is not validation for >> this. >>>> >>>> On Thu, Jul 15, 2010 at 5:57 PM, Karan Malhi <[email protected]> >> wrote: >>>> >>>>> In the messages.properties, some of the keys have nice comments above >> them, >>>>> like fail() or warn(). This gives a good idea to the test author >> whether to >>>>> test for a warning or failure. Please try and make sure if you add keys >> to >>>>> this file, also supplement the keys with the little comment. >>>>> >>>>> >>>>> On Wed, Jul 14, 2010 at 11:38 PM, David Blevins < >> [email protected]>wrote: >>>>> >>>>>> >>>>>> On Jun 10, 2010, at 10:48 PM, David Blevins wrote: >>>>>> >>>>>>>> We really should have 100% coverage. If there is a message key for >> it >>>>>> in ../config/rules/Messages.properties, than there really should be a >> test >>>>>> for that scenario. >>>>>>> >>>>>>> Basically, we need to go through this list and make sure there are >> tests >>>>>> to challenge every message key: >>>>>> >>>>>> FYI, to those who haven't seen it. This is pretty darn cool!! >>>>>> >>>>>> >>>>>> >> https://cwiki.apache.org/confluence/display/OPENEJB/Validation+Keys+Audit+Report >>>>>> >>>>>> Innovative stuff! >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Karan Singh Malhi >>>>> >>>> >>>> >>>> >>>> -- >>>> Karan Singh Malhi >>> >>> >> >> > > > -- > Karan Singh Malhi
