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

[Design the new POJO MicroContainer] - Re: Wrong dependency info after module uninstall

by adrian＠jboss.org

Two points. 1) Does the same problem exist in the new code? I don't understand your description about overriding a method with the same name. 2) Does IncompleteDeploymentException use the toHumanReadableString() method on the DependecyItem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130183#4130183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130183

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by timfox

More ideas: 1. Change a header on a message 2. Drop a user connection 3. Drop a single subscription. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130182#4130182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130182

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by timfox

Anything else anyone can think of? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130180#4130180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130180

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by timfox

A few initial comments: I would not provide overloaded methods which take a JBossDestination as well as others which take a destination name. A destination name should be sufficient. Other functionality we should have: 1) Delete a single message from a queue 2) Move a single message from one queue to another (e.g. to DLQ or expiry queue). 3) Expire a message 4) Change message priority View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130179#4130179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130179

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Wrong dependency info after module uninstall

by alesj

I've added UndeployOrderClassLoaderUnitTestCase that exposes the next problem (which Scott and me stumbled upon our OSGi demo at JBW): We have two modules, acme1.jar and acme2.jar. The number is the version of packages inside (org.jboss.acme.*). And we have foobar.jar that requires o.j.a.ales#1 (meaning it's from acme1.jar) and o.j.a.scott#2 (respectively from acme2.jar). And when I uninstall acme2.jar it does unwind foobar's deployment controller context back to Describe. But invoking DeployerClient.checkComplete produces IncompleteDeploymentException from foobar's added dependency on the acme2.jar instead of giving the right info about o.j.a.scott#2 requirement. We don't care about the module from where the pckg capabilities come from, so the info is misleading. Changing RequirementDependencyItem.unresolved to override the AbstractDependencyItem's similar method does the trick since it nullifies IDependOn, hence the info will come from toString which includes requirements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130156#4130156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130156

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven and url stream handlers

by pgier

Yes, it might be related to how the surefire plugin forks the tests. You can pass classpath elements to the forked tests, but they aren't passed directly to the jvm. A basic jvm is created, and then a new classloader is created to load whatever things you need for the test. Maybe I'm wrong, but this sounds similar to a problem that Stale was having with some aop tests, when trying to use the javaagent option. But the problem was that there isn't a way to pass the necessary classpath to the jvm. I will take a look this week and see if I can fix this and get a patch submitted to the surefire plugin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130134#4130134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130134

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoadING projects in MC trunk

by adrian＠jboss.org

Thread for classloading-vfs maven test issue http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130113#4130113 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130114#4130114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130114

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Maven and url stream handlers

by adrian＠jboss.org

Related to this thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130111#4130111 If you checkout the latest MC project and try to run the classloader-vfs tests it tells you can't create VFS files. This is because it doesn't recognise the vfsfile: protocol (even though it has been added to the system properties). This issue is specific to Maven, the tests work fine in the Eclipse. I tried to debug this before, but I couldn't work out the cause, because if I added a modified version of the URL class (with extra debugging) to the bootstrap classpath I couldn't reproduce the problem. The class from Sun's src.jar doesn't match what's in the JDK. ;-( I ended up hacking the test using reflection and setAccesible(true) to set the vfs url handler manually on the URL object. But I don't want to do that here, the construction of the VFS files are not in a test in this case, they are in real code. I'm guessing this has something to do with the way Maven is playing with the classloaders? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130113#4130113 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130113

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - New ClassLoadING projects in MC trunk

by adrian＠jboss.org

NEW PROJECTS I've added the refactored classloadING projects to the MC trunk. There are two projects, one is the basic infrastructure "classloading' the other is the VFS plugin, including the BeanMetaDataFactory that can be used to create an OSGi style classloader in a -beans.xml This api is mainly taken from the deployers-impl/vfs projects and made into a public spi with a lot more tests and a few more features. There's the old issue with the VFS not working properly in Maven for the classloading-vfs tests. I'll take this up in the build forum. What's left to do? TODO OSGi In terms of for OSGi this method sums up what is left in the resolution process org.jboss.classloading.spi.dependency.Domain | /** | * Resolve the requirement | * | * @param controller the controller | * @param module the module | * @param requirement the requirement | * @return the resolved name or null if not resolved | */ | protected Object resolve(Controller controller, Module module, Requirement requirement) | { | // TODO JBMICROCONT-182 include parent domains in requirements | // TODO JBMICROCONT-182 check consistency of re-exports | // TODO JBMICROCONT-182 check for self-dependency | // TODO JBMICROCONT-182 test circularity | for (Module other : modules) | { | List<Capability> capabilities = other.getCapabilities(); | if (capabilities != null) | { | for (Capability capability : capabilities) | { | if (capability.resolves(module, requirement)) | return other.getContextName(); | } | } | } | return null; | } | Basically instead of it resolving the capabilities based on list traversal over the modules and requirements, it needs to look at requirements in the round and try to resolve a consistent set for related classloaders. This includes classloaders from different domains. I pretty much know how to do this (there a few gotchas :-) but this only requires changes to implementation details. If you look at the code there's now support for re-exports and "uses" so the other remaining detail for OSGi are the dynamic imports. This may require a change to the ClassLoaderPolicy to make it work properly? TODO INTEGRATE WITH DEPLOYERS Going beyond OSGi, the next step is to plugin this work to the deployers. This should be fairly easy and the TopLevelClassLoaderDeployer should get a bit nicer. The only issue I can think are there a couple of places in the AS using the old private version of this api. These will obviously benefit from using a supported stable spi. TODO JBossAS RC1 After that, the remaining classloader issues are: * Use the classloader-vfs to modularise the AS bootstrap * Add the management requirements that Scott asked for * Sort out the WAR classloader properly, i.e. introduce proper support in the deployers for subdeployments having managed child classloaders of the main deployment classloader. Once these issues are resolved, all the classloading requirements for JBoss5 and OSGi will be done. Other classloading changes should be just value add. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130111#4130111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130111

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - WS-Security Usename Token Profile JAAS Implementation for JS

by thomas.diesler＠jboss.com

Karl de Boer sais: anonymous wrote : | I created a Username TokenProfile implementation where the userid pwd are verified against the active JAAS SecurityManager | I want to share this with you. | ... | Thanks Karl http://jira.jboss.org/jira/browse/JBWS-1999 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130107#4130107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130107

18 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 February 2008