Hi Andy,
any part of the spec?
@Lock is relevant only for singleton no? so why checking views?
- Romain
2012/7/5 andygumbre...@apache.org
Author: andygumbrecht
Date: Thu Jul 5 12:25:51 2012
New Revision: 1357576
URL: http://svn.apache.org/viewvc?rev=1357576view=rev
Log:
Fix hard
I have changed BeanContext to perform the check only for a singleton.
The BeanContext is used here:
org.apache.openejb.core.singleton.SingletonContainer#_invoke
boolean read =
javax.ejb.LockType.READ.equals(beanContext.*getConcurrencyAttribute*(runMethod));
This result was wrong for a singleton
weird since it was fine for me
but i know parent methods of a singleton are by default WRITE even if the
child is READ and i guess that's the same for intrefaces so i'm not sure of
the fix
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
I have changed BeanContext to perform the check
I also believe this is legal right?
@Local
@Lock(LockType.READ)
public interface *Deployer *{
@Remote
public interface DeployerRemote extends *Deployer *{
@Singleton
@TransactionManagement(TransactionManagementType.BEAN)
@AccessTimeout(value = 60, unit = TimeUnit.SECONDS)
public class
i tend to think so since intrefaces are kind of parent but i didnt find
(maybe miss) sthg clear in the spec
the lock is for me linked to impl not the contract
wdyt?
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
I also believe this is legal right?
@Local
@Lock(LockType.READ)
Romain Manni-Bucau wrote
weird since it was fine for me
I don't see how?
beanContext.*getConcurrencyAttribute*(runMethod) /always/ propagated to the
hard coded WRITE if methods were not explicitly annotated - This has to be
wrong if the class or interface is READ?
--
View this message in
no since it was handled at method level not class level.
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
Romain Manni-Bucau wrote
weird since it was fine for me
I don't see how?
beanContext.*getConcurrencyAttribute*(runMethod) /always/ propagated to the
hard coded WRITE if
I think the @Lock should /always/ be visible on the *public* contract
(interfaces), so that API users understand that there is one.
The implementation is *private* nö? The implementation should be able to
override the contract is it sees fit to do so, which is why I chose the
order @Remote,
Only handled at method level if there was an 'explicitly defined @Lock' on
the method else...
org.apache.openejb.MethodContext#getLockType
public LockType getLockType() {
return lockType != null? lockType: beanContext.getLockType();
}
...beanContext.getLockType() -- Was LockType.WRITE
weird i always got the right lock and never defined it at method level
but i never put lock on the interface
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
Only handled at method level if there was an 'explicitly defined @Lock' on
the method else...
10 matches
Mail list logo
