|
1.0.4 changes get merged into 1.1 so that is no surprise It has nothing to do with the plugins and everything to do with content negotiation. The only reason that the plugins have an effect is because they introduce controllers. The controllers then trigger an execution path that causes the XML of the request to be processed. A quick workaround is to remove the "xml" mime-type mapping from the grails.mime.types configuration option in Config.groovy. I think for 1.1 though we need to sort out the content negotiation because it seems to cause more problems than it solves. For now I'm going to shift this to 1.1 because any "fix" for 1.0.4 would be a horrible hack that might break more than it fixes. Since you have the above workaround, that should suffice for now. Thanks for the quick reply. The workaround works for me and I currently don't need content negotiation. So removing the "xml" mime-type mapping from the grails.mime.types is not a problem for me (though it might be for others and thus should be resolved sometimes but not necessarily in 1.0.4). Another error now makes Xfire break in grails-1.1-beta1 > r7774 (in r7775 groovy 1.5.6 was replaced by groovy 1.6, which apparently causes the error) To reproduce:
Interestingly I can still consume the web service if I use the old WSDL file. So it looks like only the WSDL generation is broken. Stacktrace of sample project running with xfire plugin after accessing wsdl document via web interface There's a workaround, plus Carsten's other issue appears to be something specific to XFire. I saw a post in another archive that suggested using JAXB instead of Aegis. Someone with some serious XFire foo will have to look into that one I think. It looks like XFire is trying to serialise a CertPath instance, but I have no idea why. Ive got this problem as well and its got me in big trouble I had XFire and acegi working just fine at one point, my setup was Grails 1.0.4, XFire 0.7.5 and acegi 0.4.1 and it worked fine. Then I upgraded to acegi 0.5.1 and used annotations for securing my controllers and then XFire lost the ability to generate a WSDL. I really need a workaround for this ASAP please. I tracked the problem down. This error only seems to occur if you are trying to expose grails domain objects as web service call parameters or return types. I am no longer doing this and instead using a DTO and mapping this to my domain Looks like everything seems to work again after I updated tp grails 1.1 final and xfire 0.8.1. Thanks a lot Chanwit and all the others! Just for reference: In one of my existing projects I still got an error on grails startup (see below) . My resolution for this was to copy the latest xercesImpl.jar into the applications' lib directory. 2009-03-13 13:30:33,780 [main] ERROR mortbay.log - Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'pluginMetaManager' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.LinkageError: loader constraint violation: when resolving field "NODESET" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the referring class, javax/xml/xpath/XPathConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type: java.lang.LinkageError: loader constraint violation: when resolving field "NODESET" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the referring class, javax/xml /xpath/XPathConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type at java.security.AccessController.doPrivileged(Native Method) at grails.web.container.EmbeddableServer$start.call(Unknown Source) at RunApp$_run_closure5_closure11.doCall(RunApp:145) at RunApp$_run_closure5_closure11.doCall(RunApp) at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:269) at RunApp$_run_closure5.doCall(RunApp:137) at RunApp.runInline(RunApp:104) at RunApp.this$4$runInline(RunApp) at RunApp$_run_closure1.doCall(RunApp:58) at RunApp$_run_closure1.doCall(RunApp.groovy:33) at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324) at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334) at gant.Gant$_dispatch_closure6.doCall(Gant.groovy) at gant.Gant.withBuildListeners(Gant.groovy:344) at gant.Gant.this$2$withBuildListeners(Gant.groovy) at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source) at gant.Gant.dispatch(Gant.groovy:334) at gant.Gant.this$2$dispatch(Gant.groovy) at gant.Gant.invokeMethod(Gant.groovy) at gant.Gant.processTargets(Gant.groovy:495) at gant.Gant.processTargets(Gant.groovy:480) Thanks Carsten, I am going to close this issue then. |
||||||||||||||||||||||||||||||||||||||||||||||
After playing with grails 1.1 I found out that the problem exists over there too. My gut feeling is that the constraint in the UrlMappings is no longer obeyed correctly...