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
>
>
