@isccarrasco thank you for the PR! Looks good to me but we need to test it because I forgot the difference between the two arguments and we should be able to merge it soon.

Mario, I just took a look at how this code is used now. Sadly, we don't have any test coverage for this. Right now the adaptors during initialization provide the base URI via baseUri and set genericBaseUri to an empty string "". The dialogUri is a relative URI path fragment that is then concatenated with the base URI.

Instead, the genericBaseUri is used to auto-generate the URIs of the dialogs with the dialogUri property. I don't think there is any code known to me that relies on "generic" URIs because they still have to point to existing pages that serve dialogs (and in that case it would not hurt to give a proper dialog URI path fragment).

How do you hit this problem? Our code calls ServiceProviderFactory.createServiceProvider with a proper baseUri, empty genericBaseUri, and the Dialog annotation looks like this:

@org.eclipse.lyo.oslc4j.core.annotation.OslcDialog(resourceTypes={"http://open-services.net/ns/rm#Requirement"}, usages={}, label="SelectionDialog1", hintWidth="0px", hintHeight="0px", title="SelectionDialog1", uri="requirements/selector")

I am guessing you are passing the full URI to dialogUri? I can totally see how could this be confusing. I think the reason the implementation is done this way is because you cannot use non-const expressions in @Dialog annotations. Maybe we should change the parameter name to relativeUri instead of uri or add a check for URI being absolute and then ignore both the base URI and the "generic" base URI.

Also, how are you using those "generic" base URIs? I am thinking to deprecate URI guessing for dialogs that are not fully annotated altogether to avoid confusion.

CC @jadelkhoury

Hi

I just tried to walk through the code. I am not sure what this change can solve. Can you please Mario? I can see though how this can be problematic since the genericBaseUri seem to have a whole different purpose. Making the suggested change will certainly change the current behaviour.

as suggested by @berezovskyi , will not passing the baseURI as you expect it to be do the job?

So, I normally set the baseUri to OSLC4JUtils.getServletURI() to make it refer to the same base as hte rest of the OSLC server. But I cannot see any thing hindering passing any other parameter.

Can one of the admins verify this patch?

add to whitelist

I removed the 5.0 milestone not to block the release.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

Closing this PR without merging. @isccarrasco if you still have this problem, please reply to #236 (comment) and we will consider reopening it. Thank you!