In the OSLC implementation of IBM Jazz CLM, there are two ways to specify the configuration context, that is, the URI of the configuration the request uses: Using the header “Configuration-Context” or appending the query parameter “oslc_config.context” to the URL.
This last way is not recommended in IBM Jazz CLM since it is not homogeneous between the core CLM apps. For example, in DNG, adding this causes an error when requesting a resource, but in RQM it works as expected.
It doesn’t seem possible to add this header inside the OslcClient class (/src/main/java/org/eclipse/lyo/oslc4j/client/OslcClient.java), other than in the getResource method.
Inside the OSLC Query related classes there doesn’t seem to be a way to add headers or append the “oslc_config.context” parameter.
In the RmUtil class (/src/main/java/org/eclipse/lyo/oslc4j/client/resources/RmUtil.java) the “typeURI” request fails if the type is in another Configuration
Are OSLC Configurations supported in the OSLC4J Client?
A little bit related to this, there are times where I need to unset the “OSLC-Core” header to access a particular API to manage modules in DNG https://jazz.net/wiki/bin/view/Main/DNGModuleApiOverview. Specifically, instead of that header, I need to set one as “DoorsRP-Request-Type” with value “public 2.0”. Is there a way to do this?
Thanks for a careful analysis and a thorough investigation! We will try to address the issues but can’t promise any hard timeline. Officially there is no special support for IBM products in Lyo and Config Management is not a finalised spec yet.
I will talk to IBM experts on Thursday during our regular open project call. If you have pull requests handy, I will be glad to review them and see to that they are merged.
Headers in the Client shall be easy to fix.
Query param might take a bit of thinking to add nicely.
I have no idea about the RmUtil fault. Please open an issue with the stack trace or any form of the log, please.
eclipse/Lyo OSLC java client doesn’t currently support configurations. The reasons are that there isn’t yet a published Project Specification Draft that we could rely on, and there hasn’t been much demand. We should probably address this with an additional argument to the appropriate API methods, and avoid exposing the HTTP details.
To start this process, we should have some typical use cases for how the client would use a configuration context. For example, would the configuration context be associated with the creation of the client, specified as part of the server URI, and user credentials, and then used for all subsequent accesses (probably)? Would getter and setter methods be needed to change the configuration context (probably)? Or would/should that require a different connection (probably not)? Or should every method require and additional configuration context parameter (probably not)?
Clients are likely to pick a configuration context, and then work in that context for a while. They could, but probably aren’t that likely to jump from one configuration to another accessing data.
In order to test this, we would need access to an OSLC server that supports configuration management. That could be the jazz.net apps. But that raises the question about server compatibility with an as yet unpublished standard, and the need to deal with rootservices, authentication, consumer/friend connections using OAuth 1.0a, artifact container (e.g., project area) associations, etc. in order to make the connection and access anything.
So this is going to take some work. We should see how much interest there is, and see if there are new committers willing to contribute.
I have gone ahead and created a pull request to the repository with an initial approach to handle configurations per request and also adding the “oslc_config.context” parameter in the OSLC Query. I used method overloading to preserve the current method signatures.
I’ll appreciate any feedback you have on it.
I tested these modifications in the project that originated my original post, and it passes all tests.
I agree that a more thorough analysis must be done regarding the use cases and the existing design to incorporate this feature appropriately in the client as @jamsden pointed out. The modifications I implemented in the pull request are just enough for my particular case.