[jboss-as7-dev] Definitely no subsystem support in the domain controller?

[Darran Lofthouse]

On 02/08/2011 06:24 AM, Brian Stansberry wrote:
> On 2/7/11 9:05 AM, Darran Lofthouse wrote:
>> Just want to double check one last time that there will be no support
>> for subsystems in the domain controller.
>>
>
> What I want to avoid is arbitrary configuration profiles on the domain
> controller/host controller. The configuration of the DC/HC should be
> limited to the things that need to be exposed, no more and no less.
>
>> For securing the management APIs the backing infrastructure that we
>> would need to be able to connect to is most likely already covered by
>> the login modules included within PicketBox.  The integration of this
>> with JBossAS 7 is also already working to provide a nicer schema when
>> defining a security domain.
>>
>> http://community.jboss.org/thread/154409?tstart=0
>>
>> If a schema already exists then the benefit of re-using it really means
>> that administrators only need to learn how to configure these modules
>> once rather than once for the management API and once for the actual
>> subsystems used by servers.
>>
>
> Sure, reusing schema makes sense. But within the context of an HC
> <management/>  config I don't see any requirement that the outer tag
> needs to be
>
> <subsystem xmlns="urn:jboss:domain:security:1.0">...</subsystem>

Yes, this is what I am thinking as well - if we are not going to 
actually have subsystems then just use the types from the schema that 
make sense in this context.

> It can just be<security>, or, if we decide it's important that the
> version of HC's security schema be configurable (I don't think that's
> necessary), then perhaps
>
> <security xmlns="urn:jboss:domain:security:1.0">...</security>

I think versioning makes sense even more so if we are re-using the 
types, if the security subsystem releases a later schema we will need to 
indicate at the management level which versions are supported and if we 
support multiple will need the same mechanism to identify which the user 
is using.

>> The first problem is that the existing parsing of the configuration will
>> be based around the detyped API and performing operations in the context
>> of a subsystem.  Secondly operations to operate on this configuration
>> will also be in that context.
>>
>> In the context of the domain controller configuration we could still
>> re-implement the parsing and operations without the dependency of a
>> server and the subsystem so at least the configuration appears the same
>> even if the integration with the server is different.
>>
>
> If we're smart, we should be able to get a lot of re-use. The existing
> subsystem code is purposefully oblivious as to where the subsystem
> resource sits in the overall management tree.

The part that I think we will need to look at further is that the 
subsystem initialisation reads the XML and converts this to a set of 
operations that make sense in the context of a server - we will need 
that to either work in the domain controller process or possibly just 
make some of the common areas available for re-use.

> If absolutely necessary, we can look at setting up a
> mini-server/ServerController inside the HostController process, and use
> it to manage a limited set of subsystems. But we need to think carefully
> before going down that road.
>
>> However the next issue that crops up using the PicketBox modules is the
>> dependence on things like JNDI and Datasources, probably not a massive
>> issue to solve but has there been any consideration yet regarding how to
>> manage datasources in the domain controller process?
>>
>
> We certainly don't want to run a JCA container in the HC just so
> PicketBox can talk to a DB. A simple connection pool seems adequate.

So for the DatabaseLoginModule we start we have a couple of additional 
items to look into - do we request that the DatabsaseLoginModule 
supports the plug in / override of the Datasource lookup code or do we 
provide a new implementation specifically for use in a domain controller.

This is definitely an advantage of not using fully qualified class names 
as we can now consider these options which will be transparent to the 
end user - for this I will start a PicketBox discussion.

>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>