[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [lyo-dev] Unset system properties
|
Thanks for the pointer to the spec, Jim.
I think that the Link header is actually a very good option, very compact and in line with the URI being an identifier and its headers describing the URI itlself. I think there is some kind of pushback in the mainstream dev community for this mechanism. The argument is that most apps will run on somehow constrained environments and might not have full control over headers (e.g. the new https://oslc.github.io/ site :D).
In regard to the discovery of the discovery URI:
* System properties do not seem that bad for the global bootstrapping of the discovery process, so I reverse my opinion on them. They are simple to learn, can be set from anywhere in the code and at the startup. But they are global and can be used hideously deep inside of the codebase (cough, cough, Lyo).
* Alternatives are: ENV variables, JNDI, Consul/Zookeeper, custom config libraries. I won’t go into details, but all of them have some overhead and give you trouble during deployment when you need to override them as well as during the development when you need to stub them out for testing.
So I suggest to keep suggesting better ways in https://bugs.eclipse.org/bugs/show_bug.cgi?id=519418 and make sure the configuration is passed across more explicitly.
–Andrew.
From: Jim Amsden <jamsden@xxxxxxxxxx>
Date: Monday, 10 July 2017 at 17:31
To: Eclipse Lyo Dev List <lyo-dev@xxxxxxxxxxx>
Cc: Andrii Berezovskyi <andriib@xxxxxx>, Jad El-Khoury <jad@xxxxxx>
Subject: RE: Unset system properties
Jad, Andrew,
Just capturing a bit more history and validation on this. OSLC discovery is supported through the ServiceProvicerCatalog and/or using Link header values in OSLC 3.0. These discovery resources or header values might be obtained using a GET on ServiceProviderCatalog URL or HEAD/OPTIONS on an LDPC to get the link headers. The question is, how does a client discover the discovery URI?
http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part2-discovery/oslc-core-v3.0-cs01-part2-discovery.html#bootstrappingDiscoverydiscusses this but provides no normative mechanism.
The jazz.net applications typically use a rootservices document at a known location. This is not part of the OSLC specification, but is implemented in the oslc4j-bugzilla-sample project. This is required to integrate the Bugzilla adapter with the jazz.net applications, as is the OAuth code.
It appears this service provider registry is another way of bootstrapping discovery using system properties that users or administrators can set. I don't know if this works anymore, or is used by any OSLC4J application. Perhaps we should at a minimum make sure it works. We can decide on the appropriate use of system properties for this and other purposes later.
In any case, the warnings seem inappropriate. Clearly the issue is whether the server has sufficient configuration information to be able to support discovery. If it doesn't then that is the error. A warning that a particular approach to discovery that might not even be being used doesn't seem necessary.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad El-Khoury <jad@xxxxxx>
To: Andrii Berezovskyi <andriib@xxxxxx>, Jim Amsden <jamsden@xxxxxxxxxx>
Date: 07/08/2017 01:50 AM
Subject: RE: Unset system properties
________________________________________
Your description Andrii about this registry is similar to my understanding.
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx, www.kth.se
From: Andrii Berezovskyi
Sent: 07 July 2017 22:33
To: Jim Amsden <jamsden@xxxxxxxxxx>; Jad El-Khoury <jad@xxxxxx>
Subject: Re: Unset system properties
AAAGGHH system properties again!
1. We should evaluate a new way to config https://bugs.eclipse.org/bugs/show_bug.cgi?id=519418
2. SP registry predates SP catalog, generator uses the SP catalog resource it generates
It was used in Bugzilla to have something like root URIs in IBM products, I think.
I think we should give up the idea of system-wide property instructing all adaptors in the application server where the SP catalog is.
Generator does not make any use of it, except accidental copypasted code for the “self” URI on SPC page which, I believe, I have removed by a patch long time ago.
And what the bloody #€%! Why do we have oslc4j.client package under oslc4j-wink?
So I believe we should remove the warnings and mark the fields as deprecated.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519419
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519420
–Andrew.
From: Jim Amsden <jamsden@xxxxxxxxxx>
Date: Friday, 7 July 2017 at 21:06
To: Jad El-Khoury <jad@xxxxxx>, Andrii Berezovskyi <andriib@xxxxxx>
Subject: Unset system properties
Jad, Andrew,
Project oslc4j-wink has org.eclipse.lyo.oslc4j.client.ServiceProviderRegistryURIs.java which defines and checks to see if these two system properties are set:
private static final String SYSTEM_PROPERTY_NAME_REGISTRY_URI = ServiceProviderRegistryURIs.class.getPackage().getName() + ".registryuri";
private static final String SYSTEM_PROPERTY_NAME_UI_URI = ServiceProviderRegistryURIs.class.getPackage().getName() + ".uiuri";
The codegenerator is not generating any code to set these properties, so the defaults are taken and I get the following warnings when the server runs:
WARNING: System property 'org.eclipse.lyo.oslc4j.client.registryuri' not set. Using calculated value 'http://jrawork:8080/OSLC4JRegistry/catalog/singleton'
WARNING: System property 'org.eclipse.lyo.oslc4j.client.uiuri' not set. Using calculated value 'http://jrawork:8080/OSLC4JUI'
These warnings don't seem to cause any problem. Do you know what these are for and should they be set?
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
