Proxying FileSystem.get()

[Jay Vyas <ja...@gmail.com>]

Hi mapred:

I'd like to proxy calls made to the FileSystem's created during mapreduce
jobs.

However, since the common way jobs work is to use the FileSystem.get(..),
it doesnt seem like an InvocationHandler will be a solution (because it
requires use of the Proxy.newInstance operation).

Any good way to reroute all calls to a FileSystem so that they go through a
particular dynamic proxy ?  Maybe a pure AOP solution would be better, but
havent been able to figure one out yet.

This is relevant to debugging the way different FileSystem implementations
behave beneath mapred ,.

http://stackoverflow.com/questions/18279397/using-aspects-to-inject-
invocationhandlers-without-proxy-class

-- 
Jay Vyas
http://jayunit100.blogspot.com

Re: Proxying FileSystem.get()

[Jay Vyas <ja...@gmail.com>]

Well I want the method calls to be wrapped dynamically, rather than
individually wrapping each one of them and manually wrapping the calls.
 That way the Wrapping file system can be used with any underlying
FileSystem base from any version .

If manually wrapping the underlying FileSystem, then underlying changes in
different versions of hadoop wont be reflected - and the code would require
maintainance with respect to new FileSystem contracts.




On Fri, Aug 16, 2013 at 3:24 PM, Vinod Kumar Vavilapalli <
vinodkv@hortonworks.com> wrote:

> Not sure about your final intention, but a new FileSystem impl
> wrapping/composing the underlying file system should work. No?
>
> Thanks,
> +Vinod
>
> On Aug 16, 2013, at 11:08 AM, Jay Vyas wrote:
>
> > Hi mapred:
> >
> > I'd like to proxy calls made to the FileSystem's created during mapreduce
> > jobs.
> >
> > However, since the common way jobs work is to use the FileSystem.get(..),
> > it doesnt seem like an InvocationHandler will be a solution (because it
> > requires use of the Proxy.newInstance operation).
> >
> > Any good way to reroute all calls to a FileSystem so that they go
> through a
> > particular dynamic proxy ?  Maybe a pure AOP solution would be better,
> but
> > havent been able to figure one out yet.
> >
> > This is relevant to debugging the way different FileSystem
> implementations
> > behave beneath mapred ,.
> >
> > http://stackoverflow.com/questions/18279397/using-aspects-to-inject-
> > invocationhandlers-without-proxy-class
> >
> > --
> > Jay Vyas
> > http://jayunit100.blogspot.com
>
>
> --
> 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.
>



-- 
Jay Vyas
http://jayunit100.blogspot.com

Re: Proxying FileSystem.get()

[Vinod Kumar Vavilapalli <vi...@hortonworks.com>]

Not sure about your final intention, but a new FileSystem impl wrapping/composing the underlying file system should work. No?

Thanks,
+Vinod

On Aug 16, 2013, at 11:08 AM, Jay Vyas wrote:

> Hi mapred:
> 
> I'd like to proxy calls made to the FileSystem's created during mapreduce
> jobs.
> 
> However, since the common way jobs work is to use the FileSystem.get(..),
> it doesnt seem like an InvocationHandler will be a solution (because it
> requires use of the Proxy.newInstance operation).
> 
> Any good way to reroute all calls to a FileSystem so that they go through a
> particular dynamic proxy ?  Maybe a pure AOP solution would be better, but
> havent been able to figure one out yet.
> 
> This is relevant to debugging the way different FileSystem implementations
> behave beneath mapred ,.
> 
> http://stackoverflow.com/questions/18279397/using-aspects-to-inject-
> invocationhandlers-without-proxy-class
> 
> -- 
> Jay Vyas
> http://jayunit100.blogspot.com


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