I have lots of jars on my class path. It looks like files that should be in META-INF are not found at run time. Either they are not found at all or one file is overwritten by a file with the same name in a jar that is loaded later on. The result is that ServiceLoader returns no services so I had to hack the above mentioned files and hard code the correct classes to make it work.
Has anyone else experienced this?
I have similar problems with other assets that go into META-INF, like persistence.xml type things, that are not found at runtime. I’m thinking this is probably related to the fact that I am running this with Vert.x (http://vertx.io/) but no one over there has anything to say about it.
did you try to ask about this on the vert.x forum/mailinglist? It seems to me that there is a problem in there. I’m not really into it myself, so I don’t know how they do the classloading. I’m not sure what I can do in Axon to make this any easier…
Yeah, as I said I have posted there, but without luck. So I just thought I'd ask here to see if anyone recognized the issue. I think the ServiceLoader thing is the easiest way of doing it without dependencies on one DI framwework or another. It's obviously something wrong either with my setup or the class loading in Vert.x
I get the same problem when I try to use Hibernate for JPA. The classpath assets are not found. And at least Hibernate is very specific about wanting to find certain files on the classpath.
I have been having trouble getting my ParameterResolverFactory working too. I have not been able to get the ServiceLoader/META-INF stuff working, is there a chance this will be easier to wire up in the future?
Sorry, I meant to clarify, all I want to do is wire up the SpringBeanParameterResolverFactory so that I can inject arbitrary dependencies in to my @CommandHandler annotated methods
This is a pretty gross solution but it works - if anyone knows a cleaner way to do this I’d love to hear it. To me it seems like the type of thing that should just be wired in by default
Adding the latter annotation fixed the problem, thankyou :).
At the risk of hijacking the thread, in a related problem, I have noticed that the test-fixtures are stateful when it comes to calling the registerInjectableResource(injectableResource) on the fixture, I have noticed that this bubbles through to a static/stateful call on to SimpleResourceParameterResolverFactory.register(injectableResources).
This is causing some problems for me because it makes my tests stateful, in that dependencies made available in one test are now accessible to the next. There also doesn’t seem to be any avenue for teardown of the SimpleResourceParameterResolverFactory.
Are there any plans to remove the static nature of this? Also, it would be nice if it were not mandatory to register injectable resources for @CommandHandlers which I am not invoking in my test.
Happy to. Would you like me to create two separate issues, one an issue around statefulness, another as a feature request to not need to provide all dependencies for all handlers on the aggregate?
Great work fixing these so quickly Allard! Forgive my ignorance, where can I see the release schedule for when these things may be coming out? Good stuff
for Axon 2.0.1, there is no date yet. It depends on the number of issues found and how critical they are. You can expect it around the end of the month or early march.