You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Patrik Dudits (JIRA)" <ji...@apache.org> on 2016/06/06 12:59:20 UTC

[jira] [Created] (AMQ-6312) ObjectMessage's setTrustedPackages can only be applied via system property in resource adappter setting

Patrik Dudits created AMQ-6312:
----------------------------------

             Summary: ObjectMessage's setTrustedPackages can only be applied via system property in resource adappter setting
                 Key: AMQ-6312
                 URL: https://issues.apache.org/jira/browse/AMQ-6312
             Project: ActiveMQ
          Issue Type: Bug
    Affects Versions: 5.13.3
            Reporter: Patrik Dudits


We're using ActiveMQ via resource adapter, and with upgrading post 5.12.0 we want to handle the trusted packages configuration via resource adapter rather than via system properties.

This approach is not supported at all, because:

# {{ActiveMQResourceAdapter}} does not expose {{setTrustedPackages}}
# {{ActiveMQManagedConnectionFactory}} does not expose {{setTrustedPackages}}
# Neither {{ServerSessionImpl}}, {{ActiveMQSession}} or {{MessageEndpointProxy}} set trusted packages on received {{ActiveMQObjectMessage}}

The first two could be solved by adding the support into {{ActiveMQConnectionSupport}} by adding a property and applying trustedPackages in {{createConnectionFactory(ActiveMQConnectionRequestInfo, MessageActiveationSpec}}.

However, for the third one I'm not sure on which level the change should be applied - either session should be enforcing connection's trusted packages, or {{ServerSessionImpl}} could do it in its {{beforeDelivery}} method. But I cannot think of use case where session should not be handling this in first place. 

Alternatively, {{ActiveMQObjectMessage}} could get the trusted packages list from its connection, which guarantees that deserialization rules of the connection are always applied, not only when {{ActiveMQConnectionConsumer}} is used.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)