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

[Darran Lofthouse]

On 03/10/2011 08:35 PM, Brian Stansberry wrote:
> 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.

I know what you mean, an 'Application Programming Interface' is not 
really something an administrator would automatically expect - they want 
to connect to it but not necessarily program against 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"

Thinking about it is <management-interface> that overloaded?  We use it 
elsewhere to specify network interfaces, the element we are talking 
about here is making the management accessible over a network interface. 
  It is also the same as API with the A and the P removed ;-)

Alternatively, JBoss Web has "connectors" - Messaging seems to have 
"connectors" and "acceptors".  Once Remoting 3 is integrated what word 
will be used there to define the server side of the connection?

One point if we choose something different to management-api it would 
probably also make sense to move the <http-api> and <native-api> 
elements to the same so no reference to 'api' at all.

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

Also this will be a single commit so will be easier to track everything 
that was changed for the rename.

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

Agreed, my first priority is getting the <management> element moved so I 
am free to work on it but I don't need the new element in master until 
it actually does something.

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