2:35 p.m.
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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> 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