ExecutableDescriptor#getReturnValueDescriptor() and void methods
by Gunnar Morling
Hi all,
Currently the method ExecutableDescriptor#getReturnValueDescriptor()
returns null for methods which have no return value.
Alternatively we could return a descriptor, which has no constraints, is
not cascaded etc. and has an element class of void.class. This might allow
for a more regular processing without null checks when working with a
collection of executable descriptors.
Any thoughts?
Thanks,
--Gunnar
13 years, 1 month
Name for path nodes representing return values
by Gunnar Morling
Experts,
another issue where we need some feedback is BVAL-368, which is about the
name of path nodes representing return values.
As per the current draft, Node#getName() returns null in that case.
Question is, whether we should return something more meaningful, and if so,
which value.
The RI used to return "$retval" before we change this to match the spec.
Another obvious option would be "returnValue". Having a standardized node
name for return value nodes would also help with better toString()
implementations for j.v.Path (although that's not standardized).
Any thoughts?
Thanks,
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-368
13 years, 1 month
CDI interceptors and lifecycle
by Emmanuel Bernard
While reviewing the interceptor specification, I realized that
interceptors lifecycle is bound to the object lifecycle they intercept.
In other words, it is not trivial to keep caches around for example
caches that now if a method should be intercepted or not.
Is that a problem for the expected CDI interceptor implementations?
I am asking to make sure we are not making a mistake by not considering
@ValidateExecutable in BV engines.
An interceptor should either:
- explicitly be set only on the methods that should be intercepted and
not more
- always recompute @ValidatedExecutable for every new instance of the
targeted object
- use some third party CDI bean responsible for the caching
In other words are we good?
13 years, 1 month
TCK Beta3 (was: "Constraint given several times")
by Gunnar Morling
Hi,
As discussed with Hardy the test is updated now to expect two violations.
Btw. we released Beta3 of the TCK yesterday [1] (including this change). So
for those of you working on implementations of the spec it's the perfect
time to checkout tests new tests and let us know if any of the tests are
problematic etc.
We've basically assertions for all new functionality added in 1.1, with
~83% of these assertions already covered by tests (as measured with the
coverage tool [2]).
Speaking about tooling, the audit.xml file containing all the assertions is
generated now from the actual spec text using an XSL transformation. That
way wording and structure of the TCK match 100% with the spec, but this
change caused some re-arrangement of existing tests. This should have no
influence on implementations, the actual tests are the same as before.
--Gunnar
[1]
http://in.relation.to/Bloggers/InUnisonReleaseOfBeanValidationTCK110Beta3...
[2]
http://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_sin...
2013/2/6 Hardy Ferentschik <hardy(a)hibernate.org>
> Hi,
>
> >From a runtime perspective I can see how a single constraint violation
> can make sense as well.
> We have a single instance of Woman validating the Default group. I can see
> how only one violation
> makes sense. The problem is the metadata. It would not be defined which
> constraint meta data you
> would get when inspecting the constraint violation. The one from Citizen
> or the one from Person.
>
> I am wondering whether the group parameter contributes to constraint
> equality or whether it should be
> excluded.
>
> If there are no other objections I am ok with updating this behaviour and
> test, but I can see the merit in
> the current behaviour as well.
>
> --Hardy
>
>
> On 5 Jan 2013, at 4:42 PM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > Hi all,
> >
> > While working on a bug in the RI [1], I came across a TCK test which
> made me curious: ValidationRequirementTest#testClassLevelConstraints() [2].
> The test is based on the following types:
> >
> > @SecurityCheck(groups = { Default.class, TightSecurity.class })
> > public interface Citizen { ... }
> >
> > @SecurityCheck(groups = Default.class)
> > public abstract class Person implements Citizen { ... }
> >
> > public class Woman extends Person { ... }
> >
> > The test validates an instance of Woman which violates the
> @SecurityCheck constraint(s), but expects only one violation of the type
> @SecurityCheck.
> >
> > Since the constraint is given twice in the hierarchy (and with different
> member values), I'd have expected two violations here. I spoke to Emmanuel
> and we agree that the test seems wrong.
> >
> > The RI passes that test due to the bug mentioned above, but it'd be
> interesting to know how this is handled in the Apache implementation and
> why it's passing there.
> >
> > If no one objects, I'll adapt the TCK test to expect two @SecurityCheck
> violations.
> >
> > --Gunnar
> >
> > [1] https://hibernate.onjira.com/browse/HV-665
> > [2]
> https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr...
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
13 years, 1 month
Constraint given several times
by Gunnar Morling
Hi all,
While working on a bug in the RI [1], I came across a TCK test which made
me curious: ValidationRequirementTest#testClassLevelConstraints() [2]. The
test is based on the following types:
@SecurityCheck(groups = { Default.class, TightSecurity.class })
public interface Citizen { ... }
@SecurityCheck(groups = Default.class)
public abstract class Person implements Citizen { ... }
public class Woman extends Person { ... }
The test validates an instance of Woman which violates the @SecurityCheck
constraint(s), but expects only one violation of the type @SecurityCheck.
Since the constraint is given twice in the hierarchy (and with different
member values), I'd have expected two violations here. I spoke to Emmanuel
and we agree that the test seems wrong.
The RI passes that test due to the bug mentioned above, but it'd be
interesting to know how this is handled in the Apache implementation and
why it's passing there.
If no one objects, I'll adapt the TCK test to expect two @SecurityCheck
violations.
--Gunnar
[1] https://hibernate.onjira.com/browse/HV-665
[2]
https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr...
13 years, 1 month
Method constraints and TraversableResolver contract
by Gunnar Morling
Hi all,
working on the TCK, I'm wondering whether a BV provider should use
TraversableResolver#isReachable() and isCascadable()) to check whether a
validated method parameter or return value may be accessed/traversed.
I think checking for cascadability might make sense, but I'm not so sure
about checking for reachability; can e.g. be a parameter not reachable?
If any of the checks shall be done for method validation, we need to update
the TraversableResolver contract (section 4.6.3) which
currently explicitly speaks about properties and is limited to the element
types FIELD and METHOD.
WDYT?
--Gunnar
13 years, 1 month
Fwd: [jsr342-experts] Re: Priority of interceptors
by Emmanuel Bernard
Hello group,
I have been coordinating with the platform spec to give CDI interceptors for method validation a late priority. We had to build both the notion of priority and the notion of constructor interceptors.
Quickly read through this email which capture the result of the priority discussions. IMO the agreed proposal is good.
Emmanuel
Begin forwarded message:
> From: Linda DeMichiel <linda.demichiel(a)oracle.com>
> Date: 5 février 2013 03:48:30 UTC+01:00
> To: Emmanuel Bernard <emmanuel.bernard(a)jboss.com>
> Cc: Bill Shannon <bill.shannon(a)oracle.com>, Marina Vatkina <marina.vatkina(a)oracle.com>
> Subject: Fwd: [jsr342-experts] Re: Priority of interceptors
>
> Hi Emmanuel,
>
> Setting the priority for Bean Validation to PLATFORM_AFTER+800 is
> fine with me as well. This belongs in the Bean Validation spec, so
> please proceed with that.
>
> thanks,
>
> -Linda
>
>
> -------- Original Message --------
> Subject: [jsr342-experts] Re: Priority of interceptors
> Date: Mon, 04 Feb 2013 14:26:15 -0800
> From: Bill Shannon <bill.shannon(a)oracle.com>
> Reply-To: jsr342-experts(a)javaee-spec.java.net
> To: jsr342-experts(a)javaee-spec.java.net
> CC: Emmanuel Bernard <ebernard(a)redhat.com>, Paul Parkinson <paul.parkinson(a)oracle.com>, Marina Vatkina <marina.vatkina(a)oracle.com>
>
> Linda DeMichiel wrote on 02/04/13 11:53:
>> Feedback and questions regarding interceptor priority from
>> the Bean Validation spec lead. Please weigh in as appropriate
>>
>> thanks,
>>
>> -Linda
>>
>> On 2/4/2013 11:10 AM, Emmanuel Bernard wrote:
>>> (Linda, can you forward to the jsr342 list, I don't think I have write
>>> access).
>>>
>>> Thanks for this work.
>>>
>>>
>>> ## Question
>>>
>>> The spec claims:
>>>
>>>> An interceptor bound to a component using interceptor binding, may be enabled
>>>> for the entire applica- tion by applying the Priority annotation, along with
>>>> a priority value, on the interceptor class.
>>>
>>> Does that mean that without @Priority, the interceptor is not enabled
>>> for the entire application?
>
> Unless you enable it in beans.xml.
>
>>> And to clarify my doubts, you still enforce
>>> that the binding annotation must be present for the interceptor to be
>>> applied on a given method or class, correct?
>
> I believe that's still a requirement.
>
>>> ## Proposal
>>>
>>> Have you guys considered adding a END_OF_PLATFORM_AFTER = 5000 so that
>>> if for some reasons, people want to go after Java EE platform elements,
>>> they can do so.
>
> I suppose we could consider it.
>
>>> BTW, I think the spec should clarify that negative priority are accepted
>>> and that signed number ordering happen.
>
> We already decided to reserve negative numbers for a future use.
>
>>> ## Bean Validation priority
>>>
>>> If we go with that route (allocating 1000 to the platform_after
>>> section), I'm tempted to place Bean Validation priority to
>>> PLATFORM_AFTER+800.
>>>
>>> Why? Well:
>>>
>>> 1. it makes for a beautiful symmetry with JTA :)
>>> 2. and it reflects our opinion that BV should happen relatively late
>>> just like JTA should happen relatively early, but still offer an open
>>> door to override these propositions.
>
> Seems fine to me.
>
>>> Emmanuel
>>>
>>> On Thu 2013-01-31 11:22, Linda DeMichiel wrote:
>>>>
>>>> The revisions to the Interceptor spec to accommodate the improved
>>>> managed bean alignment are nearly complete. You can download the
>>>> current draft of the spec from the interceptor-spec.java.net project
>>>> at http://java.net/projects/interceptors-spec/downloads
>>>>
>>>> One of the issues that we still need to resolve, however, is the
>>>> assignment of priorities to the new transactional interceptors being
>>>> defined by JTA and the Bean Validation interceptors that handle
>>>> method validation.
>>>>
>>>> Section 5.5 of the Interceptors spec defines the following Priority
>>>> values (see the spec for the details):
>>>>
>>>> Interceptor.Priority.PLATFORM_BEFORE = 0
>>>> Interceptor.Priority.LIBRARY_BEFORE = 1000
>>>> Interceptor.Priority.APPLICATION = 2000
>>>> Interceptor.Priority.LIBRARY_AFTER = 3000
>>>> Interceptor.Priority.PLATFORM_AFTER = 4000
>>>>
>>>> In our earlier discussions, we concluded that transactional
>>>> interceptors needed to come relatively early in the interceptor chain.
>>>> To put a stake in the ground, we propose that we define these to have
>>>> a priority of Interceptor.Priority.PLATFORM_BEFORE+200.
>>>>
>>>> Validation interceptors, however, should come relatively late,
>>>> since they will ensure that the parameters that reach the method
>>>> (which might have been modified by other interceptors) are valid.
>>>> Again, to put a stake in the ground, we'll propose a priority of
>>>> Interceptor.Priority.PLATFORM_AFTER+1000.
>>>>
>>>> Comments please!
>>>>
>>>> Emmanuel, Paul, could you please consult with your expert groups
>>>> for further input as well...
>>>>
>>>> thanks,
>>>>
>>>> -Linda
>
13 years, 1 month