This problem is related to the new CodecProvider API introduced with #231.
In my application I am finding that, in some flows, the decoding of a JSON Document tries to look up a codec using the workspace URI, which locates a directory, instead of the contextual model URI. Because my codec provider matches on resource URIs (not the workspace location, which may contain heterogeneous resource types), the correct codec is not used.
The problem is that the DICodecsManager implementations of the decode(...) method variants that accept a workspace URI for resolution of proxy URIs relative to the workspace location use this workspace URI to look up the codec to apply. This despite having also the request or socket context in which to find the model URI.
The workspace URI is certain to be the wrong URI to use as the whole point of the CodecProvider API is to support multiple codecs for the same format request/session parameter in a workspace, distinguished by model URI.
This problem is related to the new
CodecProviderAPI introduced with #231.In my application I am finding that, in some flows, the decoding of a JSON Document tries to look up a codec using the workspace URI, which locates a directory, instead of the contextual model URI. Because my codec provider matches on resource URIs (not the workspace location, which may contain heterogeneous resource types), the correct codec is not used.
The problem is that the
DICodecsManagerimplementations of thedecode(...)method variants that accept a workspace URI for resolution of proxy URIs relative to the workspace location use this workspace URI to look up the codec to apply. This despite having also the request or socket context in which to find the model URI.The workspace URI is certain to be the wrong URI to use as the whole point of the
CodecProviderAPI is to support multiple codecs for the sameformatrequest/session parameter in a workspace, distinguished by model URI.