[
https://issues.apache.org/jira/browse/OWB-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887939#comment-16887939
]
Matej Novotny commented on OWB-1293:
------------------------------------
bq. + option A. Jetty provides a Decoration mechanism that does not have hard
dependencies on any exposed Jetty APIs. This is not a CDI specific mechanism.
CDI implementations continue to have jetty integration modules which use this
mechanism. The future path for this would be for the servlet spec to be
augmented with it's own standard decoration mechanism, so ultimately all CDI
implementations would have a single servlet integration module (plus perhaps
legacy ones for older versions).
To re-iterate here, I defended this option for Weld integration and I think it
is superior because:
* the CDI integration code is in hands of the CDI impl which may want to
customize it somehow (we do some bits that you won't achieve with pure CDI API)
* The CDI-related code resting in CDI impl also gives bigger assurance to users
that should something go wrong, there will be people around who understand CDI
and can solve it
* As Greg pointed out, Servlet spec can adapt such approach (or very similar
one) in the future as a clear standard; that's strong argument as now we have
separate integration for each servlet
* Jetty doesn't need to implement cumbersome class loading and reflection based
invocation of methods which is generally error-prone and hard to manage code;
all the more when we can do this in a clean manner in CDI impl code
bq. + option B. Jetty provides a specific CDI decorator that uses the standard
CDI.current() based APIs. Jetty maintains the CdiDecorator (including
handling any future javax->jakarta renaming that may happen). The CDI
implementations themselves do not need a jetty integration module, but they
would still need code changes to know not to apply they legacy jetty
integration (nor any other integration). The future path for this is unclear
as it is not likely that such a decorator could be mandated by the servlet
specification. Perhaps other containers would take up this approach as a
defacto standard? But it is likely to remain a jetty specific mechanism.
I do not really see upsides here. The Jakarta EE rename will happen in CDI
impls anyway, so no big deal there.
As for separate modules - we already need to separately solve other servlets
and this solution doesn't seem to bring a unification on that front either.
We will still need to keep legacy code in place, so in fact the jetty module
would be around anyway, at least for some time.
Is there something blocking OWB in applying solution a)?
Or is there a massive trade-off that I am not seeing?
> Update Jetty integration prior to Jetty-10 release
> --------------------------------------------------
>
> Key: OWB-1293
> URL: https://issues.apache.org/jira/browse/OWB-1293
> Project: OpenWebBeans
> Issue Type: Improvement
> Components: Interceptor and Decorators
> Reporter: Greg Wilkins
> Priority: Major
>
> The current jetty integration relies on exposing private jetty APIs so a
> jetty Decorator can be registered. This is fragile and requires different
> APIs for the upcoming jetty-10 release.
> Instead, Jetty is developing a mechanism where a object with a decorator
> signature can be set as a context attribute and it will be introspected and
> dynamically registered as a decorator without any API dependencies.
> This is currently being developed in
> [https://github.com/eclipse/jetty.project/pull/3838] and an integration with
> Weld is at [https://github.com/weld/core/pull/1926]
> Feedback is sought from the OpenWebBeans team on the approach and then we'd
> like to collaborate to make a similar integration.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
