December 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : "flavia.rainone(a)jboss.com" wrote : that should return a class loaded by a BaseClassLoader, are returning a class loaded by the AppClassLoader. | This sounds like the issue we had before -- classes "leaking" into system cl, | where we should really only allow java.* packages through. The point is that the failures I mentioned are being seen on sanity test cases, i.e., with ClassLoaders, no ClassPool involved. "alesj" wrote : What's the "L loader" in TestScenario.cannotLoadClass(L loader, String className)? | Could be by-passing some rules? The L loader is just a generics abstraction for ClassLoaders and ClassPools, which allow me to write a test without being concerned whether it is going to be run against a ClassLoader or a ClassPool. The same test code is run with ClassLoaders (SanityTestCase) and with ClassPools (ClassPoolTestCase), thus enforcing that both behave the same way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269306#4269306 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269306

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - CL circularity failure

by alesj

My build server is complaining about this CL test: | DelegateUnitTestCase.testAbstractFactoryConcurrent | junit.framework.AssertionFailedError: Did not expect CNFE for org.jboss.test.classloader.delegate.support.b.TestFactoryImplementation from BaseClassLoader@a19b1de{B} | at org.jboss.test.AbstractTestCase.failure(AbstractTestCase.java:429) | at org.jboss.test.classloader.AbstractClassLoaderTest.assertLoadClass(AbstractClassLoaderTest.java:196) | Please wait... Show stacktrace ÃÂ» | ÃÂ« Hide stacktrace | junit.framework.AssertionFailedError: Did not expect CNFE for org.jboss.test.classloader.delegate.support.b.TestFactoryImplementation from BaseClassLoader@a19b1de{B} | at org.jboss.test.AbstractTestCase.failure(AbstractTestCase.java:429) | at org.jboss.test.classloader.AbstractClassLoaderTest.assertLoadClass(AbstractClassLoaderTest.java:196) | at org.jboss.test.classloader.AbstractClassLoaderTest.assertLoadClass(AbstractClassLoaderTest.java:173) | at org.jboss.test.classloader.AbstractClassLoaderTest.assertLoadClass(AbstractClassLoaderTest.java:158) | at org.jboss.test.classloader.delegate.test.DelegateUnitTestCase.access$100(DelegateUnitTestCase.java:56) | at org.jboss.test.classloader.delegate.test.DelegateUnitTestCase$2.run(DelegateUnitTestCase.java:301) | Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: org.jboss.test.classloader.delegate.support.b.TestFactoryImplementation, msg=org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation | at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:181) | at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265) | at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1124) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:856) | at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:499) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:444) | at java.lang.ClassLoader.loadClass(ClassLoader.java:252) | at org.jboss.test.classloader.AbstractClassLoaderTest.assertLoadClass(AbstractClassLoaderTest.java:191) | ... 4 more | Caused by: java.lang.ClassCircularityError: org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:621) | at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:66) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:627) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:586) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:562) | at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134) | at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131) | at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:455) | at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:267) | at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:166) | at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265) | at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1124) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:856) | at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:499) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:444) | at java.lang.ClassLoader.loadClass(ClassLoader.java:252) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:621) | at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:66) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:627) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:586) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:562) | at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134) | at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131) | at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:455) | at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:267) | at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:166) | ... 11 more | All other tests pass. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269297#4269297 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269297

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : that should return a class loaded by a BaseClassLoader, are returning a class loaded by the AppClassLoader. This sounds like the issue we had before -- classes "leaking" into system cl, where we should really only allow java.* packages through. What's the "L loader" in TestScenario.cannotLoadClass(L loader, String className)? Could be by-passing some rules? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269270#4269270 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269270

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Adding getAnnotationsAnnotatedWith() to MDR

by alesj

