11:16 p.m.
Hi,
we ware talking with Kabir about min/max-occurs that we have defined in many manually
written DescriptionProviders
They are supposed to be used to define constraints on on how many children resource can
have.
The problem we have with this is that there is no support for it when using
ResourceDefinition to define resources.
As we ware looking at adding it we found out that for us to do it properly support should
be added to ResourceDefinition
and ImmutableManagementResourceRegistration (IMRR) which makes it look bit odd especaly as
you would get min/max-occurs on resource
but it would actually apply to parent(you tell how may children resource can have and
child holds information about this)
so any way we look at it is bit odd and looks like it does not belong.
The issue was brought up as result of Jeff's conversion of messaging subsystem (which
is a great job btw) where resulting model
was missing min/max-occurs for children.
Question is do we even want to support this as currently there is no support for
validating and enforcing this constraints.
only thing we have is that some manually written model defines it.
If we add support for this on RD and IMRR we should probably add support for enforcing /
validating it.
Also we have figured out that when we converted subsystem we have lost this information.
Would it make sense to re-add it?
I would purpose to remove min/max-occurs all together as adding proper support for it at
this stage would be quite braking.
But it should be included from start in AS8. Support for it could be more easily and
properly added...
--
tomaz
11:40 a.m.
On 07/12/2012 11:16 PM, Tomaz Cerar wrote:
Question is do we even want to support this as currently there is no
support for validating and enforcing this constraints.
only thing we have is that some manually written model defines it.
If we add support for this on RD and IMRR we should probably add support for enforcing /
validating it.
Also we have figured out that when we converted subsystem we have lost this information.
Would it make sense to re-add it?
IMO we should add the min/max-occurs descriptions back. Even if it might
be too late to add proper validators, it still would fail during runtime
or result in some unexpected behavior. Perhaps mgmt clients can use it
as well and it end i see it as documentation of the intended purpose.
I haven't looked at the implementation in detail, but perhaps we can
even have some sensible defaults - that a wildcard address would default
to 0...n, otherwise to 0...1? This should be true for most of the cases
and we only need to change the ones where this does not apply.
Emanuel
12:27 p.m.
On 16 Jul 2012, at 10:40, Emanuel Muckenhuber wrote:
On 07/12/2012 11:16 PM, Tomaz Cerar wrote:
> Question is do we even want to support this as currently there is no support for
validating and enforcing this constraints.
> only thing we have is that some manually written model defines it.
> If we add support for this on RD and IMRR we should probably add support for
enforcing / validating it.
>
> Also we have figured out that when we converted subsystem we have lost this
information. Would it make sense to re-add it?
IMO we should add the min/max-occurs descriptions back. Even if it might
be too late to add proper validators, it still would fail during runtime
or result in some unexpected behavior. Perhaps mgmt clients can use it
as well and it end i see it as documentation of the intended purpose.
I haven't looked at the implementation in detail, but perhaps we can
even have some sensible defaults - that a wildcard address would default
to 0...n, otherwise to 0...1? This should be true for most of the cases
and we only need to change the ones where this does not apply.
That's a good point - this is more important for wildcards. When the children are
'predefined' for a type they are either there or not. I'm not sure if there is
anything to specify if a particular predefined child is optional or not though?
Emanuel
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
2:16 p.m.
On Mon, Jul 16, 2012 at 12:27 PM, Kabir Khan <kabir.khan(a)jboss.com> wrote:
On 16 Jul 2012, at 10:40, Emanuel Muckenhuber wrote:
>
> On 07/12/2012 11:16 PM, Tomaz Cerar wrote:
>> Question is do we even want to support this as currently there is no
support for validating and enforcing this constraints.
>> only thing we have is that some manually written model defines it.
>> If we add support for this on RD and IMRR we should probably add
support for enforcing / validating it.
>>
>> Also we have figured out that when we converted subsystem we have lost
this information. Would it make sense to re-add it?
>
> IMO we should add the min/max-occurs descriptions back. Even if it might
> be too late to add proper validators, it still would fail during runtime
> or result in some unexpected behavior. Perhaps mgmt clients can use it
> as well and it end i see it as documentation of the intended purpose.
>
> I haven't looked at the implementation in detail, but perhaps we can
> even have some sensible defaults - that a wildcard address would default
> to 0...n, otherwise to 0...1? This should be true for most of the cases
> and we only need to change the ones where this does not apply.
That's a good point - this is more important for wildcards. When the
children are 'predefined' for a type they are either there or not. I'm not
sure if there is anything to specify if a particular predefined child is
optional or not though?
We could easily add support for some sensible defaults but adding this
without
support for overriding it would create even more chaos.
For examples there are cases where you have wildcard definition (i.e
element=*) but it must always have 4 children, no more no less.
TBH this should be solved by different definition (i.e.
:element=value1,element=value2,..) but still definitions like this exists.
So we are back to how to sensible add this information RD/MRR?
--
tomaz
>
> Emanuel
> _______________________________________________
> 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
8:47 a.m.
I created https://issues.jboss.org/browse/AS7-5181 for tracking this.
On 07/16/2012 02:16 PM, Tomaž Cerar wrote:
On Mon, Jul 16, 2012 at 12:27 PM, Kabir Khan <kabir.khan(a)jboss.com
<mailto:kabir.khan@jboss.com>> wrote:
On 16 Jul 2012, at 10:40, Emanuel Muckenhuber wrote:
>
> On 07/12/2012 11:16 PM, Tomaz Cerar wrote:
>> Question is do we even want to support this as currently there
is no support for validating and enforcing this constraints.
>> only thing we have is that some manually written model defines it.
>> If we add support for this on RD and IMRR we should probably add
support for enforcing / validating it.
>>
>> Also we have figured out that when we converted subsystem we
have lost this information. Would it make sense to re-add it?
>
> IMO we should add the min/max-occurs descriptions back. Even if
it might
> be too late to add proper validators, it still would fail during
runtime
> or result in some unexpected behavior. Perhaps mgmt clients can
use it
> as well and it end i see it as documentation of the intended purpose.
>
> I haven't looked at the implementation in detail, but perhaps we can
> even have some sensible defaults - that a wildcard address would
default
> to 0...n, otherwise to 0...1? This should be true for most of the
cases
> and we only need to change the ones where this does not apply.
That's a good point - this is more important for wildcards. When the
children are 'predefined' for a type they are either there or not.
I'm not sure if there is anything to specify if a particular
predefined child is optional or not though?
We could easily add support for some sensible defaults but adding this
without support for overriding it would create even more chaos.
For examples there are cases where you have wildcard definition (i.e
element=*) but it must always have 4 children, no more no less.
TBH this should be solved by different definition (i.e.
:element=value1,element=value2,..) but still definitions like this exists.
So we are back to how to sensible add this information RD/MRR?
--
tomaz
>
> Emanuel
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4294
days inactive
4299
days old
4 comments
4 participants
participants (4)
-
Emanuel Muckenhuber -
Kabir Khan -
Tomaz Cerar -
Tomaž Cerar