[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
[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
[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