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

[Brian Stansberry]

On 3/10/11 1:05 PM, Darran Lofthouse wrote:
> 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...
>

Sure; the plural is correct. My concern was more that we're calling 
something that's essentially a connector an "api". We use that term 
internally all the time and I think we all grok what it means. I'm just 
a bit concerned that end users (i.e. admins) won't grok it.

> 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.
>

OK, good. Just use a constant anywhere the "management-api(s)" string or 
variants thereof appear in java code so we can change the color of the 
bike shed if someone makes a good case for green.

I'm in no rush to get the new <management/> stuff into M2. Unless lots 
of stuff behind it is implemented. ;) Otherwise, it's a new chunk of 
schema that hasn't been through the ringer yet and is subject to change 
-- better to put it in trunk the day after the release than the day before.

>> (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
>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat