The key persistenceContextRef.noMatches is also not used. Should i just start deleting these keys from Messages.properties, or probably comment them out?
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
