gemmellr commented on PR #4368: URL: https://github.com/apache/activemq-artemis/pull/4368#issuecomment-1455862054
> This was my original ask on the mailing list: https://lists.apache.org/thread/0zktnksnxvnpdqwp1wp2tojw3rtq2wz6 > > Setting the object is much more convenient but breaks everything else as the properties are serialized in some form, this would be the first outlier to that. > > Agreed on enhancing the docs. I would think there should be a way to stop serializing certain stuff. Doing so in a case like this wouldnt seem odd to me. If setting the object is more convenient, and most folks should use the filter string instead anyway, it seems further odd to do add the second class option. Related somewhat...in Qpid JMS we added an 'extensions' mechanism to the factory so we could define specific BiFunction extension points to get custom config etc objects at the appropriate time/place, but only need a single setter on the ConnectionFactory itself, helping helps keep the API (and impl) simpler whilst adding such things that few might use, and also help in not needing to refer to custom types in the factory API. The method just takes a string extension name key and a provided function (to match whatever is defined for that extension name). Applications set their function impl on the factory (perhaps just using a lambda), and when the relevant client code is hit it uses the function if present to get returned what is needed in that case...e.g here such a function could get returned the filter object for that connection as it is created. https://github.com/apache/qpid-jms/blob/2.2.0/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnectionExtensions.java For example there are a couple of simple extensions for providing the username and password, which can be seen in use here: https://github.com/apache/qpid-jms/blob/2.2.0/qpid-jms-client/src/test/java/org/apache/qpid/jms/integration/SaslIntegrationTest.java#L514-L519 Those clearly aren't very custom things, but the main point for those ones was more that it enables them to be given specifically when needed as the connection is being created, and more importantly given again when it is later re-connecting (thats covered elsewhere in a failover test) as it is then fired again and updated valid credentials can be provided if needed, useful for certain use case with expiring credentials. -- 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]
