[ 
https://issues.apache.org/jira/browse/ARTEMIS-4167?focusedWorklogId=849022&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-849022
 ]

ASF GitHub Bot logged work on ARTEMIS-4167:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 03/Mar/23 17:52
            Start Date: 03/Mar/23 17:52
    Worklog Time Spent: 10m 
      Work Description: gemmellr commented on PR #4368:
URL: 
https://github.com/apache/activemq-artemis/pull/4368#issuecomment-1453888368

   Would actually passing in the actual filter object make sense vs setting the 
option with a class name? It wouldnt work with JNDI but passing the object (or 
class name) to begin with seems like much more of more of niche case vs just 
setting the string based filter as in the other option.
   
   The precedence between the 2 different factory options, and indeed further 
between those options and the related system properties, seems like it needs 
documented as its not immediately clear.




Issue Time Tracking
-------------------

    Worklog Id:     (was: 849022)
    Time Spent: 40m  (was: 0.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: 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)

Reply via email to