Happy to help, and sorry I didn't think of that recent change as a likely explanation.
You should understand that the command line option you quoted is a security vulnerability that you've explicitly opened in your own broker, which can allow a malicious user to execute code on your system. The right way to use that flag is to explicitly list the classes you allow to be deserialized, or at most use package wildcards to avoid explicitly listing individual classes and subpackages in a trusted parent package. Does the broker warn, very clearly, at startup that the configuration you're using constitutes a security vulnerability? If not, I'll write an enhancement request in JIRA for that. Tim On Feb 12, 2016 9:43 AM, "mhemple" <mhem...@gmail.com> wrote: > ObjectMessage serialization security was the issue. > > * > ObjectMessage objects depend on Java serialization of marshal/unmarshal > object payload. This process is generally considered unsafe as malicious > payload can exploit the host system. That's why starting with versions > 5.12.2 and 5.13.0, ActiveMQ enforces users to explicitly whitelist packages > that can be exchanged using ObjectMessages.* > > I saw this a few days ago and added a white list but it didn't fix the > issue. I also tried running against AMQ 5.11.3 and it didn't work. > Apparently they added the security feature to 5.11.3 too. Anyway, I added > this (-Dorg.apache.activemq.SERIALIZABLE_PACKAGES="*") to the client side > and AMQ vm arguments and now everything is working as it should. > > Thanks Tim > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Messages-dequeued-but-not-consumed-tp4707380p4707463.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
