CORS: removing allowOrigins from the annotation only
Hi Benson, all, I've been modifying the CrossOriginResourceSharing annotation as well as the CrossOriginResourceSharingFilter during the last couple of days to address the issue reported by Matt Bishop, namely, to do with making it possible to avoid specifying "allowOrigins" within the CrossOriginResourceSharing annotation, given that "allowOrigins" keeps the list of absolute URIs thus it is not ideal at all to have it declared in the actual code. CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean property set by default to 'false' and also the 'allowOrigins' list/array property, the latter was ignored if 'allowAllOrigins' was set to true. Additionally, similar properties exist in CrossOriginResourceSharingFilter which can be effective when the annotation is not set on a given method. I started with removing what I thought was a redundant CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an empty/default 'allowOrigins' does mean 'allow all origins'. The problem I'm seeing with this now that in order to be possible to avoid specifying specific 'allowOrigins' in the application code within CrossOriginResourceSharing one has to choose not to use CrossOriginResourceSharing because if it is provided it takes the preference over the possible custom values set in the filter. So one option is to restore the boolean "allowAllOrigins" flag. By default it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is empty then there must be a filter property set customizing the allowOrigins to meet the allowAllOrigins==false requirement. Another option is to remove CrossOriginResourceSharing' allowOrigins and expect the filter customize it when needed. The idea here is that it appears to be unlikely various individual methods within a current JAX-RS endpoint may have different allowed origins, rather it's more likely that the allowOrigins are going to be shared by all the JAX-RS methods for a given endpoint. So I kind of prefer the 2nd option but at the same time I'm OK with restoring the flag for the sake of simplifying the testing and such at a minor cost of keeping the somewhat redundant 'allowAllOrigins'... Let me know please what you think Cheers, Sergey
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Just a little update on this. I made some more changes and at this point in time we're getting close. For me the OSGi Remote Services and Remote Service Admin TCKs are 100% passing but other people did report a failure that we have to investigate a little further. I'll chime in again when everything is good, as we could do a release at that point. Cheers, David On 20 February 2012 22:38, Sergey Beryozkin wrote: > Hi David > > On 19/02/12 00:42, David Bosschaert wrote: >> >> Hi all, >> >> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK >> to make sure it's still compliant with the spec. >> It turned out that the changes made between 1.2 and 1.3 cause a number >> of TCK failures, so I've been looking at fixing them. >> Here's a quick summary. >> * the single-bundle distro (which is used with the TCK) now includes >> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't >> export/import the types defined in there which meant that these types >> existed twice in the VM, once inside the single bundle distro and once >> outside. This caused issues with ConfigAdmin and some event types >> since communication with the outside world wasn't possible with these >> types any more. >> I fixed this for the single-bundle distro (it doesn't apply to the >> multi-bundle distro). >> * ExportReferenceImpl, which is really a wrapper, was used in a Map >> but missing hashCode and equals(). I added these. >> * There were some issues around close() calls not completely properly >> behaving, I fixed those >> * RemoteServiceAdminCore was putting objects of the wrong type in the >> collection returned by exportService() >> >> Some more changes may be needed in order to fully pass the TCK, but >> I've committed the above in r1290914. >> > Cool, guess you are thinking about 1.3.1 already :-) > Cheers, Sergey > >> Cheers, >> >> David > >
