May 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543230#543230 -------------------------------------------------------------- > This is not done right, as you're not taking parent order into account. The way I did it now is also not done right, but it should do for simple domain hierarchy. I'll think about it some more on how to make it right. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543230#543230] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[jBPM Development] - JBPM-2859 disble autowire feature of RepositoryCacheBinding

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] created the discussion "JBPM-2859 disble autowire feature of RepositoryCacheBinding" To view the discussion, visit: http://community.jboss.org/message/543229#543229 -------------------------------------------------------------- Hi guys, I want to disable the autowire feature of RepositoryCacheBinding. So we could solve these issues. https://jira.jboss.org/browse/JBPM-2859 https://jira.jboss.org/browse/JBPM-2859 https://jira.jboss.org/browse/JBPM-2478 https://jira.jboss.org/browse/JBPM-2478 Actually, I cannot reproduce JBPM-2478, but I believe both of them could be solved by disable autowire of RepositoryCacheBinding. And I think we needn't set autowire=true for RepositoryCacheBinding. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543229#543229] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543228#543228 -------------------------------------------------------------- > I fixed the module tracking issue > // Add the modules that can resolve the requirement > *for* (Module aux : domain.getModules(null, *null*)) > { > // The wildcard policy should not load from this module > *if* (aux == module) > *continue*; > > // Add the module if it can resolve the requirement > *if* (aux.canResolve(requirement)) > modules.add(aux); > } > > > > > and the capability resolve issue. This is not done right, as you're not taking parent order into account. And the capability issue is a hack, hence it will be removed -- module needs a name. > 2010-05-15 08:31:19,327 WARN [org.jboss.detailed.classloader.ClassLoaderManager] Unexpected error during load of:org.jboss.test.osgi.classloader.support.a.A > java.lang.IllegalStateException: No classloader for this module OSGiModule dynamic-wildcard-c:0.0.0 > at org.jboss.classloading.spi.dependency.Module.getResource(Module.java:587) > at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.findModule(WildcardClassLoaderPolicy.java:113) > at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.getBaseClassLoader(WildcardClassLoaderPolicy.java:289) > at org.jboss.classloading.spi.dependency.policy.WildcardDelegateLoader.getBaseClassLoader(WildcardDelegateLoader.java:51) > at org.jboss.classloader.spi.base.BaseDelegateLoader.getPackage(BaseDelegateLoader.java:160) > at org.jboss.classloader.spi.filter.FilteredDelegateLoader.getPackage(FilteredDelegateLoader.java:173) > at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackageFromImports(BaseClassLoaderDomain.java:1014) > at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:590) > at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:1218) > at org.jboss.classloader.spi.base.BaseClassLoader.getPackage(BaseClassLoader.java:262) > at org.jboss.classloader.spi.base.BaseClassLoader.definePackage(BaseClassLoader.java:806) > at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:645) > at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:609) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:608) > at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585) > at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:138) > at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:461) > at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:262) > at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:161) > at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:262) > at org.jboss.osgi.framework.classloading.OSGiClassLoaderDomain.loadClass(OSGiClassLoaderDomain.java:55) > at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1164) > at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:883) > at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:505) > at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:450) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at org.jboss.osgi.framework.bundle.OSGiBundleState.loadClass(OSGiBundleState.java:145) > at org.jboss.osgi.framework.bundle.OSGiBundleWrapper.loadClass(OSGiBundleWrapper.java:171) > at org.jboss.osgi.testing.OSGiTestHelper.assertLoadClass(OSGiTestHelper.java:278) > at org.jboss.osgi.testing.OSGiTest.assertLoadClass(OSGiTest.java:213) > at org.jboss.osgi.testing.OSGiFrameworkTest.assertLoadClass(OSGiFrameworkTest.java:193) > at org.jboss.test.osgi.classloader.DynamicImportPackageTestCase.testAllPackagesWildcardNotWired(DynamicImportPackageTestCase.java:195) > > > This seems to be caused by an issue that the exporting bundle is not RESOLVED. The BaseClassLoaderDomain can find the resource, but when it comes to the actual load the module has no ClassLoader associated. In OSGi a call to Bundle.loadClass() triggers bundle resolution for the exporting module. > > How can we assure that the module transistions to CLASSLOADER stage after the resource was found, but before the class is loaded. Perhaps that should be done in WildcardClassLoaderPolicy when a resource is found in an unresolved module. I'll add an extra check whether the Module is actually capabale of loading the class. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543228#543228] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543227#543227 -------------------------------------------------------------- > AFAICS, the module tracking only works when the exporting module gets installed *after* the importing module has its policy setup.The WildcardClassLoaderPolicy should probably also scan allready existing modules when it is setup. More generally, perhaps a ModuleTracker that works simmilar to http://www.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html BundleTracker is needed. Yes, forgot about that, I'll add that, properly. > Even then, addModule > *public* *void* addModule(Module current) > { > Domain md = getDomain(current); > *if* (md != *null* && current.canResolve(requirement)) > { > ... > } > > > > > > will not add the exporting module because Module.canResolve(req) would not return 'true' for DynamicImport-Package: * Why is that? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543227#543227] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Thomas Diesler

Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543225#543225 -------------------------------------------------------------- I worked arround this issue by attempting to resolve all installed bundles on Bundle.loadClass() http://github.com/jbosgi/jbosgi-framework/commit/836b70511956b7d9e66bb780... http://github.com/jbosgi/jbosgi-framework/commit/836b70511956b7d9e66bb780... The general issue at the MC layer still remains -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543225#543225] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Thomas Diesler

Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543217#543217 -------------------------------------------------------------- I fixed the module tracking issue // Add the modules that can resolve the requirement for (Module aux : domain.getModules(null, null)) { // The wildcard policy should not load from this module if (aux == module) continue; // Add the module if it can resolve the requirement if (aux.canResolve(requirement)) modules.add(aux); } and the capability resolve issue. I now see 2010-05-15 08:31:19,327 WARN [org.jboss.detailed.classloader.ClassLoaderManager] Unexpected error during load of:org.jboss.test.osgi.classloader.support.a.A java.lang.IllegalStateException: No classloader for this module OSGiModule dynamic-wildcard-c:0.0.0 at org.jboss.classloading.spi.dependency.Module.getResource(Module.java:587) at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.findModule(WildcardClassLoaderPolicy.java:113) at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.getBaseClassLoader(WildcardClassLoaderPolicy.java:289) at org.jboss.classloading.spi.dependency.policy.WildcardDelegateLoader.getBaseClassLoader(WildcardDelegateLoader.java:51) at org.jboss.classloader.spi.base.BaseDelegateLoader.getPackage(BaseDelegateLoader.java:160) at org.jboss.classloader.spi.filter.FilteredDelegateLoader.getPackage(FilteredDelegateLoader.java:173) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackageFromImports(BaseClassLoaderDomain.java:1014) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:590) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:1218) at org.jboss.classloader.spi.base.BaseClassLoader.getPackage(BaseClassLoader.java:262) at org.jboss.classloader.spi.base.BaseClassLoader.definePackage(BaseClassLoader.java:806) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:645) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:609) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:608) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585) at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:138) at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:461) at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:262) at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:161) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:262) at org.jboss.osgi.framework.classloading.OSGiClassLoaderDomain.loadClass(OSGiClassLoaderDomain.java:55) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1164) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:883) at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:505) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:450) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.jboss.osgi.framework.bundle.OSGiBundleState.loadClass(OSGiBundleState.java:145) at org.jboss.osgi.framework.bundle.OSGiBundleWrapper.loadClass(OSGiBundleWrapper.java:171) at org.jboss.osgi.testing.OSGiTestHelper.assertLoadClass(OSGiTestHelper.java:278) at org.jboss.osgi.testing.OSGiTest.assertLoadClass(OSGiTest.java:213) at org.jboss.osgi.testing.OSGiFrameworkTest.assertLoadClass(OSGiFrameworkTest.java:193) at org.jboss.test.osgi.classloader.DynamicImportPackageTestCase.testAllPackagesWildcardNotWired(DynamicImportPackageTestCase.java:195) This seems to be caused by an issue that the exporting bundle is not RESOLVED. The BaseClassLoaderDomain can find the resource, but when it comes to the actual load the module has no ClassLoader associated. In OSGi a call to Bundle.loadClass() triggers bundle resolution for the exporting module. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543217#543217] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Thomas Diesler

Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/543214#543214 -------------------------------------------------------------- This approach causes these tests to fail Failed tests: testDynamicImportWithWildcard(org.jboss.test.osgi.core.jbosgi323.OSGi323TestCase) testAllPackagesWildcard(org.jboss.test.osgi.classloader.DynamicImportPackageTestCase) testAllPackagesWildcardNotWired(org.jboss.test.osgi.classloader.DynamicImportPackageTestCase) testPackageWildcardWired(org.jboss.test.osgi.classloader.DynamicImportPackageTestCase) testPackageWildcardNotWired(org.jboss.test.osgi.classloader.DynamicImportPackageTestCase) AFAICS, the module tracking only works when the exporting module gets installed *after* the importing module has its policy setup. The WildcardClassLoaderPolicy should probably also scan allready existing modules when it is setup. More generally, perhaps a ModuleTracker that works simmilar to http://www.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html BundleTracker is needed. Even then, addModule public void addModule(Module current) { Domain md = getDomain(current); if (md != null && current.canResolve(requirement)) { ... } will not add the exporting module because Module.canResolve(req) would not return 'true' for DynamicImport-Package: * -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543214#543214] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2856 delete sub process instance after it ends

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "JBPM-2856 delete sub process instance after it ends" To view the discussion, visit: http://community.jboss.org/message/543211#543211 -------------------------------------------------------------- Hi Maciej, Thank you for reviewing my patch. But I am not clear what you point to. In the signal() in SubProcessActivity, it has to get related subProcessInstance first, and cancel the bid-relationship between superProcessInstance and subProcessInstance, otherwise we can't delete subprocessInstance directly, Database will throw a FK related exception. Do you mean this? And you said 'deleteProcessInstance method of DBSession should take care of deleting remaining subprocess instances', do you mean that we needn't delete the sub processInstance after SubProcessActivity signaled, but could leave them alive until the end of superProcessInstance ended, so the deleteProcessInstance could delete them all? If you could show more details, it will be very appreciate. Thank you once again. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543211#543211] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JCA Development] - JcaXAResourceRecovery

