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

[Security Development] - Re: PATCH (review before I commit) add stacking to LDAPExtLo

by anil.saldhana＠jboss.com

https://svn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/t... you can commit the patch. We will verify and back port. As always, thanks Andy. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268485#4268485 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268485

16 years, 1 month

1
0
0 / 0

[JBoss ESB Development] - Re: Schema Location

by Kevin.Conner＠jboss.com

That would be great, please do. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268483#4268483 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268483

16 years, 1 month

1
0
0 / 0

[JBoss ESB Development] - Re: Schema Location

by tomeicher

Thanks! Shall I file a JIRA for updating in the distribution, and for inclusion of a xsi:schemaLocation ? Cheers, Tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268482#4268482 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268482

16 years, 1 month

1
0
0 / 0

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

by kabir.khan＠jboss.com

I've had a look | public void testURLChildOfGlobalUcl() throws Exception | { | L globalLoader = testScenario.createLoader(new CLDeploymentBuilder("GLOBAL", JAR_A_1)); | L childALoader = createChildURLLoader(globalLoader, JAR_B_1); | | testScenario.loadClass(childALoader, globalLoader, CLASS_A); | testScenario.loadClass(childALoader, CLASS_B); | | L childBLoader = createChildURLLoader(globalLoader, JAR_A_2); | System.out.println("========> G" + globalLoader); | System.out.println("========> A " + childALoader); | System.out.println("========> B " + childBLoader); | testScenario.loadClass(childBLoader, globalLoader, CLASS_A); | } | The output shows G and A to always have a classloader, probably because the testScenario call maintains a strong reference to the loader? B sometimes is shown to have null loader, so createChildURLLoader needs to be reworked somehow to maintain a strong reference to the loader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268480#4268480 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268480

16 years, 1 month

1
0
0 / 0

[JBoss ESB Development] - Re: Schema Location

by Kevin.Conner＠jboss.com

Sorry about that, our repository URL was changed at some point and broke this. You should be able to find them by changing the prefix from http://anonsvn.labs.jboss.com/labs/ to http://anonsvn.jboss.org/repos/labs/labs/ Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268476#4268476 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268476

16 years, 1 month

1
0
0 / 0

[JBoss ESB Development] - Schema Location

by tomeicher

Hi, the jboss-esb.xml files in the examples all point to a svn URL as schema namespace: <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."> But that URL gives a HTTP 404 not found, when I call it. As far as I understand XML/XSD, that doesn't matter, it's just used as a string constant. But of course one would like to validate (and get editor support ;-)) when editing the XML files, so one would like to put a xsi:schemaLocation there. So, what would be the correct schema Location URL for any of the JBoss XSDs ? And wouldn't it make sense to put that also in the samples distributed with ESB ? Cheers, Tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268469#4268469 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268469

16 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

I think the difference is between implicit and explicit re-wiring of the bundle graph. The OSGi spec chooses the explicit approach where you have to explicitly use PackageAdmin or restart the framework to cause a rewiring. An implicit approach would mean that on every bundle update/uninstall the framework would bounce every bundle that depends on the uninstalled bundle causing a potential change in behaviour (because they wire to something else) Anyway, this is how the spec defines the classloading sematics of uninstalled bundles. Stale services can be avoided by using ServiceTracker i.e. you should never hold on to a service that is not being tracked. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268466#4268466 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268466

16 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by alesj

"thomas.diesler(a)jboss.com" wrote : | I realize that this behaviour may not be natural to MC, but it is how OSGi works AFAIU. | | After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well. | Both of these seem very un-natural to me. * class leakage? * stale services usage * ... Is there a valid reason to allow this? Does it say when the PackageAdmin::refresh needs to be invoked? (btw: why is PA even mentioned wrt core framework? shouldn't core be "self-enough") View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268462#4268462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268462

16 years, 1 month

1
0
0 / 0

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

by kabir.khan＠jboss.com

"alesj" wrote : | I guess you no | Well, this works too, but, as it's shows, it makes harder to test/debug tests. | I thought you would use VFS's Assembled notion. | Or is there a valid reason you didn't? | Not really, I wasn't familiar with that at the time "flavia" wrote : | Thanks for verifying that :-) | | Ales told me that the NPE is reproducible only under JDK5. Still, I have tested it with JDK5 and again couldn't see any failure. | Using JDK 5 I see this error: | Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.023 sec <<< FAILURE! | testURLChildOfGlobalUcl(org.jboss.test.classpool.jbosscl.test.RepositoryClassPoolTestCase) Time elapsed: 0.065 sec <<< ERROR! | java.lang.IllegalStateException: Illegal call. A class cannot be retrieved from ClassPool org.jboss.classpool.plugins.as.NonDelegatingClassPool@15141466 [class path: <null>:] - dcl:null because the corresponding ClassLoader is garbage collected | at org.jboss.classpool.base.BaseClassPool.get(BaseClassPool.java:130) | at org.jboss.test.classpool.support.ClassPoolTestScenario.assertLoadCtClassArray(ClassPoolTestScenario.java:173) | at org.jboss.test.classpool.support.ClassPoolTestScenario.assertLoadCtClassArray(ClassPoolTestScenario.java:163) | at org.jboss.test.classpool.support.ClassPoolTestScenario.assertLoadCtClass(ClassPoolTestScenario.java:155) | at org.jboss.test.classpool.support.ClassPoolTestScenario.loadClass(ClassPoolTestScenario.java:79) | at org.jboss.test.classpool.support.ClassPoolTestScenario.loadClass(ClassPoolTestScenario.java:44) | at org.jboss.test.classpool.jbosscl.test.RepositoryTest.testURLChildOfGlobalUcl(RepositoryTest.java:155) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268460#4268460 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268460

16 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

Bundle B may also use a BundleTracker to catch and react upon the state change of bundle X. This however would create a tight coupling between B and X, which you generally would like to avoid. After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268431#4268431 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268431

16 years, 1 month

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