7:11 a.m.
Hi all,
I think it is time to wrap some of our latest discussion to be able to move on.
Let's start with ConfigurationSource. Hopefully you remember that we discussed
renaming it [1][2].
To make this more concrete I went ahead and already created a pull request for the API [3]
and the
spec [4].
I renamed ConfigurationSource to XMLConfiguration (as it already used to be called once)
and stated in the configuration that Configuration#getXMLConfiguration returns the
information
from META-INF/validation.xml. It also specifies that Configuration#getXMLConfiguration
never returns null,
but rather the corresponding getters will return null respectively the empty set or map.
Initially I thought about using DefaultConfiguration as an alternative name, but as
Emmanuel pointed out
in an earlier email it clashes to a certain degree with the programmatic Configuration
interface.
In the end I went back to XMLConfiguration especially after reading Gunnar's summary
around this issue:
{quote}
AFAICS the original idea behind ConfigurationSource was to provide a
way for BV integrators (e.g. CDI, or maybe an OSGi container etc.) to
access the stuff from the BV default configuration (validation.xml)
and make use of this when providing e.g. a validator in their specific
environment. E.g. CDI might provide a CDI-enabled validator using the
message interpolator from validation.xml. ConfigurationSource spares
such integrators from having to parse validation.xml on their own.
ConfigurationSource IMO shouldn't address any needs specific to an
integration technology. So if for instance OSGi wanted to configure
the constraint validator factory via the OSGi configuration service (a
standard configuration API there), they would have to do that in the
code integrating with BV (likely merging/delegating to the default
configuration retrieved via ConfigurationSource).
So the only scenario I can see where ConfigurationSource would
represent something other than validation.xml, would be a BV provider
which provides another means of default configuration.
{quote}
Regarding the last point, I don't see why for example Hibernate Validator should
choose
a different default configuration option than validation.xml. And if we would I would
consider
it a provider specific feature which does not have to be (indirectly) reflected in the
spec.
Thoughts?
--Hardy
Btw, Feel free to also comment on the pull requests as well. Hopefully we can come to
an agreement within the next couple of days.
[1] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-May/000389.html
[2] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-June/000390.html
[3] https://github.com/beanvalidation/beanvalidation-api/pull/10
[4] https://github.com/beanvalidation/beanvalidation-spec/pull/8
3:42 p.m.
Hi Hardy,
thanks for this great summary.
I renamed ConfigurationSource to XMLConfiguration
I've added some comments regarding the naming to the pull request. Summary:
* I think names should be based on semantics instead of technical
aspects. So the name should express what concept is modeled here and
not how it is realized. Therefore I'd prefer DefaultConfiguration
(because that's basically what this class is about, it represents the
BV default configuration provided by the user), or maybe something
like BootstrapConfiguration. The fact that the default configuration
is realized in form of an XML file, is not really relevant for the
user of this type, so it shouldn't shine through in the name IMO.
* Not having "XML" in the name leaves the door open for other
potential kinds of default configuration in the future. Although I
think we agree that this is not really likely, I'd still prefer to
enable such an evolvement without having to rename things then.
Regarding the last point, I don't see why for example Hibernate
Validator should choose a different default configuration option than validation.xml.
+1 I also don't see really a reason for that.
And if we would I would consider it a provider specific feature which
does not have to be (indirectly) reflected in the spec.
The thing is, if a BV provider would implement some other means of
default configuration via a provider-specific API, this would also
require BV integrators to know this API and to chose which kind of
default configuration to retrieve, the standard one or the
provider-specific one. Thinking about standardized integrators such as
CDI or JSF, this seems not really feasible.
So if we want to pave the way for other future kinds of default
configuration, this would have to be exposed via a standardized API,
that is, via Configuration#get<NAME_TBD>(). BV providers could then
return an implementation of the default configuration based on their
alternative configuration approach, without BV integrators having to
act any differently. I don't think that's likely, but leaving the door
open for this by using a somewhat more generic name seems like a good
trade-off to me.
Initially I thought about using DefaultConfiguration as an
alternative name, but as Emmanuel pointed out in an earlier email it clashes to a certain
degree with the programmatic Configuration interface.
But does it really clash? IMO Configuration provides a unified way for
accessing the effective configuration. It allows to change the
configuration in a programmatic way but it could also provide a handle
to the default configuration from validation.xml via
getDefaultConfiguration().
I see there is a clash with getDefaultMessageInterpolator() etc,
though (which returns the default implementations as demanded by the
spec.), so maybe the method returning the user provided default
configuration should be named getExternalDefaultConfiguration(),
getBootstrapDefaultConfiguration() or similar.
--Gunnar
2012/7/16 Hardy Ferentschik <hardy(a)hibernate.org>:
Hi all,
I think it is time to wrap some of our latest discussion to be able to move on.
Let's start with ConfigurationSource. Hopefully you remember that we discussed
renaming it [1][2].
To make this more concrete I went ahead and already created a pull request for the API
[3] and the
spec [4].
I renamed ConfigurationSource to XMLConfiguration (as it already used to be called once)
and stated in the configuration that Configuration#getXMLConfiguration returns the
information
from META-INF/validation.xml. It also specifies that Configuration#getXMLConfiguration
never returns null,
but rather the corresponding getters will return null respectively the empty set or map.
Initially I thought about using DefaultConfiguration as an alternative name, but as
Emmanuel pointed out
in an earlier email it clashes to a certain degree with the programmatic Configuration
interface.
In the end I went back to XMLConfiguration especially after reading Gunnar's summary
around this issue:
{quote}
AFAICS the original idea behind ConfigurationSource was to provide a
way for BV integrators (e.g. CDI, or maybe an OSGi container etc.) to
access the stuff from the BV default configuration (validation.xml)
and make use of this when providing e.g. a validator in their specific
environment. E.g. CDI might provide a CDI-enabled validator using the
message interpolator from validation.xml. ConfigurationSource spares
such integrators from having to parse validation.xml on their own.
ConfigurationSource IMO shouldn't address any needs specific to an
integration technology. So if for instance OSGi wanted to configure
the constraint validator factory via the OSGi configuration service (a
standard configuration API there), they would have to do that in the
code integrating with BV (likely merging/delegating to the default
configuration retrieved via ConfigurationSource).
So the only scenario I can see where ConfigurationSource would
represent something other than validation.xml, would be a BV provider
which provides another means of default configuration.
{quote}
Regarding the last point, I don't see why for example Hibernate Validator should
choose
a different default configuration option than validation.xml. And if we would I would
consider
it a provider specific feature which does not have to be (indirectly) reflected in the
spec.
Thoughts?
--Hardy
Btw, Feel free to also comment on the pull requests as well. Hopefully we can come to
an agreement within the next couple of days.
[1] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-May/000389.html
[2] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-June/000390.html
[3] https://github.com/beanvalidation/beanvalidation-api/pull/10
[4] https://github.com/beanvalidation/beanvalidation-spec/pull/8
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:31 a.m.
On Jul 17, 2012, at 10:42 PM, Gunnar Morling wrote:
> Initially I thought about using DefaultConfiguration as an
alternative name, but as Emmanuel pointed out in an earlier email it clashes to a certain
degree with the programmatic Configuration interface.
But does it really clash? IMO Configuration provides a unified way for
accessing the effective configuration. It allows to change the
configuration in a programmatic way but it could also provide a handle
to the default configuration from validation.xml via
getDefaultConfiguration().
I see there is a clash with getDefaultMessageInterpolator() etc,
though (which returns the default implementations as demanded by the
spec.), so maybe the method returning the user provided default
configuration should be named getExternalDefaultConfiguration(),
getBootstrapDefaultConfiguration() or similar.
That's exactly the clash I am talking about. If we call it _DefaultConfiguration_ and
just call the getter
Configuration#getDefaultConfiguration we have for example
Configuration#getDefaultMessageInterpolator, but
also Configuration#getDefaultConfiguration()#getMessageInterpolatorClassName. IMO that can
be misleading.
One way to avoid this would be to call the accessor #getExternalDefaultConfiguration() or
#getBootstrapDefaultConfiguration()
as you suggest, but then I rather call it BootstrapConfiguration to begin with.
I chose XMLConfiguration, because I think it is ok to limit this method to validation.xml.
If we really want to keep
"doors open" I could imagine renaming to BootstrapConfiguration.
What do others think?
--Hardy
2:14 a.m.
Am 18.07.2012 11:32 schrieb "Hardy Ferentschik" <hardy(a)hibernate.org>:
> But does it really clash? IMO
Configuration provides a unified way for
> accessing the effective configuration. It allows to change the
> configuration in a programmatic way but it could also provide a handle
> to the default configuration from validation.xml via
> getDefaultConfiguration().
> I see there is a clash with
getDefaultMessageInterpolator() etc,
> though (which returns the default implementations as demanded by the
> spec.), so maybe the method returning the user provided default
> configuration should be named getExternalDefaultConfiguration(),
> getBootstrapDefaultConfiguration() or similar.
That's exactly the clash I am talking about. If we call it
_DefaultConfiguration_ and just call the getter
Works both for me.
> What do others think?
Yepp, please speak up guys :) Let's bring this to an end.
> --Hardy
--Gunnar
On Jul 17, 2012, at 10:42 PM, Gunnar Morling wrote:
>> Initially I thought about using DefaultConfiguration as an alternative
name, but as Emmanuel pointed out in an earlier email it clashes to a
certain degree with the programmatic Configuration interface.
Configuration#getDefaultConfiguration we have for example
Configuration#getDefaultMessageInterpolator, but
also
Configuration#getDefaultConfiguration()#getMessageInterpolatorClassName.
IMO that can be misleading.
I see, yes that's definitely sub-optimal.
One way to avoid this would be to call the accessor
#getExternalDefaultConfiguration() or #getBootstrapDefaultConfiguration()
as you suggest, but then I rather call it BootstrapConfiguration to
begin
with.
I chose XMLConfiguration, because I think it is ok to limit this
method
to validation.xml. If we really want to keep
"doors open" I could imagine renaming to
BootstrapConfiguration.
+1 Personally, for me the “naming things by semantics“ argument is even
more important than leaving doors open. We would just get the latter for
free by following the former.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:56 a.m.
On Jul 23, 2012, at 9:14 AM, Gunnar Morling wrote:
> One way to avoid this would be to call the accessor
#getExternalDefaultConfiguration() or #getBootstrapDefaultConfiguration()
> as you suggest, but then I rather call it BootstrapConfiguration to begin with.
>
Works both for me.
I did a rename from XMLConfiguration to BootstrapConfiguration. At least Gunnar and I seem
to be able to agree on this.
Unless there are no other objections we will push this to master asap.
--Hardy
4:04 p.m.
Hi all,
fyi, I've just applied the renaming to BootstrapConfiguration [1].
It's also BootstrapConfiguration#getConstraintMappingResourcePath*s*()
instead of getConstraintMappingResourcePath() now and
Configuration#getBootstrapConfiguration() is defined to never return
null (BoostrapConfiguration's getters will return null in case
validation.xml doesn't exist).
--Gunnar
[1] https://github.com/beanvalidation/beanvalidation-api/pull/10
2012/7/23 Hardy Ferentschik <hardy(a)hibernate.org>:
On Jul 23, 2012, at 9:14 AM, Gunnar Morling wrote:
> > One way to avoid this would be to call the accessor
#getExternalDefaultConfiguration() or #getBootstrapDefaultConfiguration()
> > as you suggest, but then I rather call it BootstrapConfiguration to begin with.
> >
>
> Works both for me.
I did a rename from XMLConfiguration to BootstrapConfiguration. At least Gunnar and I
seem to be able to agree on this.
Unless there are no other objections we will push this to master asap.
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4539
days inactive
4547
days old
beanvalidation-dev@lists.jboss.org
5 comments
2 participants
participants (2)
-
Gunnar Morling -
Hardy Ferentschik