"kabir.khan(a)jboss.com" wrote : What I have so far has been committed against https://jira.jboss.org/jira/browse/JBREFLECT-82. | This was moved to MDR's JIRA. ;-) "kabir.khan(a)jboss.com" wrote : | I have not done anything about caching in CachingMetaDataContext or changed the SimpleCacheMetaDataContextUnitTestCase and SimpleCacheParentMetaDataContextUnitTestCase tests, which I guess work with CachingMetaDataContext? Thinking about your cache, this really belongs here -- into CachingMDContext. And I would impl it in the way I described it before -- full indexing. Since actually using CachingMDC full time is a complete overhead (we only use info at deploy/install time), you should just wrap non-caching MDR before you do your (meta) annotations check. This way meta cache will kick in almost transparently + it will be impled at the right level. Then adding the tests is a must. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269266#4269266 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269266

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Adding getAnnotationsAnnotatedWith() to MDR

by alesj

Perhaps this cache impl / feature belongs into out CachingMDContext? Or, if you already go over the annotations, you could build the entire cache then - indexing all existing annotations and its metadata annotations. So next time you ask for a meta annotation, you would already have the result. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269261#4269261 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269261

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: SHRINKWRAP-104: Empty Directories

by aslak

What if we drop the Asset all together and make a add method like: | archive.add(Path) | Maybe we then also have to support all the convenience overloads like ? | addManifestResource(Path) | addWebResource(Path) | etc.. | Path should then probably have a isDirectory method, checking if it ends with '/' seems to be common. Could add checks to other add methods so you can't add a Asset to a directory Path, can't get the Asset of a directory path etc.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269238#4269238 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269238

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - SHRINKWRAP-104: Empty Directories

by ALRubinger

https://jira.jboss.org/jira/browse/SHRINKWRAP-104 I've added support for empty directories (and tests) in r3836. This is nice, because importers can now account for empty dirs as well. The design I've used is a new Asset implementation: public enum DirectoryAsset implements Asset { | | /** | * Singleton Instance | */ | INSTANCE; | | /** | * {@inheritDoc} | * @see org.jboss.shrinkwrap.api.Asset#openStream() | */ | @Override | public InputStream openStream() | { | // To signify that we've got nothing to back us (we're just a directory), | // we use null. A stream backed by an empty byte array would be an | // empty file, which is different. | return null; | } | | } This sucks because: 1) We don't really obey the contract of "Asset", returning a null reference on "openStream" 2) The implementation relies upon "instanceof" runtime type checking to do things like creating directories in the exporter. Meaning we're checking for a specific implementation. An alternate approach is to add: Asset.isDirectory() ...to all Asset types. In this case "DirectoryAsset.openStream" would still return null, but we could do "Asset.isDirectory" instead of the runtime type checking. Which is uglier to you? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269221#4269221 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269221

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: SHRINKWRAP-97: Verbose toString format

by ALRubinger

"jaikiran" wrote : Just to be sure - we aren't talking about "empty" dirs, are we? Right; they're not "empty", just parents of directories which contain resources. Actually ShrinkWrap doesn't even support empty directories ATM. So: https://jira.jboss.org/jira/browse/SHRINKWRAP-104 "jaikiran" wrote : i do think it would be good to print the parents too (as Jesper suggests) since it would then match the output of the standard (jar utility) Thanks for the input. The more I think on this the more I think we need user options. I personally find the extra parent dirs a bit unnecessary/noisy in most cases. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269186#4269186 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269186

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: SHRINKWRAP-97: Verbose toString format

by jaikiran

"ALRubinger" wrote : | But I'd still like to understand the requirements/desire behind the request. Why the empty dirs? :) | | S, | ALR Just to be sure - we aren't talking about "empty" dirs, are we? From the example posted earlier in this thread, we are talking about "parent" dirs. Although i don't see an advantage as such, i do think it would be good to print the parents too (as Jesper suggests) since it would then match the output of the standard: jar -tf somejar.jar View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269185#4269185 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269185

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: SHRINKWRAP-97: Verbose toString format

by ALRubinger

"aslak" wrote : Having all these different versions of toString seems a bit odd to me. My example still has one overloaded toString; only instead of accepting a boolean is takes in an enum. I think the Visitor approach just moves the problem and makes it more complex. But I'd still like to understand the requirements/desire behind the request. Why the empty dirs? :) S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269179#4269179 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269179

16 years, 4 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 December 2009