[
https://issues.apache.org/jira/browse/BVAL-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257044#comment-17257044
]
Gerhard Petracek commented on BVAL-184:
---------------------------------------
i had a discussion with romain, but we couldn't find an agreement (for now) on
some details.
i just could provide the "use-cases" in a quite general manner
(like easier validation of techn. contexts, validation of "config-graphs"
using injected config-values as well as better support for business-injection
which i don't use but i saw several requests for it over the years),
but at this point i'm not allowed to share more concrete use-case-demos easily
(besides the minimal techn. demos/tests which don't cover a specific use-case
itself). however, i'll try to provide some within the next weeks.
an important point which wasn't mentioned explicitly is:
it isn't just about the root-bean, it's mainly about the support of
@Valid (in proxied beans).
—
the following part isn't for continuing the discussion.
it's just the summary of the discussion/s we had so far (just for the records).
@"not guaranteed to work":
in case of proxies in general that's correct (i never said something
different), however,
in case proxies support it (like owb- and weld-proxies), it's possible to
support it.
the goal is *not* to support any proxy-impl. out there...
if something is missing (e.g. in the resolver for owb), we can just improve it
(as i did already btw.).
@"it is expected to not work"
users ask for it since 2009 (not at bval directly but you can find such
questions e.g. at hval and i also get it from time to time).
however, at this point we can support it at least for cdi (via such a spi).
if a diff. di-container doesn't provide proxy-subclasses which support it,
nothing changed for them.
however, lib-implementations which are part of (jakarta)-ee always integrated
as much as possible (even the integration wasn't supported for external libs).
one of many examples is TraversableResolver which is even part of bv itself
(mainly for jpa), but that doesn't mean that all orm-frameworks can/will
support it.
moreover, ee-servers often provide additional integration which isn't defined
by the spec. (at least not in the beginning).
imo it makes no sense (that it isn't expected to work) since proxies are an
implementation detail and the spec. defines bv-annotations also for fields (the
spi is just an optional way to bypass a techn. limitation).
@"antipattern":
i don't agree with that, because with that argument you need to restrict
bv-annotations on getter-methods in case of proxy-instances as well (but they
work).
that you prefer a different style (as i do btw.), is a different topic,
however, there are also other opinions and some quite special use-cases out
there.
+ if proxies are used due to a refactoring
(e.g. adding an interceptor to @Dependent beans)
it could even be the case that the behaviour (in context of bv) changes just
because the cdi-container creates the proxy (to support the interceptors)...
if interceptors are "hidden" e.g. in a @Stereotype or added dynamically by a
cdi-extension (during bootstrapping), it's really hard for users to see/find
the issue.
(for them nothing obvious changed...)
@"global chain resolver":
it isn't needed imo – per default you have 0 resolvers and users (/servers)
who would like to use/support it can do it easily – so you have just 1.
(usually).
+ if you would like to provide one for your own proxies, you have at least the
option to do it...
therefore most might use 0, several would use 1 and only very few would use 2
(or more).
since a resolver just needs to return something in case it did something, the
order is not that important (since you have 1 resolver
per "proxy-(interface)-type").
once it is important, you can even influence the ordering
(it's at least always the same order per default).
@"cglib, bytebuddy, javassist & others":
if they don't support it, nothing changed. if they support it, you can provide
a resolver just for that proxy-type which can be as fast as needed/possible.
@"performance it is a huge regression":
that isn't correct at all.
in case of 0 resolvers it's an empty stream (given the amount of streams in
bval it isn't a real diff. i already discussed it with matt and mark)
in case of 1 resolver, you can have a look at the poc-versions for owb and
weld. for normal values (no proxy) it's just 1 additional instanceof check.
(for cdi-proxies the overhead is more or less the same – as you would use the
bv-annotations on the getter-methods)
in case of your own resolver, you have to care (/decide) on your own.
--> if you don't need it in your application/s, you don't have to use it
(the overhead is almost 0).
if we don't agree on the additional interface (for whatever reason),
i'll keep the patch in the forked repo. it's "easy" for users to patch
bval based on it. however, imo it would be better to support at least
the spi itself out-of-the-box.
> Support for proxied instances
> -----------------------------
>
> Key: BVAL-184
> URL: https://issues.apache.org/jira/browse/BVAL-184
> Project: BVal
> Issue Type: New Feature
> Reporter: Gerhard Petracek
> Assignee: Gerhard Petracek
> Priority: Major
>
> currently org.apache.bval.jsr.util.Proxies just detects the real class, but
> that means only getters can get annotated.
> with a spi like
> {code}
> public interface InstanceResolver extends Comparable<InstanceResolver> {
> <T> T resolveInstance(T instance);
> //...
> }
> {code}
> it would be possible to create resolvers for external libs (like owb, weld,
> ...)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
