[GitHub] [tomcat] fmarco76 opened a new pull request, #639: Cusotm ssl engine parameters
fmarco76 opened a new pull request, #639: URL: https://github.com/apache/tomcat/pull/639 Deploying tomcat with a custom ssl engine could require to perform some extra configuration before its usage. As an example, [tomcatjss](https://github.com/dogtagpki/tomcatjss/) project needs to provide the actual IPs of client and server for audit purpose. To provide the IPs we are working on a patch which require to copy several tomcat methods from _NIO_ endpoint and channel because the current implementation does not allow to access the ssl engine before it is used (the method to be replaced are in [this PR](https://github.com/dogtagpki/tomcatjss/pull/73)). Changes in this PR allow to extend tomcat _NIO_ classes and modify the ssl engine without reimplementing the existing methods. -- 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: dev-unsubscr...@tomcat.apache.org 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
[GitHub] [tomcat] ChristopherSchultz commented on pull request #639: Cusotm ssl engine parameters
ChristopherSchultz commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1638643485 This looks good to me, but I'd appreciate someone with more in-depth knowledge of the protocol handlers to weigh-in. The only thing that caught my eye was that the signature of `AbstractNetworkChannelEndpoint.createChannel` has changed by widening the return value from `NetworkChannel` to `Channel`. This change is not backward compatible and we might want to introduce a new method instead of changing the signature of the current one. This pull request is against `main`, so this change is okay, but back-porting to other stable releases I think is not okay for this reason. -- 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: dev-unsubscr...@tomcat.apache.org 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
OSGI Portable Java Contract Definitions for the Expression Language
Hi, I was looking over the Expression Language API and implementation and noticed the following: 11.0.0-M9 API Manifest.mf: Provide-Capability: osgi.contract;osgi.contract=JavaEL;version:Version ="6.0";uses:="jaka Implementation Manifest.mf: Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.servi celoader.registrar)(version>=1.0.0)(!(version>=2.0.0)))",osgi.contrac t;osgi.contract=JavaEL;filter:="(&(osgi.contract=JavaEL)(version=6.0. 0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=21))" Specifically the JavaEL contract definition. It looks as though new contracts were published for Jakarta Expression Language: https://docs.osgi.org/reference/portable-java-contracts.html#java-ee-contracts Should this be updated from JavaEL to JakartaExpressionLanguage for Expression Language 4.0/5.0/6.0? Regards, Paul Nicolucci
