hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: Plans of moving towards JDK7 in trunkqu r
Date Sat, 12 Apr 2014 14:33:36 GMT
i disagree, "mustn't break downstream app classpath" is not an excuse, but a requirement. 

if you can make 2 versions of jetty to coexist because they are different packages (all their
public apis) and they dont bump up transitive dependencies that break other things then is
ok

thx

Alejandro
(phone typing)

> On Apr 12, 2014, at 3:15, Steve Loughran <stevel@hortonworks.com> wrote:
> 
> 1. I wasn't thinking of sticking of jetty in in the web ui or webhdfs at
> all.
> 2. the later jetties change their packaing, so should be able to co-exist
> anyway.
> 
> Jetty is a fundamental cause of problems, especially on things like
> webhdfs. We can't use the excuse of "mustn't break downstream app classpath
> compatibility" to avoid fixing significant problems
> 
> 
>> On 11 April 2014 23:05, Alejandro Abdelnur <tucu@cloudera.com> wrote:
>> 
>> newer jetties have non backwards compat APIs, we would break any user app
>> using jetty (consumed via hadoop classpath)
>> 
>> 
>> 
>> On Fri, Apr 11, 2014 at 2:16 PM, Steve Loughran <stevel@hortonworks.com
>>> wrote:
>> 
>>> that doesn't actually stop is from switching in our own code to alternate
>>> web servers,  only that jetty can remain a published artifact in the
>>> hadoop/lib dir
>>> 
>>> 
>>>> On 11 April 2014 21:16, Alejandro Abdelnur <tucu@cloudera.com> wrote:
>>>> 
>>>> because it is exposed as classpath dependency, changing it breaks
>>> backward
>>>> compatibility.
>>>> 
>>>> 
>>>> On Fri, Apr 11, 2014 at 1:02 PM, Steve Loughran <
>> stevel@hortonworks.com
>>>>> wrote:
>>>> 
>>>>> Jetty's a big change, it's fairly intimately involved in bits of the
>>> code
>>>>> 
>>>>> but: it's a source of grief, currently webhdfs is an example
>>>>> https://issues.apache.org/jira/browse/HDFS-6221
>>>>> 
>>>>> all YARN apps seem to get hosted by it too
>>>>> 
>>>>> 
>>>>>> On 11 April 2014 20:56, Robert Rati <rrati@redhat.com> wrote:
>>>>>> 
>>>>>> I don't mean to be dense, but can you expand on why jetty 8 can't
>> go
>>>> into
>>>>>> branch2?  What is the concern?
>>>>>> 
>>>>>> Rob
>>>>>> 
>>>>>> 
>>>>>>> On 04/11/2014 10:55 AM, Alejandro Abdelnur wrote:
>>>>>>> 
>>>>>>> if you mean updating jetty on branch2, we cannot do that. it
has
>> to
>>> be
>>>>>>> done in trunk.
>>>>>>> 
>>>>>>> thx
>>>>>>> 
>>>>>>> Alejandro
>>>>>>> (phone typing)
>>>>>>> 
>>>>>>>> On Apr 11, 2014, at 4:46, Robert Rati <rrati@redhat.com>
wrote:
>>>>>>>> 
>>>>>>>> Just an FYI, but I'm working on updating that jetty patch
for the
>>>>>>>> current 2.4.0 release.  The one that is there won't cleanly
apply
>>>>> because
>>>>>>>> so much has changed since it was posted.  I'll post a new
patch
>>> when
>>>>> it's
>>>>>>>> done.
>>>>>>>> 
>>>>>>>> Rob
>>>>>>>> 
>>>>>>>>> On 04/11/2014 04:24 AM, Steve Loughran wrote:
>>>>>>>>> 
>>>>>>>>>> On 10 April 2014 18:12, Eli Collins <eli@cloudera.com>
wrote:
>>>>>>>>>> 
>>>>>>>>>> Let's speak less abstractly, are there particular
features or
>> new
>>>>>>>>>> dependencies that you would like to contribute (or
see
>>> contributed)
>>>>>>>>>> that
>>>>>>>>>> require using the Java 1.7 APIs?  Breaking compat
in v2 or
>>> rolling
>>>> a
>>>>> v3
>>>>>>>>>> release are both non-trivial, not something I suspect
we'd want
>>> to
>>>> do
>>>>>>>>>> just
>>>>>>>>>> because it would be, for example, nicer to have a
newer version
>>> of
>>>>>>>>>> Jetty.
>>>>>>>>> 
>>>>>>>>> Oddly enough, rolling the web framework is something
I'd like to
>>> see
>>>>> in
>>>>>>>>> a
>>>>>>>>> v3. the shuffle may be off jetty, but webhdfs isn't.
Moving up
>>> also
>>>>>>>>> lets is
>>>>>>>>> reliably switch to servlet API v3
>>>>>>>>> 
>>>>>>>>> But.. I think we may be able to increment Jetty more
without
>> going
>>>> to
>>>>>>>>> java7, see https://issues.apache.org/jira/browse/HADOOP-9650
.
>>>>> 
>>>>> --
>>>>> CONFIDENTIALITY NOTICE
>>>>> NOTICE: This message is intended for the use of the individual or
>>> entity
>>>> to
>>>>> which it is addressed and may contain information that is
>> confidential,
>>>>> privileged and exempt from disclosure under applicable law. If the
>>> reader
>>>>> of this message is not the intended recipient, you are hereby
>> notified
>>>> that
>>>>> any printing, copying, dissemination, distribution, disclosure or
>>>>> forwarding of this communication is strictly prohibited. If you have
>>>>> received this communication in error, please contact the sender
>>>> immediately
>>>>> and delete it from your system. Thank You.
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Alejandro
>>> 
>>> --
>>> CONFIDENTIALITY NOTICE
>>> NOTICE: This message is intended for the use of the individual or entity
>> to
>>> which it is addressed and may contain information that is confidential,
>>> privileged and exempt from disclosure under applicable law. If the reader
>>> of this message is not the intended recipient, you are hereby notified
>> that
>>> any printing, copying, dissemination, distribution, disclosure or
>>> forwarding of this communication is strictly prohibited. If you have
>>> received this communication in error, please contact the sender
>> immediately
>>> and delete it from your system. Thank You.
>> 
>> 
>> 
>> --
>> Alejandro
> 
> -- 
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to 
> which it is addressed and may contain information that is confidential, 
> privileged and exempt from disclosure under applicable law. If the reader 
> of this message is not the intended recipient, you are hereby notified that 
> any printing, copying, dissemination, distribution, disclosure or 
> forwarding of this communication is strictly prohibited. If you have 
> received this communication in error, please contact the sender immediately 
> and delete it from your system. Thank You.

Mime
View raw message