Re: [lyo-dev] Unset system properties

["Jim Amsden" <jamsden@xxxxxxxxxx>]

The oslc4j-bugzilla-sample (I'm trying
to be consistent about using the Maven artifactId to identify these things
instead of the eclipse project name - which no longer shows up in eclipse)
currently runs and integrates with the jazz.net tools without setting these
properties. So they appear to be unused.

For 2.2.0, I suggest we leave this alone,
including the warnings, they don't hurt anything. Then we should explore
the other sample code to see if these properties have been deprecated and
were just never cleaned up. We can decide in a subsequent release how to
effect this deprecation.

There also appears to be some legacy
code in org.eclipse.lyo.server.oauth.core.Application. its login method
is overridden in the CredentialsFilter.init method, but is never called.
Instead the login is actually done in the CredentialsFilter.doFilter method
where OAuth and non-OAuth authentication challenges are managed.



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Andrii Berezovskyi
<andriib@xxxxxx>
To:      
 Eclipse Lyo Dev List
<lyo-dev@xxxxxxxxxxx>
Date:      
 07/11/2017 08:41 AM
Subject:    
   Re: [lyo-dev]
Unset system properties
Sent by:    
   lyo-dev-bounces@xxxxxxxxxxx

---

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#L155Note 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=519418and 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#bootstrappingDiscoverydiscussesthis 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
    
    
    
    
    
    
    

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev