Thanks. I submitted a pull based on your suggestion https://github.com/apache/activemq-artemis/pull/4368
------- Original Message ------- On Saturday, February 4th, 2023 at 7:31 PM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > I think using the URI and being a property on the connection factory would > be a good idea. > > On Thu, Feb 2, 2023 at 6:07 PM Scott Werner > werner.sc...@protonmail.com.invalid wrote: > > > Hi, > > > > I have a need for a more advanced object message deserialization filter > > than the current black/whitelist functionality. 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. This filter can be set on the `ois` within the getObject() call on the > > object message, where the black/whitelist is being set today. > > > > I have a concept working locally, and would like to contribute back, but > > it is not complete, and before submitting a PR could use some advice. > > Currently, the ConnectionFactoryOptions is used to pass down the > > black/whitelist through the various layers and implemented by the > > connection factory and other properties classes. As a user, after creating > > my connection factory, it would be ideal to set the object filter on it, > > then any object message received through one of it's sessions will use it > > for deserialization. > > > > My issue is the best way of passing down this object filter? > > ConnectionFactoryOptions and its implementations appear to only contain > > strings or primitives, populated from xml, -Ds or JNDI, and serialized. I > > don't see anywhere that an object such as this is passed down, usually > > constructed via configuration, so it feels dirty/violation to add like > > this. I can bypass these classes and add as a static to > > ObjectInputstreamWithClassLoader, if set, use. Downside, it affects > > anything within that classloader and feels equally dirty. Only thing I > > thought might be acceptable is adding the fully qualified name of the > > filter class as a string to the configs, and instantiate when necessary. > > This is not as convenient as setting an already constructed object, but it > > does avoid the config/serialization issues. Thoughts? > > Scott > > > -- > Clebert Suconic
