1
Vote

Please readd FormatterContext

description

Hello there,

today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.

Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.

Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.

Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.

At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.

With best regards,
Kay

comments

kichalla wrote Jun 6, 2012 at 10:26 PM

  • Are you trying to access the incoming Request while trying to Read/Write in a formatter?
  • GetPerRequestFormatterInstance is only called on the Response Write side.
  • Could you use Content-Type's Parameter collection to stick in version information?
    Example: Content-Type : application/abc; version=1.5
  • During Read/Write of formatters, we provide HttpContentHeaders which would give you access to Content-Type and other content headers like Content-Language...can you use this Content-Language header for your scenario?

psewar wrote Jun 7, 2012 at 1:38 AM

Yes we need especially the HttpContext from the HttpRequestMessage properties.

I read that the GetPerRequestFormatterInstance is only called in the Write side, so it's not a really satisfying solution.

We use a Content-Type like the one you mentioned, it looks like this:
application/vnd.interhome.api-ipad-v1+xml

Yes those information already help a lot for the localizing stuff. But there is still the problem with the SAP Connector which needs a HttpContext.Current set, else it will throw an error while trying to read from the config file. I know that is bad coding from SAP, but sadly we can not change it.
So during the Beta I was at least able to read the HttpContext out of the FormatterContext, which is not possible anymore.

Also it looks like there are problems with using log4net without any sort of Context. As log4net either uses a ThreadContext or GlobalContext which are not reliable in a multithreaded environment. So the more or less official workaround was to store the information in the HttpContext.

Best regards,
Kay

danroth27 wrote Jun 7, 2012 at 11:06 PM

Why isn't HttpContext.Current already set for your scenario?

psewar wrote Jun 11, 2012 at 6:59 AM

If the HttpContext.Current would be set fron the WebApi we would not have to care about it. But as the WebAPI does not seem to set it by itself we had to implement a workaround where we set it b ourself with the diffferent Contexts available.

BradWilson wrote Jun 11, 2012 at 7:29 AM

HttpContext.Current is tied to the ASP.NET runtime. Writing Web API code that uses it will mean your application will only be able to run under ASP.NET.

That said, there's no reason HttpContext.Current should ever be null when you're running inside of ASP.NET, unless you've created a new thread (directly or indirectly) without preserving the synchronization context appropriately. Do you have any threading code (including any calls to Task.Factory.CreateNew) that don't preserve the sync context?

psewar wrote Jul 1, 2012 at 10:25 AM

Hey Brad,

you where right the StartNew on the TaskFactory was the problem that the HttpContext was not set.
Perhaps it would be a good Idea to implement an overloaded TaskFactory in the WebApi which will take care that the Context will still be set if you create a new Task?

But anyway with some more workarounds we were able to solve this issue.
While I still think there has been no need to remove the context class and should be readded again, the problem we had could be solved.

I will thank everyone which commented in here.

Best regards,
Kay

Sign in to add a comment or to set email notifications