[Design of JBoss Build System] - Re: Problem running tests in microcontainer/aop-mc-int
by adrian＠jboss.org
"pgier" wrote : I wasn't able to reproduce this locally. I did an svn update and a clean install of MC, and the tests ran fine (although there are a few test failures). I'm not sure why it can't find the surefire-report plugin for your build. You could try deleting just the surefire-report stuff from your local repo, and see if that helps.
|
Hmmm. Deleting all the surefire stuff from the local repostiory fixed that
issue, so I can run the tests, but now they are all failing.
A couple of hours ago I could run the tests with the plugin disabled???
I've been working on other projects since then so no svn updates or changes
(except possibly in the maven repository).
I'll try blowing away my entire local repository. That usually fixes these issues,
but it is very tiresome. Does maven use some kind of timestamp
and its getting confused about what it needs to download?
I know most of our checksums are broken in the repository so it can't use that. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133983#4133983
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133983
18 years, 1 month
[Design the new POJO MicroContainer] - Re: VFS serialization
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote : It depends what the VirtualFile reference means.
| It isn't valid in general, just as File handles aren't serializable,
| but (I think?) the VFS will try to reconstruct the path from what it knows for files.
|
| If it is deployed on the server side and references the file on the server
| rather than on the client (and they use different file systems), it doesn't mean anything.
| It's broken.
|
| If it sent a VFS file that used a webdav protocol that said
| "get your resources from this server"
| then that would be a different issue.
Yes, the VFS should be serializable, but as you say, its as usable as the underlying url. file urls won't be usable unless there is a shared filesystem between the client and server.
The current ws failures are due to JBVFS-17. The serialization of the NestedJarFromStream is broken, and what I'm currently working.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133980#4133980
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133980
18 years, 1 month
[Design of POJO Server] - Re: jndiName
by adrian＠jboss.org
"bytor99999" wrote :
| anonymous wrote : At least part of the problem is that you are passing the wrong deployment name here
|
| I haven't changed anything, where this did work before. So in passing the "wrong" deployment, I am not sure what I am missing, or what is now considered wrong. What would it need to be?
|
| Thanks guys
>From the error message (after the null problem)
you are just passing MarkDS-ds.xml as the deployment name
rather than vfsfile:/C:/JBossServers/jboss-5.0.0.CR1/server/default/deploy/MarkDS-ds.xml
(or whatever it is called) to the ManagedObject stuff.
| 21:47:32,843 WARN [ManagementViewImpl] Failed to create ManagedDeployment for: MarkDS-ds.xml
| org.jboss.deployers.spi.DeploymentException: Context MarkDS-ds.xml not found
| at org.jboss.deployers.plugins.main.MainDeployerImpl.getDeploymentContext(MainDeployerImpl.java:173)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeployment(MainDeployerImpl.java:650)
| at org.jboss.profileservice.management.ManagementViewImpl.loadProfile(ManagementViewImpl.java:186)
| ...
| at AOPProxy$1.loadProfile(AOPProxy$1.java)
| at org.rhq.plugins.jbossas5.factory.ProfileServiceFactory.refreshCurrentProfileView(ProfileServiceFactory.java:1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133975#4133975
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133975
18 years, 1 month
[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)
by kabir.khan＠jboss.com
"adrian(a)jboss.org" wrote : I also moved the GenericBeanFactoryMetaData2 into the spi and
| called it GenericBeanFactoryMetaData.
This seems broken/untested. There are some tests for unmarshalling, which work, but if you try to actually install the resulting beans into MC you get problems like (I've already worked through some of these):
| java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ClassCastException: org.jboss.beans.metadata.plugins.AbstractPropertyMetaD
| ata
| at org.jboss.aop.advice.AdviceFactory.create(AdviceFactory.java:110)
| at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:844)
| at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:1200)
| at org.jboss.aop.MethodMatchInfo.applyBinding(MethodMatchInfo.java:143)
| at org.jboss.aop.MethodMatchInfo.overridePopulateBindings(MethodMatchInfo.java:134)
| at org.jboss.aop.MethodMatchInfo.populateBindings(MethodMatchInfo.java:83)
| at org.jboss.aop.Advisor.finalizeMethodChain(Advisor.java:928)
| at org.jboss.aop.ClassContainer.createInterceptorChains(ClassContainer.java:268)
| at org.jboss.aop.ClassContainer.rebuildInterceptors(ClassContainer.java:128)
| at org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:64)
| at org.jboss.aop.proxy.container.ClassProxyContainer.initialise(ClassProxyContainer.java:173)
| at org.jboss.aop.proxy.container.ContainerCache.createContainer(ContainerCache.java:198)
| at org.jboss.aop.proxy.container.ContainerCache.createAndCacheContainer(ContainerCache.java:186)
| at org.jboss.aop.proxy.container.ContainerCache.initClassContainer(ContainerCache.java:159)
| 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:58)
| 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:327)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1316)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:574)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:398)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:336)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:306)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
| at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
| at org.jboss.test.aop.junit.JBossXBDeployer.deploy(JBossXBDeployer.java:133)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:289)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:433)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.deploy(AOPMicrocontainerTestDelegate.java:76)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.setUp(AOPMicrocontainerTestDelegate.java:60)
| at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: java.lang.RuntimeException: java.lang.ClassCastException: org.jboss.beans.metadata.plugins.AbstractPropertyMetaData
| at org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory.doCreate(GenericBeanAspectFactory.java:96)
| at org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory.createPerVM(GenericBeanAspectFactory.java:64)
| at org.jboss.aop.AspectManager.createPerVmAspect(AspectManager.java:1880)
| at org.jboss.aop.AspectManager.getPerVMAspect(AspectManager.java:1861)
| at org.jboss.aop.Domain.getPerVMAspect(Domain.java:770)
| at org.jboss.aop.Domain.getPerVMAspect(Domain.java:756)
| at org.jboss.aop.advice.PerVmAdvice.generateOptimized(PerVmAdvice.java:51)
| at org.jboss.aop.advice.AdviceFactory.create(AdviceFactory.java:106)
| ... 50 more
| Caused by: java.lang.ClassCastException: org.jboss.beans.metadata.plugins.AbstractPropertyMetaData
| at org.jboss.beans.metadata.plugins.factory.GenericBeanFactory.createBean(GenericBeanFactory.java:103)
| at org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory.doCreate(GenericBeanAspectFactory.java:92)
| ... 57 more
|
I can fix these, but just wanted to make sure there aren't any tests somewhere that I am not aware of
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133963#4133963
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133963
18 years, 1 month
[Design of JBossCache] - Re: NPE in InvalidationInterceptor.getNodeVersion()
by bstansberry＠jboss.com
It is. But JBC doesn't know anything about that.
As I think about the semantics of what Hibernate actually wants, not sure it wants a changing DataVersion at all. It has a DataVersion impl NonLockingDataVersion that never reports a version conflicts; that's what it uses by default. Only if it the underlying entity is versioned does it try to apply a real version to the node; there it wants to use the db version (which makes sense to me). Perhaps that can be dropped, and the non
There's 3 kinds of writes to the cache in the Hibernate entity caching case:
1) Write to cache as part of tx that creates a DB record.
2) Write to cache as part of tx that updates a DB record.
3) Insertion into cache of data that's read from DB.
#3 is the one that's most likely to result in trying to write stale data to the cache. But we already handle that by calling putForExternalRead, which will silently fail if the target node even exists. Version doesn't matter -- it just fails.
Issue then is more about conflicts related to #1/#2; most simply two concurrent #2 cases. I'll have to think more about whether there is any benefit to storing the version in the JBC node there; i.e. whether any conflicts would already be caught at the db level before the cache write is even attempted.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133957#4133957
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133957
18 years, 1 month