arjantijms commented on pull request #399: URL: https://github.com/apache/tomcat/pull/399#issuecomment-752499693
> I would be against exposing container internals via the Servlet API as it undermines portability. Well, actually it could be used by integration libraries to improve portability, the exact opposite. Integration libraries enumerate all known implementations, adapting the internals of each to some common functionality. As an example, look at how Soteria is able to implement an SPI for Weld: https://github.com/eclipse-ee4j/soteria/blob/master/spi/bean-decorator/weld/src/main/java/org/glassfish/soteria/spi/bean/decorator/weld/WeldBeanDecorator.java It allows to get the Weld specific BeanManager from the spec compliant BeanManager: ```java BeanManagerProxy.unwrap(beanManager)); ``` Another example, using enumeration of known implementations: https://github.com/omnifaces/exousia/blob/master/src/main/java/org/omnifaces/exousia/spi/impl/DefaultRoleMapper.java#L374 It uses reflection, but you may get the idea. Without using reflecting and specifically for Tomcat: https://github.com/omnifaces/exousia/blob/master/src/main/java/org/omnifaces/exousia/spi/integration/IntegrationInitializer.java#L42 It now only has Tomcat, but I'm planning to add Jetty there later. The internal APIs are kinda used for essentially a polyfill. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
