May 2010 - jboss-user - Jboss List Archives

Re: [jboss-user] [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-user] [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-user] [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-user] [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-user] [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-user] [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-user] [Spring Integration] - @Autowiring of beans from Spring applicationcontext

by Vladimir Aguirre

Vladimir Aguirre [http://community.jboss.org/people/vlad_pax] replied to the discussion "@Autowiring of beans from Spring applicationcontext" To view the discussion, visit: http://community.jboss.org/message/543213#543213 -------------------------------------------------------------- Hi Marius: Thank you, very nice. I'm test with the next configuration: beanRefContext.xml File: <bean id="context" class="org.jboss.spring.vfs.context.*VFSClassPathXmlApplicationContext*"> <constructor-arg index="1"> <list value-type="java.lang.String" > <value>applicationContext-log4j.xml</value> <value>applicationContext-service.xml</value> <value>sessionFactory-sc-context.xml</value> <value>dataSource-sc-context.xml</value> </list> </constructor-arg> <constructor-arg index="2" type="boolean"> <value>false</value> </constructor-arg> </bean> I have the next error: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'context' defined in URL [vfs:/D:/Java/AppsServers/Jboss/jboss-6.0.0.20100429-M3/server/default/deploy/armonica-ear-1.0-SNAPSHOT.ear/APP-INF/lib/armonica-negocio-1.0-SNAPSHOT.jar/beanRefContext.xml]: 2 constructor arguments specified but no matching constructor found in bean 'context' (hint: specify index and/or type arguments for simple parameters to avoid type ambiguities) org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:181) I will test with Jboss 5, but tomorrow. +Muchas gracias mi hermano.+ -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543213#543213] Start a new discussion in Spring Integration at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [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-user] [jBPM] - [JBPM 4] Process variable

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "[JBPM 4] Process variable" To view the discussion, visit: http://community.jboss.org/message/543210#543210 -------------------------------------------------------------- Hi Dan, If you want to add a new persistence class to hibernate. you have to add it to the jbpm.execution.hbm.xml. Like this: <subclass name="org.jbpm.pvm.internal.type.variable.BlobVariable" extends="org.jbpm.pvm.internal.type.Variable" discriminator-value="blob"> <many-to-one name="lob" column="LOB_" cascade="all" foreign-key="FK_VAR_LOB" index="IDX_VAR_LOB" /> </subclass> Then hibernate could know to deal with your custom class type. Then jbpm.variable.types.xml is used to convert different variable value to the related class type. and the jbpm.execution.hbm.xml is used to tell hibernate how to store these instances. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543210#543210] Start a new discussion in jBPM 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-user May 2010