[ https://issues.apache.org/jira/browse/OWB-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16881400#comment-16881400 ]
Greg Wilkins commented on OWB-1293: ----------------------------------- The strategy that I have suggested to Weld is to have two integrations and to use the presence of the Decorator class on the classpath to decide which to use. the jetty Decorator class will be able to be loaded if the container has been prepared according to legacy instructions, so only once that class has been tested for do you attempt to load/use the class that is dependent on it and its other associated APIs. This means you can implement the legacy approach without using reflection. For the new approach, we are setting a context attribute to indicate it is available, so you can test for that before trying the new approach. > 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.3#76005)