That is a good pointer Harsh. Thanks a lot. But if IdentityMapper is being used shouldn't the job.xml reflect that? But Job.xml always shows mapper as our CustomMapper.
Regards Bejoy KS Sent from handheld, please excuse typos. -----Original Message----- From: Harsh J <ha...@cloudera.com> Date: Fri, 3 Aug 2012 13:02:32 To: <mapreduce-user@hadoop.apache.org> Reply-To: mapreduce-user@hadoop.apache.org Cc: Mohammad Tariq<donta...@gmail.com> Subject: Re: Reading fields from a Text line That is not really a bug. Only if you use @Override will you be really asserting that you've overriden the right method (since new API uses inheritance instead of interfaces). Without that kinda check, its easy to make mistakes and add in methods that won't get considered by the framework (and hence the default IdentityMapper comes into play). Always use @Override annotations when inheriting and overriding methods. On Fri, Aug 3, 2012 at 4:41 AM, Bejoy Ks <bejoy.had...@gmail.com> wrote: > Hi Tariq > > On further analysis I noticed a odd behavior in this context. > > If we use the default InputFormat (TextInputFormat) but specify the Key type > in mapper as IntWritable instead of Long Writable. The framework is supposed > throw a class cast exception.Such an exception is thrown only if the key > types at class level and method level are the same (IntWritable) in Mapper. > But if we provide the Input key type as IntWritable on the class level but > LongWritable on the method level (map method), instead of throwing a compile > time error, the code compliles fine . In addition to it on execution the > framework triggers Identity Mapper instead of the custom mapper provided > with the configuration. > > This seems like a bug to me . Filed a jira to track this issue > https://issues.apache.org/jira/browse/MAPREDUCE-4507 > > > Regards > Bejoy KS -- Harsh J
