ServiceLoader and Classpath problem

Imported from Google Groups
#1

This is not specific to Axon, but in my case the problem is caused by a couple of Axon classes.

Axon uses the ServiceLoader pattern to find user implementations of a couple of things. See

core/src/main/java/org/axonframework/common/annotation/ParameterResolverFactory.java
core/src/main/java/org/axonframework/serializer/ChainingConverterFactory.java

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.

/Per

#2

Hi Per,

it’s the first time I hear about this issue. What exactly did you do in term of ‘tweaking’ to get it working?

Cheers,

Allard

#3

Just some uggly quick fixes:

core/src/main/java/org/axonframework/common/annotation/ParameterResolverFactory.java

while (resolver == null && factories.hasNext()) {
resolver = factories.next().createInstance(memberAnnotations, parameterType, parameterAnnotations);
}

+if (resolver == null) {

  • ParameterResolverFactory factory = new TimestampParameterResolverFactory();
  • resolver = factory.createInstance(memberAnnotations, parameterType, parameterAnnotations);
    +}
#4

Hi Per,

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…

Cheers,

Allard

#5

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.

/Per

#6

Hi all,

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?

#7

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

#8

I was able to work around the problem by using the MethodInvokingFactoryBean provided by spring:

org.axonframework.common.annotation.ParameterResolverFactory.registerFactory

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

#9

Hi William,

the SpringBeanParameterResolver is wired automatically if you use the axon:annotation-config element.

Are you already using that? Or do you ‘manually’ wrap your annotated beans?

Cheers,

Allard

#10

My humblest apologies, I mistook my context:annotation-config/ to be axon:annotation-config.

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.

Thanks heaps for the very quick and useful reply!

#11

Hi William,

valid point you raise there. Ideally, fixtures must not be stateful.
Could you report the issue on issues.axonframework.org?

Cheers,

Allard

#12

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?

#13

http://issues.axonframework.org/youtrack/issue/AXON-100 and http://issues.axonframework.org/youtrack/issue/AXON-101

#14

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 :slight_smile:

#15

Hi Wiliam,

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.

Cheers,

Allard

#16

OK, great