[Design the new POJO MicroContainer] - MC AOP CL issue
by alesj
As part of my IoC demos
- http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun...
I'm deploying a jar that includes -beans.xml with some aop xml code:
| <interceptor xmlns="urn:jboss:aop-beans:1.0" name="StopWatchInterceptor" class="org.jboss.demos.ioc.annotations.StopWatchInterceptor"/>
|
| <bind xmlns="urn:jboss:aop-beans:1.0" pointcut="execution(* @org.jboss.demos.ioc.annotations.StopWatchLog->*(..)) OR execution(* *->@org.jboss.demos.ioc.annotations.StopWatchLog(..))">
| <interceptor-ref name="StopWatchInterceptor"/>
| </bind>
|
| <bean name="AnnotatedExecutor" class="org.jboss.demos.ioc.annotations.AnnotatedExecutor">
| <constructor>
| <parameter><bean class="org.jboss.demos.ioc.annotations.SimpleExecutor"/></parameter>
| </constructor>
| </bean>
|
| <bean name="SimpleExecutorOnType" class="org.jboss.demos.ioc.annotations.SimpleExecutor">
| <annotation>@org.jboss.demos.ioc.annotations.StopWatchLog</annotation>
| </bean>
|
| <bean name="SimpleExecutorOnMethod" class="org.jboss.demos.ioc.annotations.SimpleExecutor">
| <install method="execute">
| <annotation>@org.jboss.demos.ioc.annotations.StopWatchLog</annotation>
| </install>
| </bean>
|
This jar includes this StopWatchInterceptor class,
but I get the following exception:
| JBoss-MC-Demo ERROR [27-10-2008 15:45:03] AbstractKernelController - Error installing to Described: name=AnnotatedExecutor state=PreInstall
| java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.demos.ioc.annotations.StopWatchInterceptor
| at org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory.doCreate(GenericBeanAspectFactory.java:135)
| at org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory.createPerVM(GenericBeanAspectFactory.java:90)
| at org.jboss.aop.AspectManager.createPerVmAspect(AspectManager.java:1942)
| at org.jboss.aop.AspectManager.getPerVMAspect(AspectManager.java:1918)
| at org.jboss.aop.Domain.getPerVMAspect(Domain.java:788)
| at org.jboss.aop.Domain.getPerVMAspect(Domain.java:773)
| at org.jboss.aop.advice.ScopedInterceptorFactory.create(ScopedInterceptorFactory.java:69)
| at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:1318)
| at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:1929)
| at org.jboss.aop.MethodMatchInfo.applyBinding(MethodMatchInfo.java:152)
| at org.jboss.aop.MethodMatchInfo.overridePopulateBindings(MethodMatchInfo.java:143)
| at org.jboss.aop.MethodMatchInfo.populateBindings(MethodMatchInfo.java:92)
| at org.jboss.aop.Advisor.finalizeMethodChain(Advisor.java:1540)
| at org.jboss.aop.ClassContainer.makeInterceptorChains(ClassContainer.java:347)
| at org.jboss.aop.ClassContainer.createInterceptorChains(ClassContainer.java:313)
| at org.jboss.aop.ClassContainer.rebuildInterceptors(ClassContainer.java:138)
| at org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:72)
| at org.jboss.aop.proxy.container.ClassProxyContainer.initialise(ClassProxyContainer.java:177)
| at org.jboss.aop.proxy.container.ContainerCache.createContainer(ContainerCache.java:203)
| at org.jboss.aop.proxy.container.ContainerCache.createAndCacheContainer(ContainerCache.java:191)
| at org.jboss.aop.proxy.container.ContainerCache.initClassContainer(ContainerCache.java:164)
| at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:92)
| at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:72)
| at org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getDependencies(AOPDependencyBuilder.java:99)
| at org.jboss.kernel.plugins.dependency.DescribeAction.installActionInternal(DescribeAction.java:56)
The issue is that GenericBeanAspectFactory/GenericBeanFactory uses the wrong classloader != not deployment unit's classloader.
Was this ever tested in JBoss5?
Or what piece of code/xml am I missing in my demos?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184871#4184871
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184871
15 years, 6 months
[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller＠jboss.com
"bstansberry(a)jboss.com" wrote : Just an update.
|
| First, I deployed a bean with configuration like what you reported Andy, and when StatefulTreeCache was accessing the bean metadata to determine how to set up JBoss Cache's passivation, it got a maxSize=100000. So, that's all working fine.
|
| I deployed the bean along with a little service that creates a configurable # of threads that loop a configurable number of times instantiating new beans. Doesn't use the beans after looking up the proxy and invoking a single getter. Fired it off telling it to use 4 threads to create 200K beans. Am now watching the JMX console view of the bean container to see what happens.
|
| 1) The CurrentSize attribute steadily rose past 10K; no apparent limit; eventually got up to over 24K
|
| 2) After 5 mins, consistent with the default @CacheConfig.idleTimeoutSeconds=300 in ejb3-interceptors-aop.xml, passivation kicked in and the CurrentSize started dropping a bit while PassivatedCount steadily rose. It would appear the single background thread is able to passivate beans faster than the 4 threads create them.
|
| Judging from some periodic logging I added, it's taking about 6 secs to create 500 beans. The beans aren't particularly heavyweight, the client is in-vm, and there's only one node in the cluster, so no replication going on. So not particularly fast.
|
| But, the passivation part seems to be working as I'd expect.
In my test, what I see in the JMX console is a -1 in the maxSize. I even have the maxSize changed in ejb3-interceptors-aop.xml to 125,000, so I can tell the difference between the two caches. I have even tried putting the @CacheConfig annotation in, and it still shows -1 in the maxSize in the JMX console.
Is it possible that what you are testing is not what is in the CR 2 build?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184864#4184864
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184864
15 years, 6 months
[Design the new POJO MicroContainer] - ClassLoader injection Scope issue
by alesj
Hacking around my demos, I came across this CL usage.
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <classloader><inject bean="custom-classloader:0.0.0"/></classloader>
|
| <classloader name="custom-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true"/>
|
| <bean name="CB1" class="org.jboss.demos.ioc.classloader.CustomBean"/>
|
| </deployment>
|
This looks legit as we have similar config in JBoss5/conf.
But it fails for me with this exception:
| Caused by: java.lang.IllegalStateException: No context for AbstractDependencyValueMetaData@4d2af2{value=custom-classloader:0.0.0}
| at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.getValue(AbstractDependencyValueMetaData.java:205)
| at org.jboss.kernel.plugins.config.Configurator.getClassLoader(Configurator.java:665)
| at org.jboss.kernel.plugins.config.Configurator.getClassLoader(Configurator.java:646)
| at org.jboss.kernel.plugins.dependency.KernelScopeInfo.getScope(KernelScopeInfo.java:97)
Why this works in JBoss5 and not here? ;-)
The reason is that this was never tested outside jbossas/conf directory.
Meaning none of those config files are picked up by BeanMetaDataDeployer.
It's the BMDD that causes this to fail while merging scopes.
| ScopeInfo scopeInfo = context.getScopeInfo();
| if (scopeInfo != null)
| {
| mergeScopes(scopeInfo.getScope(), unit.getScope());
| mergeScopes(scopeInfo.getMutableScope(), unit.getMutableScope());
|
ScopeInfo::getScope
| // THIS IS A HACK - the scope originally gets initialise with a class name, we fix it to have the class
| ScopeKey key = super.getScope();
| Scope scope = key.getScope(CommonLevels.CLASS);
| if (scope == null)
| return key;
| Object qualifier = scope.getQualifier();
| if (qualifier instanceof Class)
| return key;
|
| String className = (String) qualifier;
| ClassLoader cl;
| try
| {
| cl = Configurator.getClassLoader(beanMetaData);
| }
| catch (Throwable t)
| {
| throw new RuntimeException("Error getting classloader for " + key, t);
| }
|
Where Configurator::getClassLoader invokes AbstractDependencyValueMetaData::getValue,
but ADVMD instance has not yet been visited, hence its underlying context is null:
| public Object getValue(TypeInfo info, ClassLoader cl) throws Throwable
| {
| ControllerState state = dependentState;
| if (state == null)
| state = ControllerState.INSTALLED;
| if (context == null)
| throw new IllegalStateException("No context for " + this);
| Controller controller = context.getController();
|
Using MC bean metadata outside MC's Controller looks dangerous. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184835#4184835
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184835
15 years, 6 months
[Design of EJB 3.0] - Re: Reintroducing Asynchronous Support
by david.lloyd＠jboss.com
"ALRubinger" wrote : Now, if the bean provider chooses to honor the request to cancel, there's a missing mechanism to let the client to know whether the request was fulfilled. So what should be the proper return value of "cancel()"?
|
| I'll pose this question to the JSR318 EG.
Yeah, it seems to me there's really no gray area in the javadoc for Future - "true" means cancelled, "false" means not cancelled. There's no answer that means "outcome unknown" - you pretty much would have to throw a RuntimeException in that case to strictly fulfill the contract (though in practice, returning "false" is probably good enough... that's what I do with my wrapper class anyway). Not only that but the method is (implicitly) blocking but not interruptible. Blah.
A good client use case that I measure against is a Swing client. For a long-running task, they'll want to have a "cancel" button for sure. Also, in a Swing client you don't want to block the EDT. Using a non-blocking .cancel() method is perfect for this case. The close button can map directly to the .cancel() method, with no intervening logic, and the future's callback (or a separate waiting thread) can be used to retrieve the result. Using j.u.c.Future you'd need to execute the .cancel() in another thread just in case it blocks (and manually prevent multiple button presses as well). I think that the AJAX world will also see similar behavior.
"ALRubinger" wrote : At first glance I'd approach this by using a XNIO Future impl under the hood, and wrapping w/ j.u.c.Future to return to the client. This would also pave the way to provide for more than one async interface to the client, who could choose his view (XNIO, j.u.c, etc). I'm weary of drawing in another dependency unless it's already brought into AS somewhere?
It will be, for Remoting to start with, and other projects going forward.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184833#4184833
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184833
15 years, 6 months