[
https://issues.apache.org/jira/browse/OWB-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888042#comment-16888042
]
Matej Novotny commented on OWB-1293:
------------------------------------
{quote}This is one of the drawback I see, jetty is not able to support CDI but
relies on impls supporting jetty at the end which is bad since it prevents
users to just use CDI, they must use the jetty version supported by the impl.
{quote}
I don't know how OWB did it, but with Weld we always had legacy support for
older version and integrated newer versions via new APIs. You could just pick
the latest version and code away. Unless you intend to change the integration
API every release, this is not really a problem. Plus we are trying to talk a
way that won't break so easily due to not having hard dependency and with a
prospect of making it into servlet spec part. Sorry, but your argument just
doesn't ring true to me.
You also completely disregarded the bit about having it under control in CDI
impl in regards to customization. Imagine this could be a standard, then in CDI
impl you have one decorator for all servlets but you are still able to
differentiate (if you want/need to) between servlets and adjust it. You loose
this ability with the other approach.
{quote}Not a point IMHO since you can also reverse it and say the jetty side of
things will be a pity in the CDI land so it is a 1-1 here IMHO.
{quote}
My point was that we do not delegate CDI knowledge and responsibility to Jetty
team (or any other servlet team) but instead keep it in house. That takes a
burden from them while adding next to nothing to us since we know CDI anyway
and have those integrations even now (and will keep legacies around for a
while). But yea, you can use that "reverse this" logic to any argument.
{quote}CDI already did most of the work (the not portable layer is only a
listener) and Servlet spec already rejected part of it so let's disagree on
this one even if it sounds easy to defer the responsability to its sibling ;).
{quote}
How do we defer responsibility here? By saying we do, hold and maintain
implementation and not them? That doesn't make much sense to me; in fact we
offer to take the responsibility instead.
{quote}This is really 3 lines (1 try/catch with a single loadClass and could
even just be nothing if you replace by it the doc of the listener to add). Most
of the reflection is needed to support server/webapp provider approaches but
this sounds out of scope for jetty (whereas it is for tomcat to link to my
first sentence).
{quote}
Yea, it's short, I never disputed that aspect. I merely say it's not a nice
code to have around when you can easily avoid that.
{quote}So at the end both options work and if you add the stability of the
projects it is likely that jetty is saner in terms of maintenance,
{quote}
Both options worked from the start, I thought the intention was to design
something unified that can lay foundation for a standard in future (defacto or
otherwise).
The stability of projects doesn't play a role here - Weld and Jetty are both
mature, stable and maintained projects. I don't see any difference that would
make a point in what we are discussing here.
> 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)
