Re: Plans of moving towards JDK7 in trunk

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 wrote: > that doesn't actually stop is from switching in our own code to alternate > web servers, only that jetty can remain a p

Re: Plans of moving towards JDK7 in trunk

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 wrote: > because it is exposed as classpath dependency, changing it breaks backward > compatib

Re: Plans of moving towards JDK7 in trunk

because it is exposed as classpath dependency, changing it breaks backward compatibility. On Fri, Apr 11, 2014 at 1:02 PM, Steve Loughran 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://

Re: Plans of moving towards JDK7 in trunk

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 wrote: > I don't mean to be den

Re: Plans of moving towards JDK7 in trunk

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

Re: [Important] Confirmation related to OpenSsl security issue

I took a quick glance at the build output, and I don't think openssl is getting linked statically into libhadooppipes.a. I see the following lines: Linking CXX static library libhadooppipes.a /usr/bin/cmake -P CMakeFiles/hadooppipes.dir/cmake_clean_target.cmake /usr/bin/cmake -E cmake_link_script

[jira] [Resolved] (HADOOP-10431) Change visibility of KeyStore.Options getter methods to public

[ https://issues.apache.org/jira/browse/HADOOP-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur resolved HADOOP-10431. - Resolution: Fixed Fix Version/s: 3.0.0 Hadoop Flags: Reviewed commi

Re: DISCUSS: use SLF4J APIs in new modules?

if you dont convert mgs to templates the dont remove the guards, else you create str mgs obj even when not logging. thx Alejandro (phone typing) > On Apr 11, 2014, at 10:06, Karthik Kambatla wrote: > > On Fri, Apr 11, 2014 at 1:37 AM, Steve Loughran wrote: > >> On 10 April 2014 16:38, Karth

Re: DISCUSS: use SLF4J APIs in new modules?

In addition, we need to consider limiting any printing messages to the stdout in some cases. This can impact other running some apache products in silent mode such as hive in 'hive -S' option. Thanks -Rahman On Fri, Apr 11, 2014 at 10:06 AM, Karthik Kambatla wrote: > On Fri, Apr 11, 2014 at 1:3

Re: DISCUSS: use SLF4J APIs in new modules?

On Fri, Apr 11, 2014 at 1:37 AM, Steve Loughran wrote: > On 10 April 2014 16:38, Karthik Kambatla wrote: > > > +1 to use slf4j. I would actually vote for (1) new modules must-use, (2) > > new classes in existing modules are strongly recommended to use, (3) > > existing classes can switch to. That

[jira] [Resolved] (HADOOP-9219) coverage fixing for org.apache.hadoop.tools.rumen

[ https://issues.apache.org/jira/browse/HADOOP-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Eagles resolved HADOOP-9219. - Resolution: Fixed Duping this issue to MAPREDUCE-3860 as per Andrey's comment. > covera

Re: Plans of moving towards JDK7 in trunk

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 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 clean

[jira] [Resolved] (HADOOP-8746) TestNativeIO fails when run with jdk7

[ https://issues.apache.org/jira/browse/HADOOP-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mit Desai resolved HADOOP-8746. --- Resolution: Not a Problem Target Version/s: 2.0.2-alpha, 0.23.3, 3.0.0 (was: 0.23.3, 3.0.0

Re: [Important] Confirmation related to OpenSsl security issue

I don't know anything about that, but I do know the apache infrastructure related changes -apache.org was vulnerable -a new *.apache.org certificate is being obtained -once issued, committers and anyone with JIRA admin access are going to have to /should change passwords -JIRA login passwords are

[jira] [Created] (HADOOP-10492) Help Commands needs change after deprecation

Raja Nagendra Kumar created HADOOP-10492: Summary: Help Commands needs change after deprecation Key: HADOOP-10492 URL: https://issues.apache.org/jira/browse/HADOOP-10492 Project: Hadoop Common

[jira] [Created] (HADOOP-10491) Add Collection of Labels to KeyProvider API

Larry McCay created HADOOP-10491: Summary: Add Collection of Labels to KeyProvider API Key: HADOOP-10491 URL: https://issues.apache.org/jira/browse/HADOOP-10491 Project: Hadoop Common Issue T

Re: Plans of moving towards JDK7 in trunk

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

Build failed in Jenkins: Hadoop-Common-trunk #1096

See Changes: [cnauroth] HADOOP-10490. TestMapFile and TestBloomMapFile leak file descriptors. Contributed by Chris Nauroth. [vinodkv] MAPREDUCE-5826. Fixed HistoryServerFileSystemStore to use right permissions on Windows for temp

[Important] Confirmation related to OpenSsl security issue

Hi, Recently one security issue has been found in OpenSSL which has impacted so many customers of different vendors. http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=720951&SearchOrder=4 I want to ask, whether is there in impact of this on the Hadoop Release? Currently

Re: DISCUSS: use SLF4J APIs in new modules?

On 10 April 2014 16:38, Karthik Kambatla wrote: > +1 to use slf4j. I would actually vote for (1) new modules must-use, (2) > new classes in existing modules are strongly recommended to use, (3) > existing classes can switch to. That would take us closer to using slf4j > everywhere faster. > #1

Re: DISCUSS: use SLF4J APIs in new modules?

On 10 April 2014 16:17, Alejandro Abdelnur wrote: > +1 pn slf4j. > > one thing Jay, the issues with log4j will still be there as log4j will > still be under the hood. > > *may* still be under the hood. Even with commons-logging you can swap out log4j, and indeed, I did exactly that for hadoop 0.

Re: Plans of moving towards JDK7 in trunk

On 10 April 2014 18:12, Eli Collins 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 s