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