Issue Details (XML | Word | Printable)

Key: GRAILS-3537
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Peter Ledbrook
Reporter: Carsten Block
Votes: 4
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Grails

Xfire service url mapping broken in projects that also use acegi or jsecurity

Created: 06/Nov/08 10:19 AM   Updated: 13/Mar/09 08:34 AM   Resolved: 13/Mar/09 08:34 AM
Return to search
Component/s: Configuration
Affects Version/s: None
Fix Version/s: 1.1

Time Tracking:
Not Specified

File Attachments: 1. Text File xfire_stacktrace.log (15 kB)

Environment: Ubuntu Intrepid 8.10, Java 1.6_r10, grails 1.04_SNAPSHOT


 Description  « Hide

After the fixing of GRAILS-3369 in Revision 7401, the URL Mapping now seems to be broken for services exposed via Xfire WS plugin in projects that also use acegi or jsecurity

Here is a short example on how to reproduce this bug:

  • check out latest svn version of grails 1.0.4 from trunk
  • install xfire plugin
  • create simple Webservice, e.g.:
WsTestService.groovy
class WsTestService {

    boolean transactional = true
    static expose = ['xfire']

    public String serviceMethod() {
        return "Hello"
    }
}
  • in grails-app/conf/UrlMappings.groovy insert constraint: controller(matches:/.*[^(services)].*/)
  • check that you can properly consume the hello world service via a soap client, i.e. you receive "Hello" as response
  • install acegi (or jesecurity) plugin
  • invoke xFire service again and you should receive a Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0] response
  • roll back grails snapshot to a release < 7400, e.g. svn update -r 7399; ant jar
  • restart testapp and check that your receive "Hello" as response again


Carsten Block added a comment - 07/Nov/08 12:11 PM

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...


Graeme Rocher added a comment - 07/Nov/08 01:50 PM

1.0.4 changes get merged into 1.1 so that is no surprise


Peter Ledbrook added a comment - 10/Nov/08 02:51 AM

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.


Carsten Block added a comment - 10/Nov/08 03:12 AM

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).


Carsten Block added a comment - 02/Dec/08 05:24 AM

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:

  • check out grails 1.1 r7774 (i.e. svn update -r 7774)
  • grails create-app testapp
  • grails install-plugin xfire
  • in grails-app/conf/UrlMappings.groovy insert constraint: controller(matches:/.[^(services)]./)
  • in in grails-app/conf/Config.groovy delete xml entry from grails.mime.types
  • create sample web service as described above
  • run app and check that you can properly consume the xfire web service
  • check out the newest grails-1.1 release (any release > r 7774) will do
  • compile and run everything again
  • When trying to browse the WSDL file in the browser the error "Couldn't create type for property certificates on class java.security.cert.CertPath: Cannot create mapping for java.util.List, unspecified component type for property certificates" will occur

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.


Carsten Block added a comment - 02/Dec/08 06:55 AM

Stacktrace of sample project running with xfire plugin after accessing wsdl document via web interface


Peter Ledbrook added a comment - 27/Jan/09 12:41 PM

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.


Sean Tindale added a comment - 12/Feb/09 08:54 PM

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.


Sean Tindale added a comment - 14/Feb/09 09:38 PM

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


Carsten Block added a comment - 13/Mar/09 07:47 AM

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)

Graeme Rocher added a comment - 13/Mar/09 08:34 AM

Thanks Carsten, I am going to close this issue then.