{"action":"created","issue":{"url":"https://api.github.com/repos/mulesoft/redis-connector/issues/4","repository_url":"https://api.github.com/repos/mulesoft/redis-connector","labels_url":"https://api.github.com/repos/mulesoft/redis-connector/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/mulesoft/redis-connector/issues/4/comments","events_url":"https://api.github.com/repos/mulesoft/redis-connector/issues/4/events","html_url":"https://github.com/mulesoft/redis-connector/pull/4","id":57383176,"number":4,"title":"Fix issue of getting BeanCreationException when our maven project build runs integration tests","user":{"login":"ckimMM","id":10532333,"avatar_url":"https://avatars.githubusercontent.com/u/10532333?v=3","gravatar_id":"","url":"https://api.github.com/users/ckimMM","html_url":"https://github.com/ckimMM","followers_url":"https://api.github.com/users/ckimMM/followers","following_url":"https://api.github.com/users/ckimMM/following{/other_user}","gists_url":"https://api.github.com/users/ckimMM/gists{/gist_id}","starred_url":"https://api.github.com/users/ckimMM/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ckimMM/subscriptions","organizations_url":"https://api.github.com/users/ckimMM/orgs","repos_url":"https://api.github.com/users/ckimMM/repos","events_url":"https://api.github.com/users/ckimMM/events{/privacy}","received_events_url":"https://api.github.com/users/ckimMM/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-02-11T21:53:16Z","updated_at":"2016-03-16T19:41:05Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/mulesoft/redis-connector/pulls/4","html_url":"https://github.com/mulesoft/redis-connector/pull/4","diff_url":"https://github.com/mulesoft/redis-connector/pull/4.diff","patch_url":"https://github.com/mulesoft/redis-connector/pull/4.patch"},"body":"This is to fix the issue discussed in the (long) issue thread:\r\n[BeanCreationException: Could not autowire method: public byte[] org.mule.module.redis.RedisModule.set(...)]\r\n(https://github.com/mulesoft/redis-connector/issues/3). We acknowledge and appreciate the help given by David Dossot.\r\n\r\nThere are three relatively small sub-commits done over the many days, each addressing a particular challenge that had to be overcome as we try to debug and find a reasonable fix that works for our mule project.\r\n\r\nWe see the BeanCreationException when our maven project build runs integration tests; the project is large, and not easy to reduce the project to something simple that can reproduce the exception being thrown.\r\n\r\nTo try to provide some background on our project, I'll copy/paste at bottom from one of my comments in the issue thread in reply to a question by David Dossot.\r\n\r\nThe fix in this pull request removes the @Inject annotation from seven api methods in the RedisModule class. However, in order for the redis connector to still work in a mule xml flow, we needed to provide a MuleEvent object to those seven api methods, but instead of providing that as one of the method arguments autowired by @Inject, we remove the need for that argument by providing the MuleEvent object within those seven methods.\r\n\r\nI have tested the resulting redis connector using the redis example project that David wrote up in his blog [Mule and Redis get a web bug] (http://blogs.mulesoft.org/mule-and-redis-get-a-web-bug/), but changing to Operation \"Set\" instead of \"Increment hash\" since the increment hash method is not one of the seven api methods in RedisModule affected by this fix, but the set method is one of those seven api methods. I did not do more testing involving the other six api methods because I have doubts whether MuleSoft would accept this pull request, but would be happy to do so if this pull request is reviewed positively for merging into master branch.\r\n\r\nFinally, in the project pom, I arbitrarily named the repository https://repository.mulesoft.org/nexus/content/repositories/releases/ as \"MuleSoft Releases Repository NexusPublic\"; that probably should be reviewed for internal consistency by MuleSoft staff.\r\n\r\nThanks for your consideration.\r\n\r\nBelow is some background on our large mule project where we ran into above problem, copy/paste from one of my comments in the issue thread:\r\n...\r\na) We have a large subsystem currently running Mule 3.4.0 CE that has been in Production for about a year now. That subsystem currently specifies in the project pom the dependency: mule-module-redis version 3.3.3-SNAPSHOT, so I was just trying to work down the Tech Debt and see what it would take to upgrade. So, hoping not to do wholesale refactoring or re-design for what had looked like just upgrading to a later version 3.4.0 mule-module-redis, at least not for now.\r\nb) That project uses Mule flow, Spring beans for DI, and Java POJO classes.\r\n\r\n1) I don't believe 'org.mule.module.redis' package gets scanned, as you commented, since our beans config file has only:\r\n<pre><code>\r\n    &lt;context:annotation-config /&gt;\r\n    &lt;context:component-scan base-package=\"com.jumptap.mephesto,com.jumptap.mule\" /&gt;\r\n</code></pre>\r\nBut, to try to throw more light, we do have our own redis adapter class that in in a package that does get scanned, and that redis adapter singleton uses Spring to inject in a RedisModule object named \"globalredis' as a class property (field).\r\n<pre><code>\r\n      &lt;spring:property name=\"redisModule\" ref=\"globalredis\"/&gt;\r\n</code></pre>\r\n\r\n That RedisModule object is specified by\r\n<pre><code>\r\n    &lt;redis:config \r\n        name=\"globalredis\"\r\n        connectionTimeout=\"${redis.connectionTimeout}\"\r\n        host=\"${redis.host}\"\r\n        password=\"${redis.password}\"\r\n        port=\"${redis.port}\"\r\n        reconnectionFrequency=\"${redis.reconnectionFrequency}\"\r\n        poolConfig-ref=\"jedisConfig\"\r\n    /&gt;\r\n</code></pre>\r\n\r\n2) So to answer you second bullet point, Mule (via redis:config) does the instantiation of the RedisModule object/bean.\r\n\r\nI do take your point that since we only call RedisModule methods in Java (from within that redis adapter class), maybe we shouldn't be using the redis-connector. There are a number of wrapper methods that you've written in RedisModule that we take advantage of in our redis adapter class, such as\r\n  redisModule.set(...)\r\n  redisModule.get(...)\r\neven\r\n  RedisUtils.run(redisModule.getJedisPool(), new RedisAction<Long>() {...});\r\nso that's probably part of the reason for the initial design choice to make use of mule-module-redis.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/mulesoft/redis-connector/issues/comments/197509282","html_url":"https://github.com/mulesoft/redis-connector/pull/4#issuecomment-197509282","issue_url":"https://api.github.com/repos/mulesoft/redis-connector/issues/4","id":197509282,"user":{"login":"Damore","id":4624254,"avatar_url":"https://avatars.githubusercontent.com/u/4624254?v=3","gravatar_id":"","url":"https://api.github.com/users/Damore","html_url":"https://github.com/Damore","followers_url":"https://api.github.com/users/Damore/followers","following_url":"https://api.github.com/users/Damore/following{/other_user}","gists_url":"https://api.github.com/users/Damore/gists{/gist_id}","starred_url":"https://api.github.com/users/Damore/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Damore/subscriptions","organizations_url":"https://api.github.com/users/Damore/orgs","repos_url":"https://api.github.com/users/Damore/repos","events_url":"https://api.github.com/users/Damore/events{/privacy}","received_events_url":"https://api.github.com/users/Damore/received_events","type":"User","site_admin":false},"created_at":"2016-03-16T19:41:05Z","updated_at":"2016-03-16T19:41:05Z","body":"When this fix will be available?"}}