On 21/07/2020 14:44, Romain Manni-Bucau wrote: > Yes, was thinking to tomee in particular since it does not use tomcat as > a lib but really as the container so if the container fails then it can > become hard if not "disabl-able" somehow (at least with subclassing or > something programmatic).
I don't think I am going to pursue this at this time. The benefit is minimal and the chances it breaks something or makes things difficult for TomEE is high. I may come back to this in the future. Mark > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mar. 21 juil. 2020 à 15:39, Mark Thomas <ma...@apache.org > <mailto:ma...@apache.org>> a écrit : > > On 21/07/2020 14:26, Romain Manni-Bucau wrote: > > Hi Mark, > > > > e) c as default + add a toggle to behave as a? (thinking to container > > extending tomcat where this shouldn't fail probably) > > So keep the attributes in ContextService and friends that record the > JAX-RPC so they are accessible to downstream projects that still want to > support JAX-RPC? Are there any such projects? TomEE? > > Mark > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | LinkedIn > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > > > > Le mar. 21 juil. 2020 à 14:34, Mark Thomas <ma...@apache.org > <mailto:ma...@apache.org> > > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> a écrit : > > > > All, > > > > JAX-RPC has been removed in Jakarta EE 9. > > > > Implementations are free to continue supporting it if they wish. > > > > My preference would be to remove JAX-RPS support in Tomcat 10. > > > > I am working on this at the moment and am wondering how to > handle the > > JAX-RPC elements we can't entirely remove. > > > > There is a chain of references from web-app_5_0.xsd to > > jakartaee_web_services_client_2_0.xsd which still has a number of > > JAX-RPC specific attributes defined for "service-ref": > > > > - jaxrpc-mapping-file > > - handler > > - handler-chains > > > > (a double check I have identified all the JAX-RPC specific > attributes > > would be appreciated) > > > > This appears to be a consequence of the same element being > used for > > JAX-RPC and JAX-WS. > > > > Assuming there is consensus to remove JAX-RPC support then the > question > > arises what do we do if we observe one of the JAX-RPC specific > > attributes above? Possible options include: > > > > a) Ignore it and carry on > > b) Log a warning but otherwise ignore it and carry on > > c) Log an error and fail the deployment > > d) Something else > > > > I'm currently leaning towards option c. > > > > Thoughts? > > > > Mark > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org> > > <mailto:dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org>> > > For additional commands, e-mail: dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org> > > <mailto:dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org>> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
