January 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | ... | | I don't see what you are describing in the UnifiedClassLoader | | ... | | | | Or is this something in the URLClassLoader code? | No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described. This has been fixed: http://jira.jboss.com/jira/browse/JBMICROCONT-227 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122302#4122302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122302

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by alesj

"scott.stark(a)jboss.org" wrote : One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. | OK, I must admit I'm not entirely following the discussion. :-) But has this got to do something with this: | 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties | 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\deploy\jboss-seam-booking.ear\jboss-seam-booking.war\WEB-INF\lib\jboss-seam-debug.jar\seam.properties | 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear, relative: jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties | | 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties | 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties | 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties | I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs. Where does that 'jar:file' come from? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122298#4122298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122298

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | ... | I don't see what you are describing in the UnifiedClassLoader | ... | | Or is this something in the URLClassLoader code? No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122287#4122287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122287

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes? For importAll, they are matched in the old way. i.e. the order the classloader was added to the domain/repository. This is achieved by storing them in a list by package name they export. BaseClassLoaderDomain: | /** The classloaders by package name */ | private Map<String, List<ClassLoaderInformation>> classLoadersByPackageName = new ConcurrentHashMap<String, List<ClassLoaderInformation>>(); | For specific imports (delegation model) that are matched in the order the imports are "declared" (and depending upon the parent policy, i.e. before/after). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122284#4122284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122284

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by scott.stark＠jboss.org

Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122280#4122280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122280

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems. | | | | I don't see what you are describing in the UnifiedClassLoader | Or is this something in the URLClassLoader code? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122278#4122278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122278

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems. | I don't see what you are describing in the UnifiedClassLoader, but I do see a difference in the logic between the UnifiedLoaderRepository.getResource() | public URL getResource(String name, ClassLoader cl) | { | | ... | | // Not found in cache, ask the calling classloader | resource = getResourceFromClassLoader(name, cl); | | ... | | // Not visible in global cache, iterate on all classloaders | resource = getResourceFromRepository(name, cl); | and BaseClassLoaderDomain.getResource() | URL getResource(BaseClassLoader classLoader, String name, boolean allExports) | { | boolean trace = log.isTraceEnabled(); | | if (getClassLoaderSystem() == null) | throw new IllegalStateException("Domain is not registered with a classloader system: " + toLongString()); | | // Try the before attempt | URL result = beforeGetResource(name); | if (result != null) | return result; | | // Work out the rules | ClassLoaderInformation info = null; | BaseClassLoaderPolicy policy; | if (classLoader != null) | { | policy = classLoader.getPolicy(); | info = infos.get(classLoader); | if (policy.isImportAll()) | allExports = true; | } | | // Next we try the old "big ball of mud" model | if (allExports) | { | result = getResourceFromExports(classLoader, name, trace); | if (result != null) | return result; | } | else if (trace) | log.trace(this + " not getting resource " + name + " from all exports"); | | // Next we try the imports | if (info != null) | { | result = getResourceFromImports(info, name, trace); | if (result != null) | return result; | } | | // Finally use any requesting classloader | if (classLoader != null) | { | if (trace) | log.trace(this + " trying to get resource " + name + " from requesting " + classLoader); | result = classLoader.getResourceLocally(name); | if (result != null) | { | if (trace) | log.trace(this + " got resource from requesting " + classLoader + " " + result); | return result; | } | } | | // Try the after attempt | result = afterGetResource(name); | if (result != null) | return result; | | // Didn't find it | return null; | } | i..e. it doesn't do the look locally first before asking the parent or searching the repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122277#4122277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122277

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by scott.stark＠jboss.org

One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122271#4122271 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122271

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-structure help needed

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : | Scott, I understand that the custom application policies are not being found, hence it is defaulting to "other". But what I do not understand is from where is the DynamicLoginConfigService kicking in, for this test case? It is neither explicitly defined in this test deployment nor anything is done from the test case. | >From calleridentity-ds.xml | <local-tx-datasource> | <jndi-name>RunAsIdentityDS</jndi-name> | <connection-url>jdbc:hsqldb:mem:RunAsIdentityDB</connection-url> | <driver-class>org.hsqldb.jdbcDriver</driver-class> |  | <user-name>sa</user-name> | <password></password> | <security-domain-and-application>RunAsIdentityDSRealm</security-domain-and-application> | <metadata> | <type-mapping>Hypersonic SQL</type-mapping> | </metadata> | </local-tx-datasource> | | <mbean code="org.jboss.security.auth.login.DynamicLoginConfig" | name="jboss.security.tests:service=SecuritySpecLoginConfig"> | <attribute name="AuthConfig">login-config.xml</attribute> | <depends optional-attribute-name="LoginConfigService"> | jboss.security:service=XMLLoginConfig | </depends> | <depends optional-attribute-name="SecurityManagerService"> | jboss.security:service=JaasSecurityManager | </depends> | </mbean> | Which also contains a further known bug (FAQ), in that the security MBean is deployed after the datasource (they are deployed in file order). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122258#4122258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122258

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Data gravitation cleanup process and stale nodes

by bstansberry＠jboss.com

+1. As a JBC user, this isn't a big deal to me. I'd much rather have 2.1 be as stable as possible. Plus, more time to think about any downsides or reasons to make it configurable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122251#4122251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122251

18 years, 2 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 January 2008