[
https://issues.apache.org/jira/browse/ARTEMIS-4167?focusedWorklogId=849245&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-849245
]
ASF GitHub Bot logged work on ARTEMIS-4167:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 06/Mar/23 10:21
Start Date: 06/Mar/23 10:21
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
-------------------
Worklog Id: (was: 849245)
Time Spent: 1h 40m (was: 1.5h)
> Enhance deserialization filter beyond black/whitelist functionality
> -------------------------------------------------------------------
>
> Key: ARTEMIS-4167
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4167
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Scott Werner
> Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Now that Artemis is Java 11+ compatible, there is now the ability to set an
> ObjectInputFilter on an ObjectInputStream. There are also built in methods to
> generate filters similar to the current syntax and offers many other features
> out of the box. A global jvm property (jdk.serialFilter) can be set, but this
> is quite restrictive. I suggest adding a new serial filter pattern and class
> name of an ObjectInputFilter implementation, everywhere blacklist/whitelist
> exist today. In time we can look into converting the existing black/whitelist
> to the new format or just deprecating as the semantics are a bit different
> and may not be able to make it 100% compatible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
