纯Java和Grails之间的反射差异

Question

I'm using a set of APIs developed internally by my company to communicate with some common central services in the organization. The APIs can be configured dynamically by runtime configuration to use several transport protocols as needed by the system.

The collection of internal APIs are coupled to the IBM WebService thinclient.jar to configure and call all the necessary web services. I got the standalone prototype working smoothly, but need to integrate the functionality into several other services that are being developed in Grails.

This is where things fell apart. In the code that I've written, we just call a factory method and use that to get a client session and then proceed with our business logic. Simple. Using the debugger and digging into the API getClient() call, I can see that this gets a generic transport configuration and then binds it to a SOAP transport configuration. From here, the path differs whether it is the pure standalone Java service or the service running in the Grails app.

• In the pure Java standalone, this then is bound to a com.ibm.ws.webservice.engine.client.Service where the initService() method is called and things work as expected.

• In the Grails app, with the same Java code included, the same place in the code calls to com.springsource.loaded.ri.ReflectiveIntercepter and then after a lot of back and forth in the spring-loaded API, it finally throws a java.lang.reflect.InvocationTargetException.

Does any one have any tips or ideas on how to get the reflection in Grails to behave the same as in the straight Java?

I've tried a lot of variations to get to this point and I'm nearing the end of my rope. Ideally, it would be easiest to manage the Grails service that manages our business logic and the Java code that talks to these internal systems together, so I would prefer to get everything (Grails and my Java service code) working together. I briefly tried building a standalone JAR of my service code and all it's dependencies, but had chained dependency conflicts when trying to use that in Grails. My final option will be to stand my Java service up separately from the business logic in the Grails service and just make the calls from the Grails service to the Java service. This is less than ideal.

Answer 1

It's easy when you stumble into the answer... ;-)

The Grails service runs as expected if I set the run configuration in IDEA to use -noreloading option.

grails -noreloading run-app

This stops Grails/IDEA from leaving in the hooks to reload classes on the fly.

Are there any thoughts on whether this is a bug in Grails or the SpringSource Loader classes?