[Design the new POJO MicroContainer] - Re: Anonymous beans
by bstansberry@jboss.com
There's a problem with the way the anonymous bean impl (NestedBeanHandler I think) is generating names. Looks like it's getting confused about where it is in the nested bean hierarchy and ends up trying to apply the same name to multiple beans.
The -beans.xml I'm trying to deploy can be found at https://svn.jboss.org/repos/jbossas/trunk/cluster/src/etc/jboss-cache-man... . When I try to deploy it in AS trunk I get this:
| 2008-04-10 22:45:20,150 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Real: name=vfsfile:/home/bes/dev/jboss/trunk/build/output/jboss-5.0.0.CR1/server/all/deploy/cluster/jboss-cache-manager-beans.xml state=PreReal mode=Manual requiredState=Real
| org.jboss.deployers.spi.DeploymentException: Error deploying: CacheConfigurationRegistry$runtimeConfig
| at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:92)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:46)
| 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:174)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:991)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:674)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:456)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:259)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:137)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:544)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.IllegalStateException: CacheConfigurationRegistry$runtimeConfig is already installed.
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:577)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88)
| ... 22 more
|
Note that the runtimeConfig property is not an immediate child of the CacheConfigurationRegistry bean. It's a property of "StandardSessionCacheConfig" and "FieldSessionCacheConfig".
To add to the challenge, "StandardSessionCacheConfig" and "FieldSessionCacheConfig" really can be anonymous. I just gave them names for human readability. So any solution should work even if they were anonymous.
BTW, what I'm trying to do in the part of this file that uses anonymous beans is parse XML to create a set of JBoss Cache configurations. JBC has its own XML format and parser that I can use to accomplish this. It didn't have system property substitution, but I added that earlier this week. So I can use that. I'd prefer to use MC to do this. But don't let me totally rearrange your schedule; I have a workaround.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143341#4143341
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143341
17 years, 12 months
[Design of POJO Server] - LogConfigurationException from commons-logging
by bstansberry@jboss.com
I've been seeing this kind of thing quite a bit in logs from testsuite runs; seems to correspond to intermittent increase in clustering failures:
| 2008-04-10 13:58:28,949 ERROR [org.jboss.cache.remoting.jgroups.CacheMessageListener] (Multiplexer,udp,10.18.34.175:51700) Caught org.apache.commons.logging.LogConfigurationException while responding to state transfer request
| org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
| at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:798)
| at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
| at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
| at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664)
| at org.jboss.cache.statetransfer.DefaultStateTransferGenerator.<init>(DefaultStateTransferGenerator.java:32)
| at org.jboss.cache.statetransfer.StateTransferFactory.getStateTransferGenerator(StateTransferFactory.java:43)
| at org.jboss.cache.statetransfer.StateTransferManager.getStateTransferGenerator(StateTransferManager.java:297)
| at org.jboss.cache.statetransfer.StateTransferManager.getState(StateTransferManager.java:82)
| at org.jboss.cache.remoting.jgroups.CacheMessageListener.getState(CacheMessageListener.java:137)
| at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:629)
| at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:747)
| at org.jgroups.JChannel.up(JChannel.java:1154)
| at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1175)
| at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1198)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
|
I'm going to turn on commons-logging's diagnostic logging feature for the cluster-udp-0 and cluster-udp-1 configs; hopefully that will shed some light on what's causing this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143331#4143331
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143331
17 years, 12 months