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

Reply via email to