Using the following example, I am not able to intercept the methods call when I have #Advice.Origin Method method as an argument in my method.
public static void premain(String arguments, Instrumentation instrumentation) throws IOException {
new AgentBuilder.Default()
.type(ElementMatchers.nameEndsWith("Controller"))
.transform((builder, type, classLoader, module) -> {
return builder.method(ElementMatchers.any()).intercept(MethodDelegation.to(AccessInterceptor.class));
}
).installOn(instrumentation);
}
#RuntimeType
public static Object intercept(#Advice.Origin Method method, #SuperCall Callable<?> callable) throws Exception {
System.out.println("intercept");
return callable.call();
}
If I remove #Advice.Origin Method method, the code starts working
#RuntimeType
public static Object intercept(#SuperCall Callable<?> callable) throws Exception {
System.out.println("intercept");
return callable.call();
}
There is a difference between #Advice.Origin and #Origin. Advice can do less then delegation but inlines its code. You need to adjust your imports.
Related
For some reason I can't work out yet, my agent doesn't intercept java LinkageError instances.
Agent code:
import net.bytebuddy.agent.builder.AgentBuilder;
import net.bytebuddy.implementation.MethodDelegation;
import net.bytebuddy.implementation.SuperMethodCall;
import net.bytebuddy.matcher.ElementMatchers;
import java.lang.instrument.Instrumentation;
public class MyAgent {
public static void premain(String arguments, Instrumentation instrumentation) {
new AgentBuilder.Default()
.type(ElementMatchers.isSubTypeOf(LinkageError.class))
.transform((builder, type, classLoader, module) ->
builder.constructor(ElementMatchers.isDefaultConstructor())
.intercept(SuperMethodCall.INSTANCE.andThen(MethodDelegation.to(MyInterceptor.class)))
).installOn(instrumentation);
}
}
Interceptor code:
public class MyInterceptor {
#RuntimeType
public static void intercept(#Origin Constructor<?> constructor) throws Exception {
System.out.println("Intercepted: " + constructor.getName());
}
}
Test code:
public static void main(String[] args) {
new NoClassDefFoundError("should be intercepted!!!").toString();
new Foo("oh").toString();
}
What is puzzling is that replacing ElementMatchers.isSubTypeOf(LinkageError.class) with ElementMatchers.nameContains("Foo") gives the expected result and Foo constructor is intercepted.
The NoClassDefFoundError is loaded by the bootstrap loader. It willnot be able to see your interceptor class which is why it is never triggered.
Try using the Advice class (as a visitor) to add bytecode to matched classes which should resolve this problem.
In my selenium TestNG class, there are some
methods, like method1, method2 etc.
I have added fail and success conditions to each method.
public class TestNGClass {
public void method1(String value) throws Exception {
if(value.equals("PASS"){
org.testng.Assert.assertTrue(condition, message);
}
}
//This is another method
public void method2(String value) throws Exception {
if(value.equals("FAIL"){
org.testng.Assert.fail(message);
}
}
But after the TestNG class execution, in the Test-Output folder "Index.html" will be created, which shows only the failed methods. How to display the passed methods also (custom report) .?
Thank you
Convert your test methods using #Test annotation. Modified Code Snippet:
public class TestNGClass {
#Test
public void method1(){
Assert.assertTrue(condition, "Your Message goes here");
}
//This is another method
#Test
public void method2(){
Assert.fail("Your Message goes here");
}
Now, you will have your testcases reported.
i have this class
#Value("${norsys.loadfile.directory}")
private String chemin;
#RequestMapping(value = "/{fileName:.+}", method = RequestMethod.GET)
#ResponseBody()
public void loadVideoFile(#PathVariable("fileName") String fileName,HttpServletResponse response) {
try {
response.setContentType("video/mp4");
Files.copy(Paths.get(chemin, fileName), response.getOutputStream());
response.flushBuffer();
} catch (java.io.FileNotFoundException e) {
response.setStatus(HttpStatus.NOT_FOUND.value());
} catch (Exception e) {
response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
}
}
I dont know how to apply a JUnit test to keep coverage high, I hope that you can give me an idea, thank you
In general you can use Mockito http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html to test classes which have heavyweight dependencies. Using a mock HttpServletResponse class you could verify that the status code is set appropriately for your failure/success cases.
You're going to run into some problems with the use of those static methods.
Instead of
Files.copy(Paths.get(chemin, fileName), response.getOutputStream());
You could use a non-static class, which you could then mock
class ResourceCopier {
public void copy(String dir, String file, OutputStream os) {
Files.copy(Paths.get(dir, file), os);
}
}
Your main class uses
private ResourceCopier resourceCopier;
public void loadVideoFile(....) {
resourceCopier.copy(chemin, fileName, response.getOutputStream());
}
And in your test class you create your primary object, create a Mock of ResourceCopier and HttpServletResponse and use #InjectMocks to inject them to your primary object.
You can then use Mockito's verify() method to make sure the right things have happened (like response.setStatus called with 404 code)
I have a simply interface:
public interface ITest
{
void Method1();
void Method2();
}
and implementation:
public class Test:ITest
{
public void Method1()
{
}
public void Method2()
{
//Method1();
}
}
The custom interceptor:
public class CustomInterceptor:IInterceptor
{
public void Intercept(IInvocation invocation)
{
invocation.Proceed();
}
}
Now, when I execute there two methods:
ITest obj = getting through ninject
obj.Method1();
obj.Method2();
my interceptor is calling twice what is ok.
But when I uncomment the body of Method2(), then the interceptor for the Method1() is not called. I'm looking for what to do, because I want the interceptor to be fired.
When I call the Method1 from the second, I understand this is not called by the generated proxy and that's why it doesn't work. But is it possible to do it in same way?
Ninject creates a proxy object around the actual instance of the Test class. Your methods aren't virtual, so any override for the proxy should be created with 'new' rather than 'override'. Thus, if you call Method1 from Method2, there is no virtual lookup to find the proxy and invoke it.
I have the following interfaces that are part of an existing project. I'd like to make it possible to call the Store(..) function with dynamic objects. But I don't want to change the Interface hierarchy (if at all possible).
public interface IActualInterface
{
void Store(object entity);
}
public interface IExtendedInterface : IActualInterface
{
//Interface items not important
}
public class Test : IExtendedInterface
{
public void Store(object entity)
{
Console.WriteLine("Storing: " + entity.ToString());
}
}
and the following code:
IExtendedInterface extendedInterfaceTest = new Test();
IActualInterface actualInterfaceTest = new Test();
Test directTest = new Test();
dynamic employee = new ExpandoObject();
employee.Name = "John Smith";
employee.Age = 33;
employee.Phones = new ExpandoObject();
employee.Phones.Home = "0111 123123";
employee.Phones.Office = "027 321123";
employee.Tags = new List<dynamic>() { 123.4D, 99.54D };
try
{
extendedInterfaceTest .Store(employee);
}
catch (RuntimeBinderException rbEx)
{
Console.WriteLine(rbEx.Message);
}
//Casting as (object) works okay as it's not resolved at runtime
extendedInterfaceTest.Store((object)employee);
//this works because IActualInterface implements 'Store'
actualInterfaceTest.Store(employee);
//this also works okay (directTest : IProxyTest)
directTest.Store(employee);
When I call extendedInterfaceTest.Store(employee), it raises a runtime binder exception. Why does the interface type make a difference when it's the same underlying type? I can call it on IActualInterface and Type, but not IExtendedInterface?
I understand that when calling a function with a dynamic parameter, the resolution happens at runtime, but why the different behaviours?
What you need to remember is that dynamic resolution basically does the same process as static resolution, but at runtime. Anything that couldn't be resolved by the CLR won't be resolved by the DLR.
Let's take this small program, inspired by yours, and that doesn't use dynamic at all:
namespace ConsoleApplication38 {
public interface IActualInterface {
void Store(object entity);
}
public interface IExtendedInterface : IActualInterface {
}
public class TestInterface : IExtendedInterface {
public void Store(object entity) {
}
}
public abstract class ActualClass {
public abstract void Store(object entity);
}
public abstract class ExtendedClass : ActualClass {
}
public class TestClass : ExtendedClass {
public override void Store(object entity) {
}
}
class Program {
static void TestInterfaces() {
IActualInterface actualTest = new TestInterface();
IExtendedInterface extendedTest = new TestInterface();
TestInterface directTest = new TestInterface();
actualTest.Store(null);
extendedTest.Store(null);
directTest.Store(null);
}
static void TestClasses() {
ActualClass actualTest = new TestClass();
ExtendedClass extendedTest = new TestClass();
TestClass directTest = new TestClass();
actualTest.Store(null);
extendedTest.Store(null);
directTest.Store(null);
}
static void Main(string[] args) {
TestInterfaces();
TestClasses();
}
}
}
Everything compiles fine. But what did the compiler really generate? Let's see using ILdasm.
For the interfaces:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestInterface::Store(object)
We can see here that the C# compiler always generates calls for the interface or class where the method is defined. IActualInterface has a method slot for Store so it's used for actualTest.Store. IExtendedInterface doesn't, so IActualInterface is used for the call. TestInterface defines a new method Store, using the newslot IL modifier, effectively assigning a new slot in the vtable for that method, so it's directly used since directTest is of type TestInterface.
For the classes:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
For the 3 different types, the same call is generated because the method slot is defined on ActualClass.
Let's now see what we get if we write the IL ourselves, using the type we want rather than letting the C# compiler choosing it for us. I've modified the IL to look like this:
For interfaces:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.IExtendedInterface::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestInterface::Store(object)
For classes:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.ExtendedClass::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestClass::Store(object)
The program compiles fine with ILasm. However it fails to pass peverify and crashes at runtime with the following error:
Unhandled Exception:
System.MissingMethodException: Method
not found: 'Void
ConsoleApplication38.IExtendedInterface.Store(System.Object)'.
at
ConsoleApplication38.Program.TestInterfaces()
at
ConsoleApplication38.Program.Main(String[]
args)
If you remove this invalid call, the derived classes calls work fine without any error. The CLR is able to resolve the base method from the derived type call. However interfaces have no true representation in runtime, and the CLR isn't able to resolve the method call from the extended interface.
In theory, the C# compiler could emit the call directly to the correct class specified in the runtime. It would avoid problems about middle classes calls as seen on Eric Lippert's blog. However as demonstrated, this is not possible for interfaces.
Let's get back to the DLR. It resolves the method exactly the same way as the CLR. We've seen that IExtendedInterface.Store couldn't be resolved by the CLR. The DLR cannot either! This is totally hidden by the fact that the C# compiler will emit the right call, so always be careful when using dynamic unless you perfectly know how it works in the CLR.