[JBoss AOP] New message: "Pointcut not executing"
by yusef asjana
User development,
A new message was posted in the thread "Pointcut not executing":
http://community.jboss.org/message/522368#522368
Author : yusef asjana
Profile : http://community.jboss.org/people/yusefasjana
Message:
--------------------------------------------------------------
Hi, one of my pointcuts is not executing
execution(* com.test.Engine->getInstance(..))
I'm using the @Replace and MockAspect classes to mock some objects on my junit, one of the methods that I need to mock is the getInstance method on the Engine class. and whenever the method that I'm trying to mock references the class(eg.Engine) on it's signature the callback doesn't execute, then if i change the callback signature to return and Object everything works.
package com.test;
public class Engine {
public String name;
public String getResponse(String name)
{
return name;
}
public Engine()
{
System.out.println("CLASS");
}
public String retro()
{
return "Test2";
}
public static Engine getInstance()
{
Engine t = new Engine();
t.name="test";
return t;
}
}
public class BatchTest extends BaseTestCase{
@Test
@Replace(invocation = "com.test.Engine->getInstance(..)",
callbackClass = "BatchTest",
callbackMethod = "test")
public void executeTest() throws Exception
{
Engine engine = new Engine();
System.out.println(Engine.getInstance(new Batch()).name);
}
public Engine test()
{
Engine t = new Engine();
t.name="test3";
return t;
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522368#522368
16 years, 2 months
[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Flavia Rainone
User development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/522362#522362
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
> mailto:kabir.khan@jboss.com wrote:
>
> The only scenario I can think of where this might not happen, is if there are two classpools in the domain loading the same class? CP1 was added to the domain first and contains Class A, and CP2 was added later and also contains Class A. If a) happens for Class A using CP2 then that will be added, but in b) when hitting the domain CP1 will be used first. Maybe we are having problems with classpools not getting unregistered as they should?
I am not sure, because the tests fail even the first time I run the tests against a newly started up AS. Where else would this class be coming from, except from the new ClassPool itself?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522362#522362
16 years, 2 months
[EJB 3.0] New message: "Re: Setting MDB Max Pool Size"
by Leonardo Porto
User development,
A new message was posted in the thread "Setting MDB Max Pool Size":
http://community.jboss.org/message/522361#522361
Author : Leonardo Porto
Profile : http://community.jboss.org/people/leoporto
Message:
--------------------------------------------------------------
Thanks for replying. While i was waiting for someone to reply to this post i also tried that annotation:
@Pool(value=PoolDefaults.POOL_IMPLEMENTATION_STRICTMAX, maxSize=50, timeout=10000)
The one that is mentioned in that page you linked and still didnt work. Take a look at the attached SS that i took from the queue in the Admin Console. As you can see the consumer count is 1... Its very simple, and its working too, i just want to configure more consumers... thx in advance
http://community.jboss.org/servlet/JiveServlet/showImage/1879/imagem.JPG
Below is my code:
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
import org.jboss.ejb3.annotation.Pool;
import org.jboss.ejb3.annotation.defaults.PoolDefaults;
/**
* Message-Driven Bean implementation class for: MDB
*
*/
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "Destination", propertyValue = "/queue/test"),
}
)
@Pool(value=PoolDefaults.POOL_IMPLEMENTATION_STRICTMAX, maxSize=50, timeout=10000)
public class MDB implements MessageListener {
/**
* Default constructor.
*/
public MDB() {
}
/**
* @see MessageListener#onMessage(Message)
*/
public void onMessage(Message message) {
try {
System.out.println("****** RECEIVED MSG *****************************************************************");
System.out.println("*************************************************************************************");
System.out.println(((TextMessage) message).getText());
System.out.println("*************************************************************************************");
System.out.println("");
} catch (JMSException e) {
e.printStackTrace();
}
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522361#522361
16 years, 2 months
[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Flavia Rainone
User development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/522355#522355
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
> mailto:kabir.khan@jboss.com wrote:
>
> > mailto:flavia.rainone@jboss.com wrote:
> > - why is it that calling get on the default domain returns a different version of the same class? This needs further investigation because it is clearly a bug
> Yes, this definitely needs fixing. But I thought we had tests for this already? e.g. this from SimpleDelegatingClassPoolTestCase. I added a few extra checks as indicated to make double sure
>
> *public* *void* testOnePoolPerClassLoadedByA() *throws* Exception
> {
> ClassPoolDomain domain = createClassPoolDomain("SIMPLE", null, *false*);
> ClassPool poolA = createDelegatingClassPool(domain, JAR_A_URL);
> ClassPool poolB = createDelegatingClassPool(domain, JAR_B_URL);
>
> //The first time we access the pool it will create the classes, second time will use the cache
> accessOnePoolPerClassLoadedByA(poolA, poolB);
> accessOnePoolPerClassLoadedByA(poolA, poolB);
> }
>
> private *void* accessOnePoolPerClassLoadedByA(ClassPool poolA, ClassPool poolB) *throws* Exception
> {
> CtClass a = poolA.get(CLASS_A);
> assertEquals(a, poolA.get(CLASS_A));//Added
> assertEquals(a, poolB.get(CLASS_A));//Added
> CtClass b = poolA.get(CLASS_B);
> assertEquals(b, poolA.get(CLASS_B));//Added
> assertEquals(b, poolB.get(CLASS_B));//Added
>
> assertNotSame(a.getClassPool(), b.getClassPool());
> assertEquals(poolA, a.getClassPool());
> assertEquals(poolB, b.getClassPool());
> }
>
>
>
>
For some reason yet to be found, those tests do not replicate what is happening in the tests in AS. I'll have to do more debugging to find out exactly what is going on and then add any tests to jboss-classpool if needed.
> mailto:kabir.khan@jboss.com wrote:
> > mailto:flavia.rainone@jboss.com wrote:
> >
> > - why wasn't the classes cache being used by BaseClassPool.get before? Any reason for this? This has been copied from previous versions, I think that it definetly causes some overhead (the above should work, but it would be faster if the classpool finds out it has already created the class and returns the same class instead of delegating to the domain first).
> I can't see anything in BaseClassPool.get() or get0() regarding this? I think you mean DelegatingClassPool.get0()? I don't see the ClassPool.classes cache being used there either, so maybe I am looking in the wrong place. If I am in the right place, it might be an idea to try to load it locally in the initiating classpool first before hitting the domain if the cachedLookups == null.
>
> //TODO KABIR was synchronized - I don't see why apart from that the standard javassist.ClassPool implementation was synchronized?
> *public* *final* CtClass get0(String classname, *boolean* useCache) *throws* NotFoundException
> {
> //KABIR Made final just to make sure that cached lookups are only handled in one place.
>
> *if* (cachedLookups != *null*)
> {
> CtClass cachedLookup = cachedLookups.get(classname, domain.getModCount());
> *if* (cachedLookup != *null*)
> {
> logger.trace(classname + " was found in the cache of " + *this*);
> *return* cachedLookup;
> }
> }
> *else*
> {
> CtClass cached = getCachedLocally(classname);
> *if* (cached != *null*)
> *return* cached;
> }
>
> ...
> }
>
That's the point I'm saying that, IMO, the first thing that BaseClassPool.get should do is looking in the cache. Currently, it doesn't. That has been done only locally in my machine, and fixed the failing tests. I haven't comitted anything because none of this is 100% validated yet.
> mailto:kabir.khan@jboss.com wrote:
> > mailto:flavia.rainone@jboss.com wrote:
> > - if the cache starts being used as a first step of BaseClassPool.get, as it is in my local fix (not committed yet), is there need for a second level cache as Kabir wrote?
> Yes. It caches all CtClasses looked up by that classpool, and they might come from any classpool in the domain. The cacheLookups of all the classpools in the domain are invalidated when a classpool is added/removed to the domain or its parent domain. Basically, it means that if we look something up in a classpool, we don't need to do all the work in the domain.
I see now. This looks nice . Testing the cache in AS is next in my list.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522355#522355
16 years, 2 months
[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Kabir Khan
User development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/522345#522345
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> mailto:flavia.rainone@jboss.com wrote:
>
> A quick update on this: for some reason, the behavior of ClassPool.get method is no longer consistent with ScopedClassPool.getLocally method.
Thinking about this, aside from the performance comments, I don't understand why this would happen? The flow should be as mentioned below
> mailto:flavia.rainone@jboss.com wrote:
>
> The first time AOP asks for a class, during transformation, it knows that the class should be generated by the exact same classpool that corresponds to the classloader that loaded the class, so it uses getLocally.
a) So here the class should be found and added to the classpool's cache in ClassPool.classes
> mailto:flavia.rainone@jboss.com wrote:
>
> The second time AOP asks for the class is during the same transformation (these are actually indirect calls made from inside javassist, during call weaving, for example), the class is retrieved through get. Currently, the classpool delegates the retrieval of the class to the default domain, and the default domain returns a different class.
b) So it delegates to the domain, which goes over all the classpools in the domain and calls loadLocally() on each class. This hits the cache and if not found there tries to load the class locally. When it comes to the classpool in a) it should be found in its ClassPool.classes.
The only scenario I can think of where this might not happen, is if there are two classpools in the domain loading the same class? CP1 was added to the domain first and contains Class A, and CP2 was added later and also contains Class A. If a) happens for Class A using CP2 then that will be added, but in b) when hitting the domain CP1 will be used first. Maybe we are having problems with classpools not getting unregistered as they should?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522345#522345
16 years, 2 months
[jBPM] New message: "Async continuation in decision activity"
by Johan Kumps
User development,
A new message was posted in the thread "Async continuation in decision activity":
http://community.jboss.org/message/522344#522344
Author : Johan Kumps
Profile : http://community.jboss.org/people/johan.kumps
Message:
--------------------------------------------------------------
Hi all,
I want to use an asynchrounous continuation in my JBpm process. Please consider following piece of my process definition :
...
...
The WorkerDecisionHandler is implemented using Drools.
When an instance is of this process is being created I want it to run the WorkerDecisionHandler in a separate thread. So I configured it as follows :
...
...
When trying it using a unit test I think no separate thread is used to run the WorkerDecisionHandler in. I print the Thread.currentThread() in my test class and in the WorkerDecisionHandler and these are the same. What am I doing wrong?
T in Test : hread[main,5,main]
T in WorkerDecisionHandler : Thread[main,5,main]
Kind regards,
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522344#522344
16 years, 2 months
[EJB 3.0] New message: "Setting MDB Max Pool Size"
by Leonardo Porto
User development,
A new message was posted in the thread "Setting MDB Max Pool Size":
http://community.jboss.org/message/522342#522342
Author : Leonardo Porto
Profile : http://community.jboss.org/people/leoporto
Message:
--------------------------------------------------------------
Hi all,
id like to know how do i set up the maximum pool size for a MDB. I ve tried an annotation (@ActivationConfigProperty(propertyName = "MaxPoolSize", propertyValue = "20"),) but i keep getting the exception below. Is there another way? I am using JBOSS 5 and EJB3.
org.jboss.deployers.spi.DeploymentException: Error for ActivationSpec class org.jboss.resource.adapter.jms.inflow.JmsActivationSpec as JavaBean
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:135)
at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:313)
at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:276)
at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.ejb3.JmxClientKernelAbstraction.invoke(JmxClientKernelAbstraction.java:58)
at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.createActivationSpec(JBossMessageEndpointFactory.java:320)
at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.start(JBossMessageEndpointFactory.java:205)
at org.jboss.ejb3.mdb.MessagingContainer.startProxies(MessagingContainer.java:224)
at org.jboss.ejb3.mdb.MessagingContainer.lockedStart(MessagingContainer.java:176)
at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:884)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Unknown Source)
Caused by: java.beans.IntrospectionException: No property found for: MaxPoolSize on JavaBean: org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@1e1356d(ra=null destination=null destinationType=null tx=true durable=false reconnect=10 provider=java:/DefaultJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=60000 useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=5)
at org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties(PropertyEditors.java:354)
at org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties(PropertyEditors.java:285)
at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:129)
... 71 more
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522342#522342
16 years, 2 months
