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>
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>
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.
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.
Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat