On Jul 23, 2010, at 7:54 PM, Karan Malhi wrote:
> I do see some TODO's in the Jee schema. Here is a snippet from
> AssemblyDescriptor:
>
> ** snip **
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "assembly-descriptorType", propOrder = {
> "securityRole",
> "methodPermission",
> "containerTransaction",
> //TODO moved out of assembly descriptor in schema
> "containerConcurrency",
> //TODO moved out of assembly descriptor in schema
> "methodSchedule",
> "interceptorBinding",
> "messageDestination",
> "excludeList",
> "applicationException"
> })
> ** snip **
>
> Seems like the schema has been modified by the code has not been updated.
> Just need somebody to verify it before I start making changes. Looks like
> some existing tests might have to be re-written too, those tests are still
> using assembly descriptor for concurrency info.
The non-jaxb code is based on a draft schema. I updated the jaxb code to match
the final schema, with the exception of the TODO's you found, but I didn't
understand what the xml meant well enough to update the non-jaxb code. Maybe
you can figure it out :-)
thanks
david jencks
>
> On Fri, Jul 23, 2010 at 10:19 PM, Karan Malhi <[email protected]> wrote:
>
>> Am working on writing some validation tests for Concurrency, according to
>> the ejb 3.1 schema, the lock is to be specified in the<concurrent-method>
>> which is part of the <session> element.
>> <concurrent-method id="idvalue10">
>> <method id="idvalue11">
>> . . . . .
>> </method>
>> <lock>lock</lock>
>> <access-timeout id="idvalue13">
>> . . . .
>> </access-timeout>
>> </concurrent-method>
>>
>> This means that I should be able to add this info to the EjbJar as shown
>> below:
>>
>> EjbJar ejbJar = new EjbJar();
>> SingletonBean bean = ejbJar.addEnterpriseBean(new
>> SingletonBean(XmlTestBean.class));
>>
>> bean.setConcurrencyManagementType(org.apache.openejb.jee.ConcurrencyManagementType.BEAN);
>> ConcurrentMethod method = new ConcurrentMethod();
>> method.setLock(ConcurrentLockType.WRITE);
>> bean.getConcurrentMethod().add(method);
>>
>> However, when I look at the AnnotationDeployer (which contains the
>> validation code), it tries to look for a concurrent-method in the
>> assembly-descriptor (shown below)
>>
>> public Map<String, List<MethodAttribute>>
>> getExistingDeclarations() {
>> return assemblyDescriptor.getMethodConcurrencyMap(ejbName);
>> }
>>
>> Shouldn't the AnnotationDeployer be looking for the concurrent-method in
>> the SingletonBean instead?
>> I am in the middle of writing the test and wanted to confirm that the
>> AnnotationDeployer behavior would need to be changed.
>>
>> --
>> Karan Singh Malhi
>>
>
>
>
> --
> Karan Singh Malhi
