matthiasblaesing commented on PR #9077: URL: https://github.com/apache/netbeans/pull/9077#issuecomment-3676374494
The problem I see here is, that not only the interface classes from JSF/Faces are used, but also the implementation classes. That works as long as the implementations always match the interfaces. That does not work anymore (javax.* vs. jakarta.* package namespaces). So yes I think you are right. We need to isolate the implementations more. Maybe the approach taken for JSP can be adapted. Starting point is here: https://github.com/apache/netbeans/blob/master/enterprise/web.jspparser/src/org/netbeans/modules/web/jspparser/JspParserImpl.java The idea is there: the javax/jakarta specific part is built into a separate jar. For parsing a class loader is created, that makes the modules abstraction classes available, adds the java/jakarta specific parts and also includes the corresponding API modules. The javax/jakarta specific part parses the JSP and maps the data into the abstraction classes. These are then returned and used by the surrounding code. The javax/jakarta specific part is thus confined into the special class loader. For JSP the javax/jakarta specific code (https://github.com/apache/netbeans/tree/master/enterprise/web.jspparser/extsrc) exists only once in the jakarta variant, but is build for javax by replacing the references with the corresponding javax variants. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
