I created a lyo test application with the OSLC Refimpl Github as a base. I have it running in DNG so far. I can see my custom iframe with all my test objects when I try to link. Upon choosing an object and clicking on “OK” the window in DNG closes. A popup appears which says “Save links” and then nothing happens. There are no links set in DNG or my application. What causes this? I dont see any errors in my browser console. I researched a bit and found this: DOORS Lyo incompatibility
But I am not sure your problem is the same as the one reported in the topic you linked.
Ultimately, we’ll need a bit more to investigate, such as RefImpl logs and DNG server logs if you don’t see any problems in the browser console. I recall having to use buger/goreplay in the past to see the exact request/response bodies between ELM tools and connected OSLC friends. Here’s the command from my notes that I used:
sudo gor --input-raw 127.0.0.1:8180 \
--input-raw-track-response \
--output-file=requests_jazz.gor -verbose 10
I noticed that I am getting an error in my console. “Blocked autofocusing on a input element in a cross-origin subframe.” Is this something which needs fixing? The iframe seems fine.
I also tried the creation dialog inside DNG and while this one does not create a link either, the object itself is being created. So communication in that regard works. Am I possibly missing some function in the refImpl, which is supposed to create the link? The ResourcesFactory has two functions called “constructLinkForRequirement” which are never used anywhere. Or is it the updateRequirement function, which creates the Link?
Depending on what kind of link you are trying to create, there are different approaches to saving the link based on link ownership. Generally DNG doesn’t own any CM, QM or AM links, but expects the link to be stored on the other end. This could require the selection or creation dialog to do a GET on the resource, add the link assertion, and then do a PUT.
Weird, linking with Change Tickets does work. Just the links inside of modules do not work. Also the change ticket window contains the headline of the Selector iFrame, the module does not?
Does this have something to do with the global config in RM? The CCM does not have one and the selector uri in CCM stops at /selector, while in RM it is /selector?oslc.context=…
I did add a QName parameter (globalConfigurationAware) to my serviceprovider prior to adding it to DNG, otherwise it would show an error.
@andrew@jamsden I figured out, that you can link RM only via “References” Link with other objects of external RM. That way it was possible to set a link. However the oslc.domain.Requriement does not seem to include “ReferencedBy” so that the link on the other side is visible too. Is that intentional?
Regarding the inverse links like X oslc_rm:constraints Y vs Y oslc_rm:constrainedBy X, there is a bit of a complicated relationship with them in OSLC. OSLC OP considered deprecating them all at one point of time but hopefully this decision is now reversed. @jamsden should know more.
Regarding referencedBy link type specifically, I don’t think it’s part of the OSLC CM standard but specific to IBM ELM/Jazz.
The Requirements Domain does not include the “ReferencedBy” property indeed.
See picture below for current model.
But that does not hinder you from modelling hte Jazz domain in LyoDesigner. I believe this would be a good contribution since I am sure many others would have similar needs.
@jad
That depends. Since I created my application with the oslc-refimpl as a base, I somehow need to integrate the “referencedby” attribute to my “Requirement” Object, so that the link is set both ways, similar to how it is already done with the existing properties. What would the easiest way be to extend the Requirements Domain? A subclass which includes this “referencedBy” property as a new hashset? Or is there an easier or more logical way?
Here is also the IBM table which describes this “References” links for future users, who find this thread: IBM Documentation
@LyoUser the RefImpl uses Lyo Designer to generate most of its code, so it makes sense to adjust the model a bit and regenerate the code (docs). The RefImpl modelling project depends on the OSLC domain models provided in Lyo, therefore you’d need to edit them if you’re after the simplest way to add a referencedBy property.
Lyo Designer is based on quite an advanced generation framework that preserves all modifications when you run it again. This is nothing like “Spring Boot starter”, Swagger/OpenAPI, or Rails generators.
Of course, you can subclass a Requirement class into a JazzRequirement and add a getter/setter pair with the right OSLC annotations (that’s all it takes to make POJOs that marshal cleanly into OSLC RDF graphs) but then all REST endpoint methods would need to be updated. Furthermore, you’d be making changes to the code outside protected code blocks (namely, REST handler methods) that are not touched when code is regenerated, which would make regeneration harder. Because now you’d be making changes that the generator would overwrite.
We already made changes, which the generator overrides, due to refactoring a lot of stuff, including folder names I think the easiest way for us is to create a subclass. I just created one and replace the old domain class “Requirement” with the subclass. The server is running fine. To make it possible to set links in both directions, we need to replace the “@OSLCPropertyDefinition” of “referencedBy” with the fitting namespace. Is that correct? So instead of “open-services.net” it has to be something with “jazz.net” ?
By the way, we are happy to take feedback on the default JAX-RS template. If you have any refactorings you’d like to see, we may be able to make them and allow you to take advantage of them in the future versions of Lyo Designer.
@OslcNamespace(Oslc_rmDomainConstants.REQUIREMENT_NAMESPACE)
@OslcName(Oslc_rmDomainConstants.REQUIREMENT_LOCALNAME)
@OslcResourceShape(title = "Requirement Shape", describes = Oslc_rmDomainConstants.REQUIREMENT_TYPE)
public class JazzRequirement
extends Requirement
{
private Set<Link> referencedBy = new HashSet<>();
public JazzRequirement()
{
super();
}
public JazzRequirement(final URI about)
{
super(about);
}
public void addReferencedBy(final Link referencedBy)
{
this.referencedBy.add(referencedBy);
}
@OslcName("referencedBy")
@OslcPropertyDefinition(Oslc_rmVocabularyConstants.REQUIREMENTS_MANAGEMENT_VOCABULARY_NAMSPACE + "referencedBy")
@OslcDescription("The subject is referenced by the object. For example, a user requirement is referenced by another requirement.")
@OslcOccurs(Occurs.ZeroOrMany)
@OslcValueType(ValueType.Resource)
@OslcRepresentation(Representation.Reference)
@OslcReadOnly(false)
public Set<Link> getReferencedBy()
{
return referencedBy;
}
public void getReferencedBy(final Set<Link> referencedBy )
{
this.referencedBy.clear();
if (referencedBy != null)
{
this.referencedBy.addAll(referencedBy);
}
}
Currently my class looks like this. Would this be sufficient to allow for communication or does there need to be a Jazz specific change? The only thing else I did was replace the domain.Requirement class with this one and update the UI with another field for “referencedBy”. Everything seems to work for now, however a link is not yet created when setting a “Reference” link in DNG.
The changes in the refImpl were essentially reducing everything to server-rm and renaming to company specific names. However a nice change for the refImpl would be to add a “Friends” tab similar to DNG in the UI and replacing the GenericAdaptorClient with a fully fledged out one. Since this is not included our next step would be to add one.
I would double check if this is the right prefix. As I wrote before, I think you need a prefix constant equal to http://open-services.net/xmlns/rm/1.0/ instead. Please check some sample output from Jazz.
From what I could find it seems to be “www.purl.org/dc/terms” and then either “references” or “isReferencedBy”. I updated my class accordingly (using Dctermsconstants for the address) and changing “referencedBy” to “isReferencedBy”. Still, DNG does not create the link on the other side. Preview-Frames in DNG do work, so there does not seem to be any kind of restriction regarding communication.
A silly question, but are you sure you are creating/returning instances of JazzRequirement (and not Requirement) now? Does your response now include this new expected property?
From what I can see, your new subclass JazzRequirement is using the same @OslcNamespace, @OslcName, & @OslcResourceShape annotations as Requirement. Can you change these, just to see/confirm that your new changes are being picked up?
