Using PIAB / Unity, is it possible to intercept "child" method calls ?
e.g. the class has three methods ...
DoSomething(), DoFirst(), DoSecond()
The DoSomething() method calls DoFirst() which in turn calls DoSecond()
I can get interception of DoSomething, but I can't get anything for DoFirst and DoSecond. I've tried various of the Policy Injection rules ... Type Matching, Tag Attribute, Method Signature ... but nothing works. But I can intercept each method if I call them directly
So basic question ... can you even do this ?
And if so, how !!
I've found that I need to use the VirtualMethodInterceptor rather than the TransparentProxy or Interception interceptors
Related
i just want to make a class that inherited from Attribute class to put attribute tags in every method in my project to write the method name , Class name that have this method , date and time of calling , parameters and method's return ( if it's return something ).
i create a table in SQL Server that will receive all log information and sign it ..
i have done all the methods & query that interact with my database ( except Date & Time method) , the only problem is i don't know how to use it with Attribute way to get the information i have mention.
If you want logging with attributes, you may use PostSharp that modifies IL during compilation of your code and puts your logging codes before/after the method that you put your custom attribute derived from PostSharp's attributes (aspects)(AOP).
I think you can not do this only by use of custom attributes, because as I know custom attributes are instantiated only when Type.GetCustomAttributes() is called. So you may have to do some reflection business for sending your logs through your attributes that I don't recommend.
Instead of attributes, you can simply use AOP through a third party tool. You can use Castle Dynamic Proxy 's interceptor.
You can also log with attributes by using Interception in Castle Windsor.
To do this, you create a class that inherits from IInterceptor, register it with your container, then you can add an attribute to any class or method you want to add the logging behaviour to.
I've written an explanation here:
http://www.paulsodimu.co.uk/Post/Aspect-Oriented-Programming-Using-Castle-Windsor
And I've created a sample on GitHub to show how its done:
https://github.com/PaulSodimu/LoggingAopCastle
I would like to know if it is possible by definition, that a decorator may have an interceptor for a method or not. I am using owb and it does not work!
EDIT: Just tested it with WELD and it's the same! Why does a decorator may not have an interceptor?
IMO: Methods in the decorator are never called directly through a contextual reference, therefore must not interceptable. These are container invocations of methods.
I'm trying to create a decorator class in AS3/Flex in order to add some functionality to a UI element. The problem is that I don't know how to automatically "redirect" method and property calls to the object being decorated. I suppose I'm looking for something like the __call() "magic method" from PHP, which is called every time the application calls a non-callable method.
So, the question is - how do I redirect calls for methods and properties (which aren't overriden/don't exist in the decorator class) to the object being decorated?
I think the closest to magic methods in actionscript would be extending Proxy.
I have a common base class from which all my ASMX webservice classes will inherit. In the constructor, I want to do some common authentication checks; if they fail, I would like to halt processing right away (subclass's code would not get executed) and return a 401-status-code response to the caller.
However, the common ASPX-like ways of doing this don't seem to work:
Context.Response.End(); always kicks back a ThreadAborted exception to the caller, within a 500-status-code response. Even if I explicitly set Context.Response.StatusCode = 401 before calling End(), it is ignored. The result is still a 500-response, and the message is always "thread-aborted-exception".
MSDN suggests I use HttpContext.Current.ApplicationInstance.CompleteRequest() instead. However, this does not stop downstream processing: my subclass's functions are still executed as if the constructor had done nothing. (Kind of defeats the purpose of checking authorization in the constructor.)
I can throw a new HttpException. This is a little better in that it does prevent downstream processing, and at least it gives me control over the exception Message returned to the caller. However, it isn't perfect in that the response is still always a 500.
I can define a DoProcessing instance var, and set it to true/false within the constructor. Then have every single WebMethod in every single subclass wrap its functionality within an if (DoProcessing) block... but let's face it, that's hideous!
Is there a better / more thorough way to implement this sort of functionality, so it is common to all my ASMX classes?
edit: Accepting John's answer, as it is probably the best approach. However, due to client reluctance to adopt additional 3rd-party code, and some degree of FUD with AOP, we didn't take that approach. We ended up going with option #3 above, as it seemed to strike the best balance between speed-of-implementation and flexibility, and still fulfill the requirements.
The best way to do it would be to switch to WCF, which has explicit support for such a scenario.
If you must still use ASMX, then your best bet is to call the base class methods from each web method. You might want to use something like PostSharp to "magically" cause all of your web methods to call the base class method.
Context.Response.Write("My custom response message from constructor");
Context.Response.StatusCode = (int)HttpStatusCode.Forbidden;
Context.Response.End();
That code prevent to pass in web method after constructor.
I made a custom handler that derives from MvcHandler. I have my routes using a custom RouteHandler that returns my new handler for GetHttpHandler(), and I override ProcessRequest() in my custom handler. The call to GetHttpHandler is triggering a breakpoint and my handler's constructor is definitely being called, but BeginProcessRequest() is being called on the base MvcHandler instead of ProcessRequest().
Why are the async methods being called when I haven't done anything to call them? I don't want asynchronous handling, and I certainly didn't do anything explicit to get it. My controllers all derive from Controller, not AsyncController.
I don't have the source code with me right now, but I can add it later if needed. I was hoping someone might know some of the reasons why BeginProcessRequest might be called when it's not wanted.
Brad Wilson responded to my post on the Asp.net forums with the following answer http://forums.asp.net/t/1547898.aspx:
Short answer: yes.
With the addition of AsyncController,
the MvcHandler class needs to be an
IHttpAsyncHandler now, which means
that as far as the ASP.NET core
runtime is concerned, the entry points
are now BeginProcessRequest and
EndProcessRequest, not ProcessRequest.
It sounds like ProcessRequest is not even called anymore, but I could be mistaken. I can say that I haven't seen it in my testing.