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

[Jason T. Greene]

On 9/23/11 9:05 AM, Bill Burke wrote:
>
>
> On 9/23/11 9:55 AM, 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.
>>
>
> Not sure I'm understanding.  So you're requiring users to configure that
> they want a specific module imported?
>

Yeah instead of mucking with our modules, which is bad for many reasons, 
they define their own and put it in the static modules dir. This is how, 
for example, the H2 jdbc driver is installed:

<driver name="h2" module="com.h2database.h2">
 
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>

This is the preferred mechanism for extensions/plugins that we ship with 
AS (We want all deployed deployments to always be the user's stuff). 
It's also the fastest since it's static.

However, defining a static module requires that you create a module.xml, 
and that you create the proper package like sub directories. It also 
means that the bits don't take advantage of the replicated content 
repository, and so the module, if it's installed on many nodes either 
need be done manually or via the patch infrastructure which is under 
development atm. So for users we recommend using the deployment based 
methodology for jdbc drivers, since it's easy (just deploy it and the 
config can refer to it), and if you are in domain mode the bits get 
replicated for you.

It seems like we need both for security plugins if we expect them to be 
commonly used/developed by users.

-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat