Hi Craig, Markus,
I agree this is something we need to fix. The current design specific
does not cache Http(s)URLConnection instances, it relies on properties
to be set on created instances. My thoughts were that
HttpURLConnection anyway caches connections underneath and there are
many properties that require setting and instances are not thread safe.
We need a much better NIO-based low-level client that scales and uses
threads better just like we have Grizzly on the server-side.
We are also exploring the use of the Apache HTTP client as well, code
is in the trunk, it is just not enabled, because we need to fix some
concurrency issues.
A solution is support the setting of HostnameVerifier,
SSLSocketFactory instances as properties and then set those on the
HttpsURLConnection instance. Would that work for you?
Do you also require access to the local and peer Principle instances
involved in hand shaking?
Paul.
On Dec 12, 2008, at 8:30 AM, Markus KARG wrote:
> I appreciate your idea of injectable connection factories so I voted
> for
> this proposal. :-) It opens the way for using different connection
> implementations, like pooled ones and ones using NIO internally to
> speed up
> performance.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Craig.McClanahan_at_Sun.COM [mailto:Craig.McClanahan_at_Sun.COM]
>> Sent: Freitag, 12. Dezember 2008 01:18
>> To: users_at_jersey.dev.java.net
>> Subject: [Jersey] Configuring an HttpsURLConnection in Jersey Client
>>
>> I've got a use case where I need my server side application to be a
>> client of other services as well (using Jersey client). These other
>> services require https (including certificate checking) -- which
>> means
>> I
>> really need access to the HttpsURLConnection instance being used so I
>> can do things like customize the trust store and socket factory.
>> (Note
>> that you can set global defaults for some aspects of this, but that
>> would apply to all the apps in my server so it's not what I want).
>>
>> The current Jersey Client handler code for handling requests
>> (URLConnectionClientHandler) creates a new URLConnection instance for
>> each request, but provides only limited configuration of it (setting
>> timeouts and the redirect flag). I'd like to see Jersey Client
>> support
>> a way to do more sophisticated customization, so I've filed an RFE:
>>
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=160
>>
>> Do you have a similar requirement? You might want to comment on this
>> RFE (or respond to this message), and watch this issue to keep
>> track of
>> progress. In the next few days, I'm probably going to have a
>> proposed
>> patch to support this, if someone else doesn't beat me to it.
>>
>> Craig
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>