Paul Sandoz wrote:
> 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?
>
Yes, that would work for me.
> Do you also require access to the local and peer Principle instances
> involved in hand shaking?
>
I haven't needed them yet for my use cases, but if I tell you I *won't*
need them, that pretty much guarantees that at some point I will :-).
> Paul.
Craig
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>