Hi Stefan,
Sometimes the build fails on BuildHive for reasons not related to the
code change. We will verify the build locally and we will make a code
review. If any further changes will be needed from your side we will let
you know.
Thanks
Mira
On 07/09/2013 01:04 PM, Stefan Katerkamp wrote:
> Hi Miroslav,
>
> ok, thats fine. I changed the code to be 1.6 compliant and started the
> pull request. BuildHive did a lot of tests and after an hour, it came
> back with a failure in jersey-tests-e2e:
>
> Tests in error: TimeoutTest.testFast:94 » Processing
> java.net.SocketTimeoutException: Read tim...
>
> This seems to be unrelated to the contributed code. Is some more
> interaction needed from my side?
>
> Thanks
> Stefan
>
> Am 09.07.2013 10:54, schrieb Miroslav Fuksa:
>> Hi Stefan,
>>
>> yes, we use JDK 1.6 and we would like to keep Jersey 2 code
>> compatible with 1.6 for some time. So, the usage of 1.6 is the
>> intention. This of course does not mean that Jersey users cannot use
>> JDK 1.7; the limitation is only for Jersey developers.
>>
>> So, I am sorry but the code change will be needed in this case.
>>
>> Thanks
>> Mira
>>
>>
>> On 07/08/2013 08:44 PM, Stefan Katerkamp wrote:
>>> Hi Miroslav,
>>>
>>> ok, I did sign the OCA and tried to create the pull request today.
>>>
>>> However, I am getting back an error message from BuildHive, that it
>>> does not want my bleeding edge JDK 1.7 code, which Netbeans 7.3.1
>>> loves to recommend and which I do like indeed.
>>>
>>> It insists on getting JDK 1.6 style code. ("error: diamond operator
>>> is not supported in -source 1.6").
>>>
>>> I modified pom.xml to tell maven-compiler plugin its 1.7, this gets
>>> ignored.
>>>
>>> Its somewhat strange for me to learn that this EE7 project does not
>>> support 1.7 source code style.
>>>
>>> Any recommendations? Wait till -source 1.7 gets in or give up and
>>> fall back into dark age and modify the code?
>>>
>>> BR
>>> Stefan
>>>
>>>
>>> Am 08.07.2013 08:24, schrieb Miroslav Fuksa:
>>>> Hi Stefan,
>>>>
>>>> Thanks for your contribution. There was a filter in Jersey 1 but
>>>> was not migrated yet.
>>>>
>>>> Could you please create a pull request for this filter in jersey
>>>> Github repository?
>>>>
>>>> https://github.com/jersey/jersey
>>>>
>>>> This is the way, how contributions are added to the Jersey. Also
>>>> please sing the OCA:
>>>> http://www.oracle.com/technetwork/community/oca-486395.html
>>>>
>>>> We will also need to have there some tests. Can you migrate the
>>>> tests from Jersey 1 and add your tests if you have any? This will
>>>> ensure that the filter works and also that the filter in Jersey 2
>>>> offers the same functionality as the filter from Jersey 1.x.
>>>>
>>>> Thanks
>>>> Mira
>>>>
>>>>
>>>> On 07/08/2013 01:54 AM, buko wrote:
>>>>> Stefan,
>>>>>
>>>>> Thanks. This is pretty cool. I'm surprised there aren't more
>>>>> examples about authentication and Jersey. Besides [1] and the
>>>>> short section on client authentication I couldn't find much else.
>>>>> This is a pretty common use case so there should probably be
>>>>> better docs.
>>>>>
>>>>> [1]
>>>>> https://github.com/jersey/jersey/blob/master/examples/https-clientserver-grizzly/src/main/java/org/glassfish/jersey/examples/httpsclientservergrizzly/SecurityFilter.java
>>>>>
>>>>>
>>>>> On Fri, Jul 5, 2013 at 7:20 PM, Stefan Katerkamp
>>>>> <stefan_at_katerkamp.de <mailto:stefan_at_katerkamp.de>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> just to let you know:
>>>>>
>>>>> I needed Http client Digest authentication for my Glassfish 4
>>>>> app. I could not find any auth filter for it, so I wrote my own.
>>>>>
>>>>> I works fine for me, it may need further testing. Feel free to
>>>>> try evaluate it and possibly integrate it with the distribution.
>>>>>
>>>>> Code can be found here: http://katerkamp.de/software/jersey/
>>>>>
>>>>> BR
>>>>> Stefan Katerkamp
>>>>>
>>>>>
>>>>
>>>
>>
>