[JBoss JIRA] Created: (JBMICROCONT-279) Check for InstanceAnnotation when doing hasMetaDataAtInstanceLevel in AOPConstructorJoinpoint
by Ales Justin (JIRA)
Check for InstanceAnnotation when doing hasMetaDataAtInstanceLevel in AOPConstructorJoinpoint
---------------------------------------------------------------------------------------------
Key: JBMICROCONT-279
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-279
Project: JBoss MicroContainer
Issue Type: Feature Request
Components: AOP
Affects Versions: JBossMC-2.0.0.Beta12
Reporter: Ales Justin
Assigned To: Ales Justin
Fix For: JBossMC.2.0.0.CR1
When AOP asks whether there are instance annotations it does this to decide whether an instance proxy is required.
In some cases, e.g. the @JMX annotation, the instance annotation does not require an instance proxy
instead we are just reusing the point cut language to invoke "advices" during deployment.
To better handle this case, we should be able to meta annotate an annotation as not requiring an instance proxy,
e.g. something like:
@org.jboss.metadata.spi.annotation.InstanceAnnotation(false)
public @interface JMX
{
...
}
then we can tell aop whether an instance proxy is required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBCACHE-1326) TxInterceptor leaks MethodCall to thread
by Brian Stansberry (JIRA)
TxInterceptor leaks MethodCall to thread
----------------------------------------
Key: JBCACHE-1326
URL: http://jira.jboss.com/jira/browse/JBCACHE-1326
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 2.1.0.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.1.1.GA, 2.2.0.GA
The various Synchronization callbacks in TxInterceptor end up calling the equivalent of cache.getInvocationContext().setMethodCall(xxx) but then don't restore the InvocationContext to its previous state when done. All other calls to InvocationContext.setMethodCall() do reverse themselves after the call is executed, so the effect is whatever MethodCall a TxInterceptor synchronization last associated to a thread ends up staying with that thread until some random other synchronization changes it to something different.
This is showing up in the AS as a classloader leak, since the leaked MethodCall has a ref to undeployed classes. If a server had a large thread pool, the leak could be long lasting.
I've added an assertion to org.jboss.cache.invocationcontext.TransactionTest.doScrubbingTest that shows the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month