[jboss-as7-dev] module mess Re: security APIs/SPIs really need a redesign

[David Bosschaert]

On 23/09/2011 14:55, Jason T. Greene wrote:
> On 9/23/11 8:44 AM, Bill Burke wrote:
>>
>> On 9/22/11 7:13 PM, David M. Lloyd wrote:
>>> On 09/22/2011 05:56 PM, Bill Burke wrote:
>>>> Also plugging in your own authentication mechanism in AS7 is crap too,
>>>> specially, modules are a mess.  Unless you fixed some things in the last
>>>> month.  But thats another conversation I want to have.
>>> Bring it ;)
>>>
>> I think I've already talked about it in the past.  If you want to extend
>> JBoss at all (i.e. a security plugin) you have to hack the modules/
>> directory so that classes are visible.  Since you've pretty much
>> isolated applications from app-server classloaders, I'll put $100 down
>> that this issue exists for other extension points as well.
> Yeah that is completely wrong.
>
> I'm doing some management related fixes to the security subsystem and I
> am going to add a module attribute similar to the way the other
> extensibility mechanisms work (module="org.foo.mymodule"
> class="blahplugin"). JDBC drivers are also allowed to be deployables and
> we could do something similar with security plugins, although that will
> require more involved changes to picketlink/box.
>
FYI the way OSGi does this is through the Service Registry. Services are 
typically registered under a common interface and more than 1 service 
instance per interface can exist (you can refine your lookup with 
additional properties).

The common interface is generally provided separately (e.g. as the SPI 
module/bundle) so consumers only need visibility of that. They don't 
need to have visibility to the implementation module/bundle.

Cheers,

David