5:19 p.m.
At least personally I think the admin client needs some TLC. For example
creating a user requires:
UserRepresentation user = new UserRepresentation();
user.setUsername("user");
Response response = keycloak.realm("realm").users().create(user);
// Retrieve created user id
String path = response.getLocation().getPath();
String id = path.substring(path.lastIndexOf('/') + 1);
// Remember to close the response
response.close();
// Set password
CredentialRepresentation credentials = new
CredentialRepresentation();
credentials.setType(CredentialRepresentation.PASSWORD);
credentials.setValue("password");
keycloak.realm("realm").users().get(id).resetPassword(credentials);
// Add role
RoleRepresentation role =
keycloak.realm("realm").roles().get("role").toRepresentation();
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
That's pretty rubbish right?
In my opinion a lot of the usability issues is caused by directly exposing
interfaces/proxies from RestEasy Client and it would be much better if we
introduced a wrapper around it.
So my questions are:
1) What do we do with regards to admin client? Do we just wrap what we
have, keep it or create a brand new one from scratch?
2) Is it an issue that we require a specific RestEasy version to use the
admin client? This seems a heavy dependency to me, which could conflict
with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
as it should in theory work with any JAX-RS 2 provider.
3) What do we do with current fixes for admin client? Do we merge to master
and 1.9.x or just merge to master?
At least from my POV the answers are:
1) Create wrappers around interfaces/proxies from RestEasy client and not
expose JAX-RS directly through the API as that should be an implementation
detail
2) Use JAX-RS 2 client
3) Merge fixes to both master and 1.9.x (admin client is not supported in
product for now, so it's less risky)
7:31 p.m.
Hi Stian,
First off: I didn't know that Keycloak existed three weeks ago. Much of
what I write might be a result of me being unfamiliar with earlier design
choices. That being said:
Based on the snippet that you provided I'd argue that it is the service,
rather than the admin client, that could/should be improved. When
implementing a (REST) service, it is common to provide a representation as
part of the response to a create (POST) request: the service response
should include the most up-to-date representation of the resource, which
prevents the client from having to reconstruct it (exactly what you're
doing in that snippet), which is tedious, error-prone and lacking the
inclusion of server-generated values. On top of that, if a client needs
multiple requests to recreate a representation, concurrency issues come in
to play. Who's to say that all responses reflect the exact same state,
server sided?
Restructuring the web services could lead to a large change (although
inclusion of representation in responses might be backwards compatible, as
the random sample of services that I checked appear to currently have empty
responses - perhaps the representation could simply 'fit in'). In any case,
timing-wise, such an effort would coincide with the upcoming 2.0
development.
Based on the above, my suggestion would be:
1) Apart from the changes above, there might not be a need to rewrite the
admin client. From my basic use over the last two weeks, I like it's
simplicity. It provides a low-level entry point for people that start with
Keycloak, which is good.
2) I can't say - simply don't have enough experience in this fields. Then
again, in Java, when one says "in theory, it's compatible" it typically
isn't.
3) Apply the changes for the as-is client to 1.9.x, and improve services
(and as a result, the client) in 2.x
Kind regards,
Guus
On 5 April 2016 at 10:19, Stian Thorgersen <sthorger(a)redhat.com> wrote:
At least personally I think the admin client needs some TLC. For
example
creating a user requires:
UserRepresentation user = new UserRepresentation();
user.setUsername("user");
Response response = keycloak.realm("realm").users().create(user);
// Retrieve created user id
String path = response.getLocation().getPath();
String id = path.substring(path.lastIndexOf('/') + 1);
// Remember to close the response
response.close();
// Set password
CredentialRepresentation credentials = new
CredentialRepresentation();
credentials.setType(CredentialRepresentation.PASSWORD);
credentials.setValue("password");
keycloak.realm("realm").users().get(id).resetPassword(credentials);
// Add role
RoleRepresentation role =
keycloak.realm("realm").roles().get("role").toRepresentation();
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
That's pretty rubbish right?
In my opinion a lot of the usability issues is caused by directly exposing
interfaces/proxies from RestEasy Client and it would be much better if we
introduced a wrapper around it.
So my questions are:
1) What do we do with regards to admin client? Do we just wrap what we
have, keep it or create a brand new one from scratch?
2) Is it an issue that we require a specific RestEasy version to use the
admin client? This seems a heavy dependency to me, which could conflict
with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
as it should in theory work with any JAX-RS 2 provider.
3) What do we do with current fixes for admin client? Do we merge to
master and 1.9.x or just merge to master?
At least from my POV the answers are:
1) Create wrappers around interfaces/proxies from RestEasy client and not
expose JAX-RS directly through the API as that should be an implementation
detail
2) Use JAX-RS 2 client
3) Merge fixes to both master and 1.9.x (admin client is not supported in
product for now, so it's less risky)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:58 p.m.
On 05/04/16 10:19, Stian Thorgersen wrote:
At least personally I think the admin client needs some TLC. For
example creating a user requires:
UserRepresentation user = new UserRepresentation();
user.setUsername("user");
Response response = keycloak.realm("realm").users().create(user);
// Retrieve created user id
String path = response.getLocation().getPath();
String id = path.substring(path.lastIndexOf('/') + 1);
// Remember to close the response
response.close();
// Set password
CredentialRepresentation credentials = new CredentialRepresentation();
credentials.setType(CredentialRepresentation.PASSWORD);
credentials.setValue("password");
keycloak.realm("realm").users().get(id).resetPassword(credentials);
// Add role
RoleRepresentation role =
keycloak.realm("realm").roles().get("role").toRepresentation();
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
That's pretty rubbish right?
In my opinion a lot of the usability issues is caused by directly
exposing interfaces/proxies from RestEasy Client and it would be much
better if we introduced a wrapper around it.
Yeah, agree that usability is not very
great.
However to me personally, the biggest issue is not usability but the
fact, that admin-client needs to be manually maintained. AFAIK it was
lots of spent time - especially for Stan and Marko - to have the
admin-client synced with the latest server. And it seems that earlier or
later, the issue will be back once we will add more endpoints. We can
have "policy" that everyone, who is adding new server endpoint, would
need to update client too (which is usually needed anyway for the test).
But that still requires some time spend in manually updating code +
there is some risk that earlier or later will admin-client still become
outdated...
IMO If we can have admin-client autogenerated, it will be a huge win. I
am not sure if it's realistic (and seems that it will be even harder to
accomplish if we use wrapper instead of JAX-RS directly. ) but maybe
worth to look into it at least?
So my questions are:
1) What do we do with regards to admin client? Do we just wrap what we
have, keep it or create a brand new one from scratch?
2) Is it an issue that we require a specific RestEasy version to use
the admin client? This seems a heavy dependency to me, which could
conflict with other JAX-RS libraries. Using JAX-RS 2 Client would be
an improvement as it should in theory work with any JAX-RS 2 provider.
3) What do we do with current fixes for admin client? Do we merge to
master and 1.9.x or just merge to master?
At least from my POV the answers are:
1) Create wrappers around interfaces/proxies from RestEasy client and
not expose JAX-RS directly through the API as that should be an
implementation detail
+1 for wrappers. And as I mentioned above, look if we can do
something
regarding autogeneration (or at least something else to enforce the
admin-client won't become outdated again).
2) Use JAX-RS 2 client
+1
But it will be good if people have possibility to configure the details
of underlying Apache HTTP Client (connection pooling, connection/socket
timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2
client at the same time, it will be cool. Otherwise if we need to choose
just one of these, the "configurability" of Apache HTTP client is more
important IMO.
3) Merge fixes to both master and 1.9.x (admin client is not
supported
in product for now, so it's less risky)
+1
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:18 p.m.
On 5 April 2016 at 12:31, Guus der Kinderen <guus.der.kinderen(a)gmail.com>
wrote:
Hi Stian,
First off: I didn't know that Keycloak existed three weeks ago. Much of
what I write might be a result of me being unfamiliar with earlier design
choices. That being said:
Based on the snippet that you provided I'd argue that it is the service,
rather than the admin client, that could/should be improved. When
implementing a (REST) service, it is common to provide a representation as
part of the response to a create (POST) request: the service response
should include the most up-to-date representation of the resource, which
prevents the client from having to reconstruct it (exactly what you're
doing in that snippet), which is tedious, error-prone and lacking the
inclusion of server-generated values. On top of that, if a client needs
multiple requests to recreate a representation, concurrency issues come in
to play. Who's to say that all responses reflect the exact same state,
server sided?
I did take an extreme example and you're right that it can be improved by
fixing the server side rest endpoints.
Restructuring the web services could lead to a large change (although
inclusion of representation in responses might be backwards compatible, as
the random sample of services that I checked appear to currently have empty
responses - perhaps the representation could simply 'fit in'). In any case,
timing-wise, such an effort would coincide with the upcoming 2.0
development.
We have been discussing to introduce a version 2.0 of the rest api, we'd
still keep version 1 for backwards compatibility for a while at least.
Based on the above, my suggestion would be:
1) Apart from the changes above, there might not be a need to rewrite the
admin client. From my basic use over the last two weeks, I like it's
simplicity. It provides a low-level entry point for people that start with
Keycloak, which is good.
Maybe you're right and the client will be simpler to use once we improve
the server side
2) I can't say - simply don't have enough experience in this
fields. Then
again, in Java, when one says "in theory, it's compatible" it typically
isn't.
;)
3) Apply the changes for the as-is client to 1.9.x, and improve
services
(and as a result, the client) in 2.x
Kind regards,
Guus
On 5 April 2016 at 10:19, Stian Thorgersen <sthorger(a)redhat.com> wrote:
> At least personally I think the admin client needs some TLC. For example
> creating a user requires:
>
> UserRepresentation user = new UserRepresentation();
> user.setUsername("user");
>
> Response response = keycloak.realm("realm").users().create(user);
>
> // Retrieve created user id
> String path = response.getLocation().getPath();
> String id = path.substring(path.lastIndexOf('/') + 1);
>
> // Remember to close the response
> response.close();
>
> // Set password
> CredentialRepresentation credentials = new
> CredentialRepresentation();
> credentials.setType(CredentialRepresentation.PASSWORD);
> credentials.setValue("password");
>
>
> keycloak.realm("realm").users().get(id).resetPassword(credentials);
>
> // Add role
> RoleRepresentation role =
> keycloak.realm("realm").roles().get("role").toRepresentation();
>
>
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>
> That's pretty rubbish right?
>
> In my opinion a lot of the usability issues is caused by directly
> exposing interfaces/proxies from RestEasy Client and it would be much
> better if we introduced a wrapper around it.
>
> So my questions are:
>
> 1) What do we do with regards to admin client? Do we just wrap what we
> have, keep it or create a brand new one from scratch?
> 2) Is it an issue that we require a specific RestEasy version to use the
> admin client? This seems a heavy dependency to me, which could conflict
> with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
> as it should in theory work with any JAX-RS 2 provider.
> 3) What do we do with current fixes for admin client? Do we merge to
> master and 1.9.x or just merge to master?
>
> At least from my POV the answers are:
> 1) Create wrappers around interfaces/proxies from RestEasy client and not
> expose JAX-RS directly through the API as that should be an implementation
> detail
> 2) Use JAX-RS 2 client
> 3) Merge fixes to both master and 1.9.x (admin client is not supported in
> product for now, so it's less risky)
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
8:22 p.m.
On 5 April 2016 at 12:58, Marek Posolda <mposolda(a)redhat.com> wrote:
On 05/04/16 10:19, Stian Thorgersen wrote:
At least personally I think the admin client needs some TLC. For example
creating a user requires:
UserRepresentation user = new UserRepresentation();
user.setUsername("user");
Response response = keycloak.realm("realm").users().create(user);
// Retrieve created user id
String path = response.getLocation().getPath();
String id = path.substring(path.lastIndexOf('/') + 1);
// Remember to close the response
response.close();
// Set password
CredentialRepresentation credentials = new
CredentialRepresentation();
credentials.setType(CredentialRepresentation.PASSWORD);
credentials.setValue("password");
keycloak.realm("realm").users().get(id).resetPassword(credentials);
// Add role
RoleRepresentation role =
keycloak.realm("realm").roles().get("role").toRepresentation();
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
That's pretty rubbish right?
In my opinion a lot of the usability issues is caused by directly exposing
interfaces/proxies from RestEasy Client and it would be much better if we
introduced a wrapper around it.
Yeah, agree that usability is not very great.
However to me personally, the biggest issue is not usability but the fact,
that admin-client needs to be manually maintained. AFAIK it was lots of
spent time - especially for Stan and Marko - to have the admin-client
synced with the latest server. And it seems that earlier or later, the
issue will be back once we will add more endpoints. We can have "policy"
that everyone, who is adding new server endpoint, would need to update
client too (which is usually needed anyway for the test). But that still
requires some time spend in manually updating code + there is some risk
that earlier or later will admin-client still become outdated...
IMO If we can have admin-client autogenerated, it will be a huge win. I am
not sure if it's realistic (and seems that it will be even harder to
accomplish if we use wrapper instead of JAX-RS directly. ) but maybe worth
to look into it at least?
I don't think auto-generating is realistic. Nor do I think it will be a
particularly big issue going forward. If anyone touches the admin endpoints
they WILL update the admin client as well as add tests for it, end of ;)
So my questions are:
1) What do we do with regards to admin client? Do we just wrap what we
have, keep it or create a brand new one from scratch?
2) Is it an issue that we require a specific RestEasy version to use the
admin client? This seems a heavy dependency to me, which could conflict
with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
as it should in theory work with any JAX-RS 2 provider.
3) What do we do with current fixes for admin client? Do we merge to
master and 1.9.x or just merge to master?
At least from my POV the answers are:
1) Create wrappers around interfaces/proxies from RestEasy client and not
expose JAX-RS directly through the API as that should be an implementation
detail
+1 for wrappers. And as I mentioned above, look if we can do something
regarding autogeneration (or at least something else to enforce the
admin-client won't become outdated again).
API's, user interfaces, etc.. can NOT be auto-generated if you want to have
anything remotely usable
2) Use JAX-RS 2 client
+1
But it will be good if people have possibility to configure the details of
underlying Apache HTTP Client (connection pooling, connection/socket
timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
at the same time, it will be cool. Otherwise if we need to choose just one
of these, the "configurability" of Apache HTTP client is more important IMO.
Sticking with RestEasy Client makes the assumption that all users use other
JBoss projects. We know that's not true as Tomcat, Jetty and Spring
adapters all have a lot of use. IMO we should either convert to JAX-RS 2
client or use Apache HTTP client directly (I'm not to keen on that though).
3) Merge fixes to both master and 1.9.x (admin client is not
supported in
product for now, so it's less risky)
+1
Marek
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
8:47 p.m.
On 05/04/16 13:22, Stian Thorgersen wrote:
On 5 April 2016 at 12:58, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 05/04/16 10:19, Stian Thorgersen wrote:
> At least personally I think the admin client needs some TLC. For
> example creating a user requires:
>
> UserRepresentation user = new UserRepresentation();
> user.setUsername("user");
>
> Response response = keycloak.realm("realm").users().create(user);
>
> // Retrieve created user id
> String path = response.getLocation().getPath();
> String id = path.substring(path.lastIndexOf('/') + 1);
> // Remember to close the response
> response.close();
>
> // Set password
> CredentialRepresentation credentials = new
> CredentialRepresentation();
> credentials.setType(CredentialRepresentation.PASSWORD);
> credentials.setValue("password");
> keycloak.realm("realm").users().get(id).resetPassword(credentials);
> // Add role
> RoleRepresentation role =
>
keycloak.realm("realm").roles().get("role").toRepresentation();
>
keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
> That's pretty rubbish right?
>
> In my opinion a lot of the usability issues is caused by directly
> exposing interfaces/proxies from RestEasy Client and it would be
> much better if we introduced a wrapper around it.
Yeah, agree that usability is not very great.
However to me personally, the biggest issue is not usability but
the fact, that admin-client needs to be manually maintained. AFAIK
it was lots of spent time - especially for Stan and Marko - to
have the admin-client synced with the latest server. And it seems
that earlier or later, the issue will be back once we will add
more endpoints. We can have "policy" that everyone, who is adding
new server endpoint, would need to update client too (which is
usually needed anyway for the test). But that still requires some
time spend in manually updating code + there is some risk that
earlier or later will admin-client still become outdated...
IMO If we can have admin-client autogenerated, it will be a huge
win. I am not sure if it's realistic (and seems that it will be
even harder to accomplish if we use wrapper instead of JAX-RS
directly. ) but maybe worth to look into it at least?
I don't think auto-generating is realistic. Nor do I think it will be
a particularly big issue going forward. If anyone touches the admin
endpoints they WILL update the admin client as well as add tests for
it, end of ;)
>
> So my questions are:
>
> 1) What do we do with regards to admin client? Do we just wrap
> what we have, keep it or create a brand new one from scratch?
> 2) Is it an issue that we require a specific RestEasy version to
> use the admin client? This seems a heavy dependency to me, which
> could conflict with other JAX-RS libraries. Using JAX-RS 2 Client
> would be an improvement as it should in theory work with any
> JAX-RS 2 provider.
> 3) What do we do with current fixes for admin client? Do we merge
> to master and 1.9.x or just merge to master?
>
> At least from my POV the answers are:
> 1) Create wrappers around interfaces/proxies from RestEasy client
> and not expose JAX-RS directly through the API as that should be
> an implementation detail
+1 for wrappers. And as I mentioned above, look if we can do
something regarding autogeneration (or at least something else to
enforce the admin-client won't become outdated again).
API's, user interfaces, etc.. can NOT be auto-generated if you want to
have anything remotely usable
> 2) Use JAX-RS 2 client
+1
But it will be good if people have possibility to configure the
details of underlying Apache HTTP Client (connection pooling,
connection/socket timeouts, tls etc). If it's possible to achieve
it and use JAX-RS 2 client at the same time, it will be cool.
Otherwise if we need to choose just one of these, the
"configurability" of Apache HTTP client is more important IMO.
Sticking with RestEasy Client makes the assumption that all users use
other JBoss projects. We know that's not true as Tomcat, Jetty and
Spring adapters all have a lot of use. IMO we should either convert to
JAX-RS 2 client or use Apache HTTP client directly (I'm not to keen on
that though).
At least we may just have possibility to inject underlying
javax.ws.rs.client.Client during creation of admin-client. So if someone
is on resteasy and wants to tweak Apache HTTP Client, he can use
RestEasy API to build client by himself and inject it. If he's using
some other library, he would need to use it's API to build client (and
possibly configure connection pooling etc in library specific way).
Marek
> 3) Merge fixes to both master and 1.9.x (admin client is not
> supported in product for now, so it's less risky)
+1
Marek
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:19 p.m.
On 4/5/2016 7:47 AM, Marek Posolda wrote:
>> 2) Use JAX-RS 2 client
> +1
>
> But it will be good if people have possibility to configure the
> details of underlying Apache HTTP Client (connection pooling,
> connection/socket timeouts, tls etc). If it's possible to achieve
> it and use JAX-RS 2 client at the same time, it will be cool.
> Otherwise if we need to choose just one of these, the
> "configurability" of Apache HTTP client is more important IMO.
>
>
> Sticking with RestEasy Client makes the assumption that all users use
> other JBoss projects. We know that's not true as Tomcat, Jetty and
> Spring adapters all have a lot of use. IMO we should either convert
> to JAX-RS 2 client or use Apache HTTP client directly (I'm not to
> keen on that though).
At least we may just have possibility to inject underlying
javax.ws.rs.client.Client during creation of admin-client. So if
someone is on resteasy and wants to tweak Apache HTTP Client, he can
use RestEasy API to build client by himself and inject it. If he's
using some other library, he would need to use it's API to build
client (and possibly configure connection pooling etc in library
specific way).
If you're using Tomcat, Spring or whatever, anything JBoss is evil and
they can't co-exist? That's ridiculous. You're really going to stub
out every single piece of the REST api and/or write your own tool? No....
We revise the rest interface. Either use Resteasy, or they can write
their own clients.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:32 p.m.
On 5 April 2016 at 14:19, Bill Burke <bburke(a)redhat.com> wrote:
On 4/5/2016 7:47 AM, Marek Posolda wrote:
2) Use JAX-RS 2 client
>
> +1
>
> But it will be good if people have possibility to configure the details
> of underlying Apache HTTP Client (connection pooling, connection/socket
> timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
> at the same time, it will be cool. Otherwise if we need to choose just one
> of these, the "configurability" of Apache HTTP client is more important
IMO.
>
Sticking with RestEasy Client makes the assumption that all users use
other JBoss projects. We know that's not true as Tomcat, Jetty and Spring
adapters all have a lot of use. IMO we should either convert to JAX-RS 2
client or use Apache HTTP client directly (I'm not to keen on that though).
At least we may just have possibility to inject underlying javax.ws.rs.client.Client
during creation of admin-client. So if someone is on resteasy and wants to
tweak Apache HTTP Client, he can use RestEasy API to build client by
himself and inject it. If he's using some other library, he would need to
use it's API to build client (and possibly configure connection pooling etc
in library specific way).
If you're using Tomcat, Spring or whatever, anything JBoss is evil and
they can't co-exist? That's ridiculous. You're really going to stub out
every single piece of the REST api and/or write your own tool? No....
What's wrong with JAX-RS 2.0?
We revise the rest interface. Either use Resteasy, or they can write
their own clients.
What are you saying here exactly?
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:36 p.m.
On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
On 5 April 2016 at 14:19, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 4/5/2016 7:47 AM, Marek Posolda wrote:
>
>>> 2) Use JAX-RS 2 client
>> +1
>>
>> But it will be good if people have possibility to configure
>> the details of underlying Apache HTTP Client (connection
>> pooling, connection/socket timeouts, tls etc). If it's
>> possible to achieve it and use JAX-RS 2 client at the same
>> time, it will be cool. Otherwise if we need to choose just
>> one of these, the "configurability" of Apache HTTP client is
>> more important IMO.
>>
>>
>> Sticking with RestEasy Client makes the assumption that all
>> users use other JBoss projects. We know that's not true as
>> Tomcat, Jetty and Spring adapters all have a lot of use. IMO we
>> should either convert to JAX-RS 2 client or use Apache HTTP
>> client directly (I'm not to keen on that though).
> At least we may just have possibility to inject underlying
> javax.ws.rs <http://javax.ws.rs>.client.Client during creation of
> admin-client. So if someone is on resteasy and wants to tweak
> Apache HTTP Client, he can use RestEasy API to build client by
> himself and inject it. If he's using some other library, he would
> need to use it's API to build client (and possibly configure
> connection pooling etc in library specific way).
>
If you're using Tomcat, Spring or whatever, anything JBoss is
evil and they can't co-exist? That's ridiculous. You're really
going to stub out every single piece of the REST api and/or write
your own tool? No....
What's wrong with JAX-RS 2.0?
The proxy thing is Resteasy specific. Its not in
the spec.
We revise the rest interface. Either use Resteasy, or they can
write their own clients.
What are you saying here exactly?
That we use Resteasy to create the admin client. If somebody doesn't
want to have a dependency on Resteasy then they are on their own.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:45 p.m.
On 5 April 2016 at 14:36, Bill Burke <bburke(a)redhat.com> wrote:
On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
On 5 April 2016 at 14:19, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 4/5/2016 7:47 AM, Marek Posolda wrote:
>
>
> 2) Use JAX-RS 2 client
>>
>> +1
>>
>> But it will be good if people have possibility to configure the details
>> of underlying Apache HTTP Client (connection pooling, connection/socket
>> timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
>> at the same time, it will be cool. Otherwise if we need to choose just one
>> of these, the "configurability" of Apache HTTP client is more important
IMO.
>>
>
> Sticking with RestEasy Client makes the assumption that all users use
> other JBoss projects. We know that's not true as Tomcat, Jetty and Spring
> adapters all have a lot of use. IMO we should either convert to JAX-RS 2
> client or use Apache HTTP client directly (I'm not to keen on that though).
>
> At least we may just have possibility to inject underlying javax.ws.rs.client.Client
> during creation of admin-client. So if someone is on resteasy and wants to
> tweak Apache HTTP Client, he can use RestEasy API to build client by
> himself and inject it. If he's using some other library, he would need to
> use it's API to build client (and possibly configure connection pooling etc
> in library specific way).
>
> If you're using Tomcat, Spring or whatever, anything JBoss is evil and
> they can't co-exist? That's ridiculous. You're really going to stub
out
> every single piece of the REST api and/or write your own tool? No....
>
We're already stubbing out everything due to having to create the
interfaces. I've never been convinced about exposing RestEasy client
interfaces/proxies directly as the usability is not very good IMO.
Especially around error handling.
What's wrong with JAX-RS 2.0?
The proxy thing is Resteasy specific. Its not in the spec.
What's this then
http://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/client/ClientB...
?
> We revise the rest interface. Either use Resteasy, or they can write
> their own clients.
>
What are you saying here exactly?
That we use Resteasy to create the admin client. If somebody doesn't want
to have a dependency on Resteasy then they are on their own.
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
9:54 p.m.
On 4/5/2016 8:45 AM, Stian Thorgersen wrote:
On 5 April 2016 at 14:36, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
>
>
> On 5 April 2016 at 14:19, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 4/5/2016 7:47 AM, Marek Posolda wrote:
>>
>>>> 2) Use JAX-RS 2 client
>>> +1
>>>
>>> But it will be good if people have possibility to
>>> configure the details of underlying Apache HTTP Client
>>> (connection pooling, connection/socket timeouts, tls
>>> etc). If it's possible to achieve it and use JAX-RS 2
>>> client at the same time, it will be cool. Otherwise if
>>> we need to choose just one of these, the
>>> "configurability" of Apache HTTP client is more
>>> important IMO.
>>>
>>>
>>> Sticking with RestEasy Client makes the assumption that all
>>> users use other JBoss projects. We know that's not true as
>>> Tomcat, Jetty and Spring adapters all have a lot of use.
>>> IMO we should either convert to JAX-RS 2 client or use
>>> Apache HTTP client directly (I'm not to keen on that though).
>> At least we may just have possibility to inject underlying
>> javax.ws.rs <http://javax.ws.rs>.client.Client during
>> creation of admin-client. So if someone is on resteasy and
>> wants to tweak Apache HTTP Client, he can use RestEasy API
>> to build client by himself and inject it. If he's using some
>> other library, he would need to use it's API to build client
>> (and possibly configure connection pooling etc in library
>> specific way).
>>
> If you're using Tomcat, Spring or whatever, anything JBoss
> is evil and they can't co-exist? That's ridiculous. You're
> really going to stub out every single piece of the REST api
> and/or write your own tool? No....
>
We're already stubbing out everything due to having to create the
interfaces. I've never been convinced about exposing RestEasy client
interfaces/proxies directly as the usability is not very good IMO.
Especially around error handling.
>
> What's wrong with JAX-RS 2.0?
The proxy thing is Resteasy specific. Its not in the spec.
What's this then
http://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/client/ClientB...
You cannot create a proxy through JAX-RS client api. It doesn't exist.
ClientBuilder creates the base client (similar to HttpClient in
Apache). Even that is not comprehensive enough and you still need to
use implementation specific APIs.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2955
days inactive
2955
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Guus der Kinderen -
Marek Posolda -
Stian Thorgersen