I also created a branch of my project which uses the local version of CXF 3.3.0-SNAPSHOT with my changes in it. I am able to use ContainerRequestContext and I no longer have to set the property! W00T!
https://github.com/jaxxy-rs/jaxxy/tree/cxf-3.3.0-snapshot Thanks for taking the time to help, Andy! On Thu, Sep 13, 2018 at 6:50 PM James Carman <[email protected]> wrote: > Andy, I've submitted a PR for the splitting part (not the changing the > defaults): > > https://github.com/apache/cxf/pull/445 > > There was some funky stuff going on in there with how it nulls out the > existing HttpHeaders object on the ContainerRequestContextImpl. I wasn't > quite sure why that was being done and changing it didn't break any tests. > Hope this will work. Let me know. > > > On Thu, Sep 13, 2018 at 3:41 PM Andy McCright <[email protected]> > wrote: > >> By all means! :) Let me know once you've got something ready for review. >> >> Thanks! >> >> On Thu, Sep 13, 2018 at 2:31 PM James Carman <[email protected]> >> wrote: >> >> > Yeah, no problem. You mind if I take a stab at the PR? >> > >> > On Thu, Sep 13, 2018 at 2:20 PM Andy McCright < >> [email protected] >> > > >> > wrote: >> > >> > > So it sounds like there are two issues here: >> > > >> > > 1) The "org.apache.cxf.http.header.split" property is applied >> > > inconsistently - it works correctly in HttpHeaders, but not in >> > > ContainerRequestContext.getHeaders(). This seems like a bug to me. >> > > 2) The value for this property should be true by default - this >> doesn't >> > > seem clear in the spec, but I tend to agree with you that it ought to >> be >> > > split by default. Unless somebody says otherwise, I don't think we >> > should >> > > change the default behavior in the released streams (3.1.X and 3.2.X). >> > But >> > > I think it would be fine to change the default behavior in the 3.3.X >> > > (master) stream. >> > > >> > > Would you open up a JIRA for these issues? We can probably use one >> JIRA >> > > for both and just mention that the default behavior will remain the >> same >> > in >> > > the service releases. >> > > >> > > Thanks, Andy >> > > >> > > On Wed, Sep 12, 2018 at 5:51 PM James Carman < >> [email protected] >> > > >> > > wrote: >> > > >> > > > Well, it still doesn't even work consistently . Even with that >> property >> > > > set, ContainerRequestContext.getHeaders() returns concatenated >> values. >> > > > HttpHeaders (injected via @Context) does not. >> > > > >> > > > What I'm trying to determine is if this really is expected behavior. >> > > I've >> > > > looked at the spec and can't really find where it says these should >> be >> > > > concatenated values. I'm sure I missed something. >> > > > >> > > > I actually don't typically usually use an Application class in my >> > JAX-RS >> > > > projects, at least not with CXF. I get that's the only really >> portable >> > > way >> > > > to register stuff, but I typically don't. >> > > > >> > > > >> > > > On Wed, Sep 12, 2018 at 6:38 PM Andy McCright < >> > > [email protected] >> > > > > >> > > > wrote: >> > > > >> > > > > Hi James, >> > > > > >> > > > > Just speculating here... what if you add this code to your >> > Application >> > > > > subclass: >> > > > > >> > > > > @Override >> > > > > >> > > > > public Map<String, Object> getProperties() { >> > > > > >> > > > > Map<String,Object> props = new HashMap<>(); >> > > > > >> > > > > props.put("org.apache.cxf.http.header.split", true); >> > > > > >> > > > > return props; >> > > > > >> > > > > } >> > > > > >> > > > > >> > > > > I think that might a more portable approach that does the same >> > thing... >> > > > > >> > > > > >> > > > > Hope this helps, >> > > > > >> > > > > >> > > > > Andy >> > > > > >> > > > > On Sat, Sep 8, 2018 at 8:00 AM James Carman < >> > > [email protected]> >> > > > > wrote: >> > > > > >> > > > > > No thoughts on this one? I'd like to keep my implementation >> very >> > > > > "vanilla" >> > > > > > with respect to the JAX-RS spec, but I am using CXF as my JAX-RS >> > > > > > implementation during testing. I just want to make sure I'm not >> > > doing >> > > > > any >> > > > > > unnecessary CXF-specific work-arounds in my code. If we were to >> > > "fix" >> > > > > it, >> > > > > > though, it might introduce a change in behavior and that's not >> good >> > > > > > either. >> > > > > > >> > > > > > On Fri, Aug 31, 2018 at 8:49 AM James Carman < >> > > > [email protected] >> > > > > > >> > > > > > wrote: >> > > > > > >> > > > > > > I think I misspoke here. Even if I set the header split >> > property, >> > > > the >> > > > > > > ContainerRequestContext.getHeaders() still returns >> concatenated >> > > > values, >> > > > > > but >> > > > > > > if I use a @Context annotation to inject HttpHeaders, I can >> get >> > > back >> > > > > the >> > > > > > > header values individually (not concatenated). If I take away >> > the >> > > > > header >> > > > > > > split property, then HttpHeaders starts returning concatenated >> > > > headers. >> > > > > > I >> > > > > > > probably should have said so in my original email, but I'm >> using >> > > CXF >> > > > > > > v3.2.6. >> > > > > > > >> > > > > > > On Fri, Aug 31, 2018 at 8:35 AM James Carman < >> > > > > [email protected] >> > > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > >> I found a thread about this topic from 2015, but it seems to >> be >> > > > > talking >> > > > > > >> about client-side: >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> http://mail-archives.apache.org/mod_mbox/cxf-users/201504.mbox/%[email protected]%3E >> > > > > > >> >> > > > > > >> I'm writing a CorsFilter and I need to get the list of >> > > > > > >> Access-Control-Request-Headers to evaluate them. If I do >> this: >> > > > > > >> >> > > > > > >> JAXRSServerFactoryBean factory = new >> JAXRSServerFactoryBean(); >> > > > > > >> >> > > factory.getProperties(true).put("org.apache.cxf.http.header.split", >> > > > > > true); >> > > > > > >> >> > > > > > >> then everything works fine. However, it seems odd (even >> after >> > > > reading >> > > > > > >> the referred javadocs) that the expected behavior would be >> > > > > concatenated >> > > > > > >> values. The return type is MultivaluedMap<String,String>. >> If >> > the >> > > > > > intent >> > > > > > >> was that there would always be only one "value" in the map >> for >> > > each >> > > > > key, >> > > > > > >> then why would they say to return a >> > MultivaluedMap<String,String>? >> > > > > > Perhaps >> > > > > > >> this is a problem with the spec or something, but I can't >> really >> > > see >> > > > > in >> > > > > > the >> > > > > > >> spec where it specifically says to return the values this >> way. >> > It >> > > > > does >> > > > > > >> have a @see pointing to the getHeaderString(String), where it >> > does >> > > > say >> > > > > > >> they'd be concatenated. I'm sure I'm missing something here. >> > > > > Thoughts? >> > > > > > >> >> > > > > > >> Thanks, >> > > > > > >> >> > > > > > >> James >> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> >
