Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lyo-dev] Unset system properties 
Thanks, Jad,

Indeed, I went a bit off topic. I suggest to remove SYSTEM_PROPERTY_NAME_REGISTRY_URI & SYSTEM_PROPERTY_NAME_UI_URI from OSLC4J until we have a more coherent mechanism. Currently every OSLC adaptor we generate has its own SP catalogue unless the designer explicitly removes it from the adaptor interface diagram. Practically, we will deprecate it in 2.2.x by producing a warning when a client sets it, not the other way around.

Registry URI is used in the original Bugzilla adaptor here: https://github.com/eclipse/lyo.docs/blob/78a125d700bbe8a48dead9f33fbca709a621d116/org.eclipse.lyo.oslc4j.bugzilla/src/main/java/org/eclipse/lyo/oslc4j/bugzilla/BugzillaManager.java#L155 Note that no queries are done to it in order to discover something, it is only set for other adaptors deployed on the same app server to use.


–Andrew.

On 2017-07-11, 13:27, Jad El-Khoury <jad@xxxxxx> wrote:

    There seems to be 2 parallel discussions here. Both relevant, but just to make sure we have some structure to this discussion.
    
    1. 
    Is there a need to maintain and support the 2 system properties SYSTEM_PROPERTY_NAME_REGISTRY_URI & SYSTEM_PROPERTY_NAME_UI_URI ?
    
    These properties are not part of the OSLC standard. But we need to deal with the warning being produced. 
    A. if they are being used, we might as well support them in both the OSLC4J SDK as well as the generator.
    B. If they are not being used, then we should also remove them from the oslc4j-wink project.
    
    Any votes on which way to go? Supporting them in the Generator should not be a big job.
    
    Similar to what is done in the OSLC4JUtils class, maybe we can complement the ServiceProviderRegistryURIs.java class with setters for ServiceProviderRegistryURI & UIURI. This allows the application to set the properties (a) without using system properties (b) without changing current behaviour.
    
    2. 
    What approach to use to set system properties?
    Ideas seem to be collected under https://bugs.eclipse.org/bugs/show_bug.cgi?id=519418.
    
    regards
    ______________________________
    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
    
    
    -----Original Message-----
    From: Andrii Berezovskyi 
    Sent: 11 July 2017 00:56
    To: Jim Amsden; Eclipse Lyo Dev List
    Cc: Jad El-Khoury
    Subject: Re: 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

Back to the top