[Design the new POJO MicroContainer] - DeploymentClassLoader test failing
by alesj
I get the following exception:
| -------------------------------------------------------------------------------
| Test set: org.jboss.test.kernel.deployment.test.DeploymentClassLoaderTestCase
| -------------------------------------------------------------------------------
| Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.062 sec <<< FAILURE!
| testDeploymentClassLoader(org.jboss.test.kernel.deployment.test.DeploymentClassLoaderTestCase) Time elapsed: 0.016 sec <<< ERROR!
| java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
| at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
| at java.security.AccessController.checkPermission(AccessController.java:427)
| at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
| at java.lang.Class.getClassLoader(Class.java:588)
| at org.jboss.test.kernel.deployment.test.DeploymentClassLoaderTestCase.testDeploymentClassLoader(DeploymentClassLoaderTestCase.java:56)
| at org.jboss.test.kernel.deployment.test.DeploymentClassLoaderTestCase.testDeploymentClassLoader(DeploymentClassLoaderTestCase.java:56)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:154)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
|
|
I don't see how this can be related with my latest (lazy) changes. :-(
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092806#4092806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092806
18 years, 7 months
[Design the new POJO MicroContainer] - Lazy bean behaviour
by alesj
I'm doing (apart from AS5_PS ... no worries ;-)) some GUI example console for MC and was missing the following feature - lazy 'instantiation/install' of the bean.
e.g. I have some service that has many dependencies - many injected beans. One of them is rarely used and/or is fully installed in some later-on deployment unit. But I would still like to have that first service up and running.
So, I hacked a lazy notion to our beans - lazy proxies.
What you can do now is the following XML
| <bean name="bean" class="org.jboss.test.kernel.lazy.support.RareBean"/>
|
| <lazy name="proxy" bean="bean" exposeClass="true">
| <interface>org.jboss.test.kernel.lazy.support.IRare</interface>
| </lazy>
|
or the straight API
| AbstractLazyMetaData lazy = new AbstractLazyMetaData("bean");
| lazy.setInterfaces(Collections.singleton(IRare.class.getName()));
|
And the test to show that lazyness :-)
| AbstractBeanMetaData bean = new AbstractBeanMetaData("bean", RareBean.class.getName());
| bean.setMode(ControllerMode.MANUAL);
|
| KernelControllerContext beanContext = controller.install(bean);
| controller.change(beanContext, ControllerState.NOT_INSTALLED);
|
| ModifiedLazyMetaData lazy = new ModifiedLazyMetaData("bean", getFactoryClassName());
| lazy.setInterfaces(Collections.singleton(IRare.class.getName()));
| KernelControllerContext lazyContext = controller.install(lazy);
|
| assertNotNull(lazyContext);
| assertEquals(ControllerState.DESCRIBED, lazyContext.getState());
|
| controller.change(beanContext, ControllerState.DESCRIBED);
| controller.change(lazyContext, ControllerState.INSTALLED);
|
| IRare lazyRare = (IRare)lazyContext.getTarget();
| assertNotNull(lazyRare);
|
| try
| {
| lazyRare.getHits();
| throw new RuntimeException("Should not be here.");
| }
| catch(Throwable t)
| {
| assertInstanceOf(t, IllegalArgumentException.class);
| }
|
| controller.change(beanContext, ControllerState.INSTALLED);
|
| assertEquals(0, lazyRare.getHits());
| lazyRare.setHits(10);
| assertEquals(5, lazyRare.checkHits(15));
|
The code checks for the first available proxy generator - Javassist, JBossAOP (wip), JDK, ... (possible additions CGLIB, ASM, ...)
| static
| {
| initializerMap = new LinkedHashMap<String, String>();
| // test class name, actual LazyInitializer implementation
| initializerMap.put("javassist.util.proxy.ProxyObject", "org.jboss.kernel.plugins.lazy.JavassistLazyInitializer");
| initializerMap.put("org.jboss.aop.proxy.container.AOPProxyFactoryParameters", "org.jboss.aop.microcontainer.lazy.JBossAOPLazyInitializer");
| initializerMap.put("java.lang.reflect.Proxy", "org.jboss.kernel.plugins.lazy.JDKLazyInitializer");
| }
|
| /**
| * Get the LazyInitializater instance.
| *
| * @param configurator the configurator
| * @return initializer instance
| */
| protected static LazyInitializer getInitializer(KernelConfigurator configurator)
| {
| if (initializer == null)
| {
| for(Map.Entry<String, String> entry : initializerMap.entrySet())
| {
| if (testLibExists(entry.getKey()))
| {
| initializer = createInitializer(configurator, entry.getValue());
| if (initializer != null)
| break;
| }
| }
| }
| if (initializer == null)
| throw new IllegalArgumentException("Cannot initialize LazyInitializater, check classpath for missing classes.");
| return initializer;
| }
|
The proxies use KernelBus to do the invocation.
Currently you need to specify which interfaces are exposed.
Perhaps this can be done automa(g|t)ically?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092782#4092782
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092782
18 years, 7 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk
by galder.zamarreno＠jboss.com
"bstansberry(a)jboss.com" wrote : Please create JIRAs for these. If you can fix them, even better. :-)
I'll create them and try to fix them too :)
"bstansberry(a)jboss.com" wrote : I've only taken a one minute glance at the relevant UnifiedInvokerHA code. Would some synchronization in the UnifiedInvokerHAProxy.getClient code solve the problem? I believe UnifiedInvokerHAProxy.invoke does not use the client instance field, but rather a local variable.
|
| A map of Clients keyed by target is also a possibility, although that's a more complex solution.
UnifiedInvokerHAProxy.getClient() returns the client instance variable. This is set in init(InvokerLocator) which gets called once only for UnifiedInvokerProxy. However in UnifiedInvokerHAProxy, this method is called whenever the cached locator is different to the one returned by the loca balance policy. So, in a round robin scenario, the client instance variable (which is accessed via getClient) would be changing constantly.
Synchronising getClient() could resolve the issue. Need to look more in depth. Seeing this, it is my intention to create a UT that tests thread safety as part of jbas-4455. It'd probably comment it when committing jbas-4455, so that it remains independent, and then resolve it when I fix that jira.
Another simple solution would be not to used the cached Client (like in jrmp). However, this could mean calling connect every time the Client is used. I need to look at Client in case this could be avoided by some isConnected() method.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092746#4092746
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092746
18 years, 7 months
[Design of EJB 3.0] - Re: Redesign extended persistence context
by bstansberry＠jboss.com
I just posted some prototype stuff related to getting Carlo's stuff to work well with clustering at https://svn.jboss.org/repos/jbossas/projects/ejb3/branches/cluster-dev/ej...
Carlo, here are some key points:
1) Cache has a couple methods added re: clustering support that we discussed this am. I made no changes yet based on our discussion.
2) PassivationManager has methods for replication callbacks.
3) PassivationGroup et al renamed SerializationGroup, since it's for both passivation and replication.
4) SerializationGroup has pretty significant API changes, mostly related to exposing stuff from the impl. I needed this so I could use the impl in my cache versions (see #6 below) without breaking your cache versions.
5) IdentityObjectStore. This is the key thing. Your SimplePassivatingCacheImpl has a hash map for an in-memory store, and then an inject edObjectStore for persistence. JBoss Cache combines the in-memory and persistent store. I need an abstraction that can handle that; this interface is that abstraction. SimpleIntegratedObjectStore is an impl of the interface that is suitable for use in a non-clustered cache. The o.j.e.test.distributed.MockJBCIntegratedObjectStore is a mock impl that behaves the way an interface to JBC would.
6) SimplePassivatingCache2/GroupedPassivatingCacheImpl2. Analogues to your classes, but using IntegratedObjectStore instead of ObjectStore. I tried to change your classes as little as possible.
7) New Cacheable interface. Exposes the inUse and lastUsed properties. Trying to get an analogue to your SimplePassivatingCache.Entry to work with the IntegratedObjectStore was proving to be a bridge too far. So I assumed the StatefulBeanContext would expose the Cacheable interface, allowing me to get rid of the need for a wrapper object like SimplePassivatingCache.Entry. SBC exposes the methods now and I assumed they were needed. We we're IMing today about the general "inUse" question, so that discussion impacts this.
8) Tests. Non-existent right now; hope to do at least a basic one this PM. Your tests still pass though.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092689#4092689
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092689
18 years, 7 months