Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lyo-dev] Some questions about the Lyo java client code
Did a Pull just before trying so I do have the latest.

And when retrying I now get 403 both when doing Debug/Run, so some intermittent issue it appears. Will ask some colleague to test to make sure it's not only on my system -- and if not so, then .. file a defect on Lyo or RTC ..?

Rgs,

/N 

On 29 apr 2013, at 17:55, Michael Fiedler <fiedler.mf@xxxxxxxxx> wrote:

I've seen problems in the past where I had different behavior between debug and non-debug - including getting 403s.   I recently (2 weeks ago) delivered some client changes to improve re-direct handling.  Not sure that is the root of your issue, but it might be worth re-trying on the latest and greatest client code (which also includes the RM resources).

Let us know if that helps at all.

Regards,
Mike


On Mon, Apr 29, 2013 at 11:38 AM, Nils Kronqvist <nissekronqvist@xxxxxxxxxxx> wrote:
Hi, and thanks for comments!

Great wrt the Requirement contribution - thanks!

Wrt create of a RTC WI; found the issue, but can't explain .. When not running in the debugger (i.e. using Run) it's working fine .. but when in Debug I get 403. Now against a sandbox of RTC 4.0.3 M3 and using the RTCFormSample latest Lyo code. No change from OOTB example except not adding the link to test case. Might be something obvious I'm missing ..?

Rgs,

/N


On 29 apr 2013, at 16:51, Michael Fiedler <fiedler.mf@xxxxxxxxx> wrote:

Hi,   See comments inline.


On Fri, Apr 26, 2013 at 5:42 AM, Nils Kronqvist <nissekronqvist@xxxxxxxxxxx> wrote:
Hi,

Some questions / comments from working with the java client code, i.e. org.eclipse.lyo.clients.java ..

1. As described in the examples you can use the ClientResource to retrieve a typed resource, e.g. using code as below:

private static void processCurrentPage(OslcQueryResult result, OslcClient client, boolean asJavaObjects) {
for (String resultsUrl : result.getMembersUrls()) {
System.out.println(resultsUrl);
ClientResponse response = null;
try {
//Get a single artifact by its URL 
response = client.getResource(resultsUrl, OSLCConstants.CT_RDF);
if (response != null) {
//De-serialize it as a Java object 
if (asJavaObjects) {
ChangeRequest cr = response.getEntity(ChangeRequest.class);

However, you need to know the type of the resource before retrieving it, and e.g. the CM spec says for most relations " .... It is likely that the target resource will be anoslc_cm:ChangeRequest but that is not necessarily the case."  If wanting to resolve the resources pointed to by the relations, I guess you can code the assumptions i.e. try typing to the expected class, and handle the (rare?) case of not getting the expected type. Or any other recommended way?


MF>  This would be the recommended way.   Alternatives would involve processing the RDF to make sure you have an rdf:type predicate for the resource type expected.
 
One option I found was as follows: Reading resources as Resource works fine (i.e. as snippet below) - can then access the rdf as raw triplets - working fine, but loosing the ability to update as can't use the wink generated rdf response (right?). Hesitate trying to write a custom MessageBodyWriter ..  

 
MF> Right - to take advantage of Wink you would still have to translate the RDF into a JAX-RS annotated Java object

 
response = client.getResource(resultUrl, OSLCConstants.CT_RDF);
 if (response != null) {
    Object stream = response.getEntity(InputStream.class);
    if (stream instanceof InputStream) {
       Model model = ModelFactory.createDefaultModel();
       model.read((InputStream) stream, null);
       com.hp.hpl.jena.rdf.model.Resource resource = model.getResource(resultUrl)
    }
 }

Looked in Bugzilla, and https://bugs.eclipse.org/bugs/show_bug.cgi?id=375756 pointed me to the JenaModelHelper, so can then read as Resource, check the type info in the Resource - then use the helper to transform to the right class. Seems like OK solution for now.

BTW: The context for the question; I built a simple Eclipse UI for setting up connection to servers, providers and querying -> presenting result in List view and Properties view. And when accessing item in list / property view I like to have generic code not assuming a specific OSLC resource type. Work in progress ..
 

MF> Please consider contributing this as a sample (if you can).
 

2. There is no implementation of the RM resources .. on the todo-list, or any other reason for not including them? E.g. the RRCFormSample the Requirement class is commented out.


MF> RM resources were just committed today and the RRC sample updated.   See:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=406799
 

3. BTW, there are duplicate implementations of the resources in Lyo -- e.g. ChangeRequest is both in OSLC4JChangeManagementCommon and in the org.eclipse.lyo.clients.java -- makes sense to refactor e.g. to have the java client point at the OSLC4JChangeManagementCommon?


MF> Yes, the current situation is bad - we need to refactor to a common package which can be used everywhere.
 

4. When trying to create a RTC WI using the RTCFormSample I get response "403 - Forbidden". Query, and Update (slight change of sample code - updating an item retrieved by query) working OK.

Found some notes e.g. https://jazz.net/forum/questions/98072/x-jazz-csrf-prevent-header-is-required-to-create-a-work-item-via-oslc-on-version-4001?redirect=%2Fforum%2Fquestions%2F98072%2Fx-jazz-csrf-prevent-header-is-required-to-create-a-work-item-via-oslc-on-version-4001 and tried adding header according to recommendation (although note that needed only if access from browser ..?), but no luck. Using latest Lyo code, and RTC 4.0.0.1. Any clues what might be wrong?


MF> I just ran the RTCFormSample on 4.0.3 RC1 and it created the workitem without that header.   What value are you setting for the header - normally it is the JSESSIONID cookie for the Http session.   It would be painful if this is being required, but we could do something in the JazzFormAuthClient to help. 

 
Rgs,

/Nils Kronqvist

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev


_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev


_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev


_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev

Back to the top