by Jesper Pedersen

Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion "JcaXAResourceRecovery" To view the discussion, visit: http://community.jboss.org/message/543125#543125 -------------------------------------------------------------- A couple of additonal commits. * 104797: Remove support for "RecoverUser" and "RecoverPassword". Split the <security-domain> into two sub use-cases * 104799: Try to reconnect if mc.getXAResource() fails * 104802: Covered the unauthenticated security domain use-case -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543125#543125] Start a new discussion in JCA Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss XML Binding Development] - first stax performance test

by Alexey Loubyansky

Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion "first stax performance test" To view the discussion, visit: http://community.jboss.org/message/543119#543119 -------------------------------------------------------------- Here are the results of Woodstox evet readers vs stream readers (running the same tests as above against XB) || * * || *event readers* || *stream readers * || | first run (in ms) | 101.6 | 85.8 | | next 1000 runs (in ms) | 541.2 | 464.8 | And here is the average of 10 AS 6 trunk start-ups comparing Woodstox event readers against SAX: Woodstox: 18223.2 ms SAX: 19038.3 ms The results of the AS start-ups were very inconsistent. I.e. (I actually have booted the AS many more times) sometimes SAX would boot in 17 sec + something and Woodstox in 22 sec + something. But still on average the difference is probably close to the one above. When I was testing the start-up I was offline, no anti-virus or other heavy processes. It's on windows vista. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543119#543119] Start a new discussion in JBoss XML Binding Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2010