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

[Design of Security on JBoss] - Re: JBoss Negotiation - Onto The GA Release

by anil.saldhana＠jboss.com

Question is whether the ldap login module has usage outside of spnego usecases? The other thing is that 4.x security is frozen. So we are not adding any new features there. Since negotiation is a drop in use in 4.x and 5.x of AS, I think for the time being, the LM can stay in negotiation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194389#4194389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194389

17 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: JBoss Negotiation - Onto The GA Release

by darran.lofthouse＠jboss.com

I am happy to keep the login module in the negotiation project but the point is there is no real dependency either way both the negotiation authenticator and the login module are completely independent of each other but if you want to configure SPNEGO authentication with roles retrieved from LDAP then you would combine both together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194387#4194387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194387

17 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: JBoss Negotiation - Onto The GA Release

by anil.saldhana＠jboss.com

I do not see any issue in this 3rd ldap login module to reside in the negotiation project, because it has the direct dependence to it. There is no restriction on any LM to extend any of JBoss LMs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194382#4194382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194382

17 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - JBoss Negotiation - Onto The GA Release

by darran.lofthouse＠jboss.com

Apart from some small code areas to tidy up I have one area that still needs to be decided before we can release the first GA. The implementation of the login module requires an LDAP login module to be chained so that the LDAP login module can perform the roles search. Our existing login modules were not really up to the job for this so the JBoss Negotiation project now contains a new login module: - org.jboss.security.negotiation.AdvancedLdapLoginModule https://jira.jboss.org/jira/browse/SECURITY-133 This new login module no longer extends the 'UsernamePasswordLoginModule' as it was this design pattern that was making using this login module for just role searches difficult. The new login module is very similar to the 'LdapExtLoginModule', the roles search is subtly different from the 'LdapExtLoginModule' roles search but I could modify this to be compatible if needed. In addition to this the new login module can authenticate itself against LDAP using GSSAPI and a local keytab. The questions are: - Are we happy to have a third LDAP login module? Where should it live? Although the JBoss Negotiation project was the driving need for this module there is no reason for the module itself to be part of JBoss Negotiation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194376#4194376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194376

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by clebert.suconic＠jboss.com

"timfox" wrote : Assuming you meant it had to wait for the backlog of commands on the connection to be processed rather than completions, then a couple of observations. | | I notice you have sync on persistent set to true on server, but set to false on the connection factory. | | I'm not sure if that makes sense (it might cause backlogs), perhaps we should disallow that combination. What happens if you have sync on send set on the session factory too? On that case the test aways pass for me. The point is the backlogs. Maybe as I have the SCSI disk it has a slower sync? Lets talk about that later today on the IRC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194338#4194338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194338

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by olivierb

I have just created the same topic on the jboss esb forum ... any news about jboss esb artifacts on the public jboss maven repository ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194337#4194337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194337

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelDeploymentDeployer and annotations in MDR

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | The issue appears to be that for the plain deployment, | | we don't necessarily have the classloader from which we can | | create the annotations. e.g. | | | | | <deployment> | | | <classloader><inject name="BeanConstructedLaterOrInThisFile"></classloader> | | | <annotation>@from.that.Classloader</annotation> | | | </deployment> | | | | | | It could create a static MetaDataLoader if the class loader was not a bean or a bean that was available, otherwise how could a MetaDataLoader that was a bean be integrated into the deployment MetaData view? | | Yes that would be one possiblity. i.e. we create an artifical bean that is responsible for populating the annotations in the DEPLOYMENT scope. The other beans in the deployment would have to depend on it at the PRE_INSTALL stage so they can see the correct annotations. But that might create a circular dependency where the classloader for the deployment is a bean within the deployment. Normally we allow you to workaround the issue by adding <classloader><null/></classloader> (e.g. the VFS classloader stuff used in the bootstrap xml does this implicitly) to that bean so we could possibly use the same to indicate that it shouldn't wait for the deployment level annotations to get set up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194322#4194322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194322

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : ...and I've created one. It makes sure that the queue submit unblocks after the worker thread dies. The executor used in the test is basically a regular ThreadPoolExecutor with the same queue wrapper, except I wrap the wrapped queue again to add addtional blocking so that the queue unblocks right when the race would occur - when the worker thread from the first task exits leaving zero threads in the pool. | | http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-threads/trunk/ma... You can't test a race condition by blocking. Its a race condition because the thing is not threadsafe. At best, all you'll do is cause a deadlock in your test. ;-) The only way to test for a race condition is to stress test something that is likely to reproduce the problem (in this case it is very difficult because it requires starving a thread of cpu longer than its idle time :-) On your solution, I don't think it resolves the real issue? The issue is that the * offer to the queue * end previous runnable * add a thread are not synchronized with each other. i.e. there are gaps between the addWorker() check and the offer to the queue where the thread that addWorker() thinks exists gets ended due to idleness leaving the Runnable in limbo. Only a new call to addWorker() would recheck the active threads and spot that there's no threads to execute the runnable. So another workaround (besides the minimum of 1 threads) would be to introduce a periodic redo of the addWorker() check. Or put another way, whether you block in the queue.offer() or the rejection() won't make any real difference as you can see from the openjdk execute() code they are essentially in the same place | if (isRunning(c) && workQueue.offer(command)) { | int recheck = ctl.get(); | if (! isRunning(recheck) && remove(command)) | reject(command); | else if (workerCountOf(recheck) == 0) | addWorker(null, false); | } | else if (!addWorker(command, false)) | reject(command); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194297#4194297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194297

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by timfox

Another observation: Total Time: 680485 milliseconds what represented 1205 per second The calculation of the final figure is broken (1205), some times I get a -ve number! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194291#4194291 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194291

17 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-6188, track-connection-by-tx

by adrian＠jboss.org

AFAIK, the property is not used anymore (its deprecated because we don't throw an error if somebody configures it in the xml, we just ignore it) Instead there is an interleaving property that has the opposite semantics. This is to avoid the FAQ where people try to use an XA rar that hasn't been coded to support interleaving, but we used to enable it by default (now we don't). i.e. the old track-connection-by-tx behaviour is now the default for both local and xa but you can enable interleaving for XA. local transaction rars must always be interleaving=false, so we ignore interleaving=true for local as well. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194286#4194286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194286

17 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 2008