[jboss-as7-dev] Management API Security - Part 2 ;-)

[Darran Lofthouse]

Just to clarify it was "management-apis" that I was proposing not 
"management-api" - I don't mind either way but the reason I went for the 
plural form is because we also have "interfaces", "jvms", "servers" etc...

Secondly these outer elements wrap singular forms e.g. "interface", 
"jvm", "server".

Within the current "management" element we have two "*-api" elements so 
could have these sharing a common "management-api" type for common 
attributes e.g. "security-realm".

On 03/10/2011 05:42 PM, Brian Stansberry wrote:
> Is there a better term than "management-api"?  "API" doesn't feel right.
>
> "management-interface"
> "management-connection"
>
> Both are somewhat overloaded, since we have "interface" elsewhere and
> you are proposing<management><connections>  elsewhere.
>
> management-api is OK if we can't come up with a better name.
>
> Please plan on submitting a patch before M2 changing the existing schema
> and operation handling from<management>  to<management-???>. But we
> don't need to add all your new<management/>  stuff to the schema for M2.

If we are happy to go for this I am actually planning on submitting 
something tomorrow - once I have the top level "management" element 
'reserved' I can then start to get that populated next week.

> (The rest below is a tangent I explored then decided against; folks
> should ignore the rest unless they want to avoid going down the same
> thought path.)
>
> Can<management-api>  go inside management? I understand the logic for
> putting it outside (one is primarily domain.xml, the other is primarily
> host.xml), but if we're going to allow host-level overrides of the
> domain level stuff, that distinction breaks down. It also makes it easy
> to set up a default config that's used by all hosts.
>
> Reason to reject: doing this means a host may be unmanageable unless it
> can contact the master DC or is configured to boot off a
> "last-known-good" local copy of domain.xml. That's not acceptable.
>
> On 3/10/11 10:42 AM, Darran Lofthouse wrote:
>> Are there any comments regarding the configuration proposals here?
>>
>> Most specifically the reclaiming of the<management>   element and
>> replacing it with the<management-apis>   element?
>>
>> I would like to start getting some of this defined so will need to start
>> with the higher level elements first.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>> On 03/09/2011 01:30 PM, Darran Lofthouse wrote:
>>> Following on from the discussions this week please find below some
>>> updated articles: -
>>>
>>> This first article specified the mechanisms to be supported for the two
>>> transports: -
>>>       http://community.jboss.org/docs/DOC-16587
>>>
>>> The next article is a sample configuration to provide this: -
>>>       http://community.jboss.org/docs/DOC-16576
>>>
>>> DOC-16576 contains quite a bit of detail but the idea here is to provide
>>> (need a better word) components that either are the required callback
>>> handlers or components that supply the required callback handlers for
>>> SASL - the HTTP API will then also make use of these in the same way.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>