背景
ibmmq 的相关jar包maven仓库是没有的，用的8版本的进行测试agent，原来是没问题的，这次怎么也不行。
原来MQMessage类中是有getProperty这个方法的，可是竟然通过反射报错没有这个方法。
把当前依赖的ibmmq的先关jar包下载下来，查看源码发现确实有这个方法呀，我头然感到有点毛骨悚然，灵异事件？
无法相信，通过getDeclareMethods打出了所有的MQMessage类中的方法，确实没有这个方法，究竟是什么鬼？
分析
因为不是用的maven打包，需要通过idea打包，打包的方式是这样的。
如上图，箭头所指是真正的demo jar包，它所依赖的是当前的同级目录的其他jar包。
可是：
在JavaAgent中System.out.println("java.class.path"+System.getProperty("java.class.path"));，（这个属性的意思是类加载的路径，貌似是所有需要加载的类的路径，所以我粗略的理解为当前加载了哪些jar包。可能有些不准确）查看加载了哪些jar包，发现并没有加载ibmmq的 8版本
相关的jar包并没有加载本demo同级目录下的相关jar包。
在agent的中打印日志，得到MQMessage这个类所在的jar包
log.debug("msg jar ====== [%s]",msg.getClass().getProtectionDomain().getCodeSource());
最终打出的jar包是当前jdk的ext目录下咋ibmmq.jar，而不是我上面的目录中的jar。
然后把这个jar send到桌面，发现确实是没有这个方法。
至此，问题有了眉目了。
通过查看demo中的加载jar包的依赖MANIFEST.MF发现
如图
引发的思考
上面确定了问题，这里来分析一下~
为什么加载到了jdk 的 ext里面的jar
双亲委派机制得工作过程：
1-类加载器收到类加载的请求；
2-把这个请求委托给父加载器去完成，一直向上委托，直到启动类加载器；
3-启动器加载器检查能不能加载（使用findClass()方法），能就加载（结束）；否则，抛出异常，通知子加载器进行加载。
4-重复步骤三；
针对于我的情况，可能就是因为ext中有了ibmmq需要的jar包，所以不去app层面找这个jar包了，即MANIFEST.MF。
解决方案
- 将ext下面ibmmq的jar删掉
- 换一个ext下面没有ibmmq的jar的机器。
（好吧，这两个解决方案好像是一个意思~）