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

[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test

by ryan.campbell＠jboss.com

Looking at build.log seems better to me too. Let's not worry about the filenames as you suggest. But we should be sure that we don't fail the build if build.log is missing for some reason. We need to do a release of the jboss-test project and add that release into /trunk only. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119258#4119258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119258

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-224

by alesj

"adrian(a)jboss.org" wrote : I'd just change all the uses of the classloader.loadClass() to be Class.forName() | Even in the classloader module? - BaseClassLoaderDomain - ClassLoaderToLoaderAdapter View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119257#4119257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119257

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | Ok. It would probably be better to change isInRange() | to accept a comparator and configure it somewhere in the classloader | setup. | | But it's one of those N^2 problems in writing comparators between | all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc. | | Less pluggable (do we know what all the possible parameters will be?), | but probably easier to manage/configure would be to write | some kind of complicated Version concrete class that can handle all the different versions | and always map the other versions into it. | In between this would be to push the mapping into the comparator implementation. We have a Version implementation and register how to map VersionXImpl onto it in the comparator bean configuration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119195#4119195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119195

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | We do have an interface, | | ... | | There was a previous discuss on this problem. | | The issue is basically if we don't use the OSGi version then we have | | to come up with some complicated code that handles comparisons between | | the different implementations when doing compareTo(). | | ... | | Of course, its probably not a real problem in practice since it is unlikely that | | foo:1.0.0 uses a different version implementation to foo:1.0.1 or foo:2.0.0 :-) | VersionRange could accept a Comparator to allow for externalization of the Version compareTo. Ok. It would probably be better to change isInRange() to accept a comparator and configure it somewhere in the classloader setup. But it's one of those N^2 problems in writing comparators between all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc. Less pluggable (do we know what all the possible parameters will be?), but probably easier to manage/configure would be to write some kind of complicated Version concrete class that can handle all the different versions and always map the other versions into it. By all the different parameters, I mean some versions take major/minor/micro while others can take more numbers. Some do numeric checks while others do alpha numeric checks on parts of the version. e.g. is 1.0.1.Final less than 1.0.10.Beta3? The gotcha is . > 0 alpha numerically similarly 1.0.1.Final < 1.0.1.RC1 :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119189#4119189 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119189

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | I fixed the "default package" problem... | This is the cause of some of the security test failures as they are not finding "users.properties" resources. I would expect a fair number of the 250 extra failures are related to this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119185#4119185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119185

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | We do have an interface, | ... | There was a previous discuss on this problem. | The issue is basically if we don't use the OSGi version then we have | to come up with some complicated code that handles comparisons between | the different implementations when doing compareTo(). | ... | Of course, its probably not a real problem in practice since it is unlikely that | foo:1.0.0 uses a different version implementation to foo:1.0.1 or foo:2.0.0 :-) VersionRange could accept a Comparator to allow for externalization of the Version compareTo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119179#4119179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119179

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Naming Exception from Embedded

by adrian＠jboss.org

Looks like a dependency issue to me. Look at the location of this message: [url] [testng] DEBUG [org.jboss.jms.server.destination.TopicService] Creating jboss.mq.destination:service=Topic,name=testTopic [/url] compared to when the lookup occurs. The resource adapter will try to activate the MDB again 10 seconds after the failure: "reconnect=10" in the activation config. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119175#4119175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119175

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Release Embedded JBoss Beta3

by pete.muir＠jboss.org

Thanks to Scott, Clebert and Kabir we got past the JMS NPE. I'm still getting an exception from JMS http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119165#4119165 Even though the exception is thrown, JMS still seems to work correctly (tests pass). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119170#4119170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119170

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I think I know what the bug is with messaging. :-) | | The "export all" handling isn't picking up the default package, so the classloader | for jboss-messaging.jar isn't included in the index of classloaders to check | for Thread.currentThread().getContextClassLoader().getResource("VERSION"); | I fixed the "default package" problem, but it is still failing to deploy jms. Strangely, it doesn't always fail? But it does more often than not. Having looked at the code, I don't think this is a classloader issue unless it is a problem with the new aop integration that Kabir did i.e. it is not applying the correct advices. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119169#4119169 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119169

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Dimitris said we are pulling in the osgi jars just to use its version class. Can we move to our own compatible interface to avoid this? | We do have an interface, http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... but you still need an implementation. Currently, we use the OSGi version class as our implementation: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... There was a previous discuss on this problem. The issue is basically if we don't use the OSGi version then we have to come up with some complicated code that handles comparisons between the different implementations when doing compareTo(). http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... Of course, its probably not a real problem in practice since it is unlikely that foo:1.0.0 uses a different version implementation to foo:1.0.1 or foo:2.0.0 :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119166#4119166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119166

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