[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [lyo-dev] Jersey and Wink support in Lyo
|
Jad,Thanks for all
this great work. I'll look at OslcClient constructors tomorrow and see
what I can come up with based on your example.Jim Amsden, Senior
Technical Staff MemberOSLC and Linked Lifecycle
Data919-525-6575From:
Jad
El-Khoury <jad@xxxxxx>To:
Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>Date:
11/05/2018
05:23 PMSubject:
Re:
[lyo-dev] Jersey and Wink support in LyoSent
by: lyo-dev-bounces@xxxxxxxxxxx
Pleasure
Not
that I know what it all means, but I found a lot of meat on this thread.
It’s got all the keywords SSLContext, TrustManager, HostnameVerifier,
X509TrustManager that are in the deprecated code in the OslcClient
class.
https://stackoverflow.com/questions/2145431/https-using-jersey-client
But
it’s all Jersey stuff. So, can/should we leave it all outside of Lyo,
and simply expect the user to pass us a ClientBuilder and/or HttpClient?
Now
I’ve told you all I know.
______________________________
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:lyo-dev-bounces@xxxxxxxxxxx [mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrii Berezovskyi
Sent: 05 November 2018 23:09
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] Jersey and Wink support in Lyo
In
other words, Jad did all the cleanup and did quite a bit work! Thank you
:)
--
/Andrew
On
Mon, Nov 5, 2018 at 11:02 PM +0100, "Jad El-Khoury" <jad@xxxxxx>
wrote:
Jim
Seem
logical to answer your questions backwards.
>To
answer this, we need an example of an OSLC server built with Jersey and
not Wink.
The
adaptor "adaptor-rm-webapp", from the branch https://github.com/OSLC/lyo-adaptor-sample-modelling/tree/F_jax-rs-2.0is such an OSLC Server built with Jersey. Of course, unlike Bugzilla, it
does not connect to a real tool, but that does not matter now.
Note
that the code changes to migrate from 2.4.0 to to support jax-rs2.0 is
quite little, so it is going to be very smooth to migrate the server code
(Generator, or otherwise).
>The
question is: can oslc-java-client apps depending on Wink and oslc-core
2.4.0 make REST API calls to an OSLC server that is not implemented using
Wink?
Of
course they can, otherwise the whole REST idea falls apart.
But
we are aiming to migrate both Core & Client to only rely on Jax-RS
2.0 API (No Jersey, nor Wink implementations).
If
Lyo is to support an application that needs to be both Server and Client,
we cannot keep lyo.client being based on Wink, while Lyo.server is based
on Jersey. So, we do need to migrate lyo.Client to JAX-RS 2.0.
>Rebuilding
this on HttpClient, and cleaning up the deprecated code in the client and
core source would probably be quite a bit of work.
Andrii
is implying that we cannot have control over the HttpClient with if we
are to reply only on the JAX-RS 2.0 API. This is offered by the implementations
(Jersey, RESTEasy, etc). I can only confirm this because I failed miserably
to make it work over the last few days.
So,
my hypothesis now is that we don’t need to clean up the deprecated code
in the client. We just throw it out. This code assumes the Wink implementation.
We
instead expect the code that calls the OslcClient constructor (which will
be based on Jersey, RESTEasy, etc) to provide us with such a configuration.
To
test this hypothesis, I have actually managed to migrate the OslcClient
code from Wink to JAX-RS 2.0, plus the latest Apache httpClient versions!
To
see it in action, run the client application “TestRMSampleForJAXRS2”
under oslc-java-samples against the “adaptor-rm-webapp” mentioned above.
(1)
You would need to delete the other code under oslc-java-samples to make
it build for now.
(2)
The code a modification of that from GenericCMSample
(3)
Run with the arguments
-url
http://localhost:8086/adaptor-rm/services/catalog/singleton-providerTitle "Service Provider 'A sample RM Service Provider 1'"
What
is left? The OslcClient constructors. How should they be defined to allow
for most flexible configuration?
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
From:lyo-dev-bounces@xxxxxxxxxxx[mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Amsden
Sent: 05 November 2018 19:56
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] Jersey and Wink support in Lyo
Here's
the status of the oslc-java-client and oslc-java-samples maven projects:
I have built these projects using 2.4.0-SNAPSHOT, and run one of the samples
against an RTC server. It all works. So, so far, no changes to oslc-core
have broken the Java client.
Currently using org.apache.httpcomponents:httpclient version 4.5.1 while
the latest is 4.5.6.
There's lots of deprecated code around HttpClient use that probably should
be cleaned up, but this could possibly be deferred.
These projects do have dependencies on Wink:
<dependency>
<groupId>org.apache.wink</groupId>
<artifactId>wink-client</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>org.apache.wink</groupId>
<artifactId>wink-client-apache-httpclient</artifactId>
<version>1.4</version>
</dependency>
These are used throughout the oslc-java-client for making REST calls and
processing the results.
Rebuilding this on HttpClient, and cleaning up the deprecated code in the
client and core source would probably be quite a bit of work.
The question is: can oslc-java-client apps depending on Wink and oslc-core
2.4.0 make REST API calls to an OSLC server that is not implemented using
Wink?
To answer this, we need an example of an OSLC server built with Jersey
and not Wink. Then we would need to develop a new oslc-java-samples app
that attempted to access this using REST API calls that depend on wink-client.
We might be able to use the GenericCMample.java since I think this runs
against Bugzilla sample server.
A Jersey based OSLC server could be the migrated doc/org.eclipse.lyo.oslc4j.bugzilla.
Or we could use the Bugzilla example generated from an updated Lyo Designer.
Do we have that? Or do we have any OSLC Jersey-based server?
I'm guessing this would work and if so, would be an acceptable solution
for 2.4.0. But it will take some time to scaffold something to test it.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Andrii
Berezovskyi <andriib@xxxxxx>
To: Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 11/04/2018
07:59 AM
Subject: Re:
[lyo-dev] Jersey and Wink support in Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
But we are talking about a JAX-RS client API, correct?
As far as I understand, that API does not offer control over the redirection
policy: https://stackoverflow.com/questions/21778393/jersey-jax-rs-client-2-5-follow-redirect#25301746
--
/Andrew
On Sun, Nov 4, 2018 at 10:27 AM +0100, "Jad El-Khoury" <jad@xxxxxx>
wrote:
Jim
We
can of course complement with new oslcClient constructors. At the moment,
I am stuck is in the basics of the current constructor below.
In
short, how to create an OSLCClient with Apache Http Client, with the necessary
redirect & SSL support.
I
can create with default Apache client. But not sure (nor can I test) the
specific of the code below.
/**
* Initialize a new OslcClient using an Apache Http
Components 4 Http client and configuration.
* Use the provided TrustManagers and X509HostnameVerifiers
instead of the defaults which do no verification;
*/
publicOslcClient(TrustManager
[] trustManagers,
X509HostnameVerifier hostnameVerifier)
{
httpClient=
newDefaultHttpClient(newThreadSafeClientConnManager());
httpClient.setRedirectStrategy(newRedirectStrategy()
{
@Override
publicHttpUriRequest
getRedirect(HttpRequest request,
HttpResponse response,
HttpContext context)
{
returnnull;
}
@Override
publicbooleanisRedirected(HttpRequest
request,
HttpResponse response,
HttpContext context)
{
ureturnfalse;
}
});
this.trustManagers=
trustManagers;
this.hostnameVerifier=
hostnameVerifier;
setupSSLSupport();
clientPool=
newOAuthHttpPool();
clientConfig=
newApacheHttpClientConfig(httpClient);
…
}
______________________________
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:lyo-dev-bounces@xxxxxxxxxxx
[mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Amsden
Sent: 02 November 2018 18:34
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] Jersey and Wink support in Lyo
Here's
what I did:
client = new OslcClient();
// Add a receptor to set the Authorization header as a default header
for all requests
// This is using deprecated code because OSLC4J OslcClient needs
to be updated at some point
Header header = new BasicHeader(HttpHeaders.AUTHORIZATION, "Basic
"+Base64.encode((userId+":"+password).getBytes()));
List<Header> headers = new ArrayList<Header>();
headers.add(header);
RequestDefaultHeaders defaultHeaders = new RequestDefaultHeaders(headers);
((DefaultHttpClient)client.getHttpClient()).addRequestInterceptor(defaultHeaders);
String catalogUrl = serverUrl + "/services/catalog/singleton";
String orgTitle = "IoT Platform Service Provider: "+orgId+"(/"+orgId+")";
String serviceProviderUrl = client.lookupServiceProviderUrl(catalogUrl,
orgTitle);
queryCapability = client.lookupQueryCapability(serviceProviderUrl,
Oslc_iotDomainConstants.IOT_PLATFORM_NAMSPACE,
Oslc_iotDomainConstants.DEVICETYPE_TYPE);
creationFactory = client.lookupCreationFactory(serviceProviderUrl,
Oslc_iotDomainConstants.IOT_PLATFORM_NAMSPACE,
Oslc_iotDomainConstants.DEVICETYPE_TYPE);
I needed to do this to handle login. Maybe we need an OslcClient(userid,
password) constructor. I used the above as a work around.
This is using old, deprecated HttpClient code.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad
El-Khoury <jad@xxxxxx>
To: Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 11/02/2018
11:23 AM
Subject: Re:
[lyo-dev] Jersey and Wink support in Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
I see.
What we really need help with is to work out how to configure oslcClient
with ApacheClient. The constructor for OslcClient.
I have the feeling this (very old deprecated) part of the code is for jazz-related
needs.
Anyone on this mailing list that can help out?
/Jad
On 2 Nov 2018, at 15:21, Nicholas Crossley <nick_crossley@xxxxxxxxxx>
wrote:
I'd like to, but I'm currently assigned to other work, and not sure if/when
I'll be able to get back to more active involvement with OSLC & Lyo.
Nick.
From: Jad
El-Khoury <jad@xxxxxx>
To: Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 10/20/2018
01:58 AM
Subject: Re:
[lyo-dev] Jersey and Wink support in Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Let’s aim for a Jersey/wink-free SDK then.
I will need to prioritize the Core part, which client depends on anyway.
Nick! Would you be able to help out with Client eventually ?
Jad
On 19 Oct 2018, at 18:43, Nicholas Crossley <nick_crossley@xxxxxxxxxx>
wrote:
As prominently a client developer, I'd love Lyo to get to the stage where
the client library dependencies were much smaller and simpler - today with
Wink et al they are huge. In other words, my personal preference would
be just the same as Andrews:
"Andrew hat:
migrate everything to raw JAX-RS 2.0 and make sure no Jersey-specific stuff
is introduced."
Nick.
From: Andrii
Berezovskyi <andriib@xxxxxx>
To: Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 10/19/2018
08:39 AM
Subject: Re:
[lyo-dev] Jersey and Wink support in Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Well, we can create new packages for the JAX-RS 2.0 migration and deprecate
the 1.1 packages and mark them for removal in Lyo 3.0. This way the client
& legacy apps can still depend on Wink while the generator can migrate
over to use the JAX-RS 2.0 compliant deps.
/A
Den 2018-10-19 16:01 skrev "Jad El-Khoury" <jad@xxxxxx>
följande:
Hi
I wanted to suggested we can wait with migrating oslc.client. This would
mean that one can run oslc servers with jersey 2.0, and oslc clients with
wink 1.0. (but not together I guess)
But that is not an option, since oslc.client has a dependency on oslc.core
☹
Assuming I can go ahead to put some more effort for this migration, let’s
start a branch to experiment and find out what the best options are.
Andrii! I am trying to decipher your notes! So once I have something going,
I can share a working example to get going with.
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,
https://www.kth.se/profile/jad
From: Andrii Berezovskyi
Sent: Friday, 19 October 2018 15:32
To: Jim Amsden <jamsden@xxxxxxxxxx>
Cc: Jad El-Khoury <jad@xxxxxx>;
Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>;
'Khatri Yash' <yash.khatri@xxxxxxxxxx>
Subject: Re: Jersey and Wink support in Lyo
Jim,
Glad we are thinking alike.
- Yes, the
REST API shall not change in any way.
- Strictly
speaking, JAX-RS 1.1 did not have a client spec. Wink Client is our biggest
liability ATM.
- There were
problems with resource shapes on the server side. I did not get the client
to work at all.
I shared the notes with Jad & Yash, they were pretty messy. Maybe they
can repost them in lyo-dev if they get a chance to follow them?
/A
Den 2018-10-19 15:14 skrev "Jim Amsden" <jamsden@xxxxxxxxxx>
följande:
Andrew,
I like how you're thinking on this. A few questions:
1. For servers, will switching to JAX-RS 2.0 have any impact at the REST
API that would impact existing HTTP client applications? That is, would
only the server implementation change, and not the actual HTTP REST API?
2. For existing JAX-RS 1.0 clients: will they still work with any Lyo OSLC
server, regardless of Wink or Jersey implementation?
3. If there are incompatibilities, what are they? I'm hoping the client
and server APIs could be migrated or at least used independently.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Andrii
Berezovskyi <andriib@xxxxxx>
To: Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Cc: Jad
El-Khoury <jad@xxxxxx>,
Jim Amsden <jamsden@xxxxxxxxxx>,
'Khatri Yash' <yash.khatri@xxxxxxxxxx>
Date: 10/19/2018
07:24 AM
Subject: Re:
Jersey and Wink support in Lyo
Jad,
Let me give two answers. Andrew hat: migrate everything to raw JAX-RS 2.0
and make sure no Jersey-specific stuff is introduced. Allow Lyo Core to
be used with any JAX-RS framework. Make Lyo Designer emit Jersey based
adaptors. Ask Ricardo Javier, for example, to test Lyo Core with RESTEasy/Wildfly/Thorntail.
Lyo project lead hat: do whatever users of Lyo would prefer, but given
that I managed to run a Lyo adaptor Jersey pretty easily once (partially),
it should be straightforward to move directly to JAX-RS 2.0. If you want
to play it safe, we can migrate to the old Jersey (1.19) that supports
JAX-RS 1.1. Also, migrate Lyo Client later.
/A
Den 2018-10-19 11:44 skrev "Jad El-Khoury" <jad@xxxxxx>
följande:
Hej
What’s your take on supporting Jersey (JAX-RS 2.0) in Lyo?
I see 2 alternatives:
- We keep Wink
(JAX-RS 1.0) as well as Jersey (More complicated, but we keep Lyo compatible
for old users)
- We migrate
from Wink to Jersey. (Less code for us to maintain, but will force
users to also migrate to Jersey).
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,
https://www.kth.se/profile/jad
_______________________________________________
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
_______________________________________________
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_______________________________________________
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
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev _______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev