all
For some reason, we want to intercept java.io.File class to add some log and do some check.
I tried to create a java agent with Byte Buddy to use Advice to do such things for some other class.
But it never work for class which is already loaded before agent premain. I am on byte-byddy 1.10.5
I also did some try use redefinition, or transform, but it's not work as well, not sure if I did something wrong.
Is there a way to achieve this?
You need to enable a retransformation of existing classes. Also, you need to define a custom ignore matcher as boot classes are not instrumented by default.
agentBuilder
.with(RedefinitionStrategy.RETRANSFORMATION)
.disableClassFormatChanges()
.ignore(...)
Related
I try to build a native container with Quarkus (with -Pnative flag), I use -H:+PrintClassInitialization to generate the class initializer reports. I see a initilizer_dependencies_yyyymmdd_hhmmss.dot file is generated; in this file, I see some classes marked with [fillcover=red], could you tell me what this means? and what action is needed?
Thanks
it seems to me those classes are the ones that will be called but not in reflection configuration. I add them in reflection or initialize to solve it.
I would like to write a JUnit5 Extension where I have to take some action when a test method annotated with #Disabled is found. Unfortunately, beforeTestExecution() is not called for such methods. Does anybody have an idea how to intercept such #Disabled test methods ?
Thanks !
As described in the User Guide, you can disable the built-in ExecutionCondition that handles #Disabled by default by setting junit.jupiter.conditions.deactivate to org.junit.*DisabledCondition (see Configuration Parameters on how to set it). This will cause your tests to be executed.
Next, you need to implement your own ExecutionCondition extension, check for #Disabled, take your action and return ConditionEvaluationResult.disabled("...").
In order to avoid having to register your extension on each test class, you can activate Automatic Extension Registration and register your extension globally.
Depending on what you want to achieve, it may be easier to register your own TestExecutionListener (see Plugging in Your Own Test Execution Listeners) and implement executionSkipped().
The extension point used here is https://github.com/junit-team/junit5/blob/master/junit-jupiter-api/src/main/java/org/junit/jupiter/api/extension/ExecutionCondition.java
It might be interesting to find out how several implementors compose, i.e. if the 2nd one will be called at all and under what circumstances. You’ll probably have to dive into Jupiter code or do some experiments.
I've been trying to get Connections to use a customised adapter located at app/extensions/data/source/database/adapter/. I thought extending the Connections class and replacing
protected static $_adapters = 'data.source';
with
protected static $_adapters = 'adapter.extension.data.source';
and changing the connections class used at the top of app/config/bootstrap/connections.php to use app\extensions\data\Connections;
would be enough to get it started. However this just leads to a load of errors where the code is still trying to use the original Connections class.
Is there a simple way to achieve this, or do I have to recreate the entire set of classes from lithium/data in extensions with rewritten class references?
EDIT:
Turns out I was going about this the wrong way. After following Nate Abele's advice, Libraries::path('adapter') showed me where to correctly place the MySql.php file I'm trying to override ;-)
For dealing with how named classes (i.e. services, in the abstract) are located, you want to take a look at the Libraries class, specifically the paths() method, which allows you to define how class paths are looked up.
You can also look at the associated definitions, like locate() and $_paths, to give you an idea of what the default configuration looks like.
Finally, note that the Connections class is 'special' since it defines one path dynamically, based on the supplied configuration: http://li3.me/docs/api/lithium/1.0.x/lithium/data/Connections::_class()
This should help you reconfigure how your classes are organized without extending/overriding anything. Generally you shouldn't need to do that unless you need some drastically different behavior.
I'm trying to sandbox MVEL expression evaluation. Unfortunately, by default MVEL includes all java.lang.* classes in the expression language, so a user could call "Runtime.exit()" and kill the whole system.
How can I exclude all classes that I haven't explicitly added with addImport()?
I haven't been able to make heads or tails of the VariableResolvers.
As far as I known this is not supported.
I faced this need some time ago on a project of my company. We had to change MVEL quite a bit to introduce a way to configure a custom policy to control access to types and methods.
The problem is that you can also access any class by its fully qualified name, so it was not just a matter of removing the default imports.
Unfortunately I don't own the code to make it available.
ParserContext ctx = new ParserContext();
ctx.addImport("System", String.class);
ctx.addImport("Runtime", String.class);
Have you tried using AspectJ to constrain these calls from MVEL?
I've been (happily) using Ninject for a while now with some basic scenarios, and would like to give it control of my logging. I noted the existence of the Ninject.Extensions.Logging namespace, and would like to use it, but I'm running into two issues:
I want the logger to be initialized with the type of the class running it (as if I ran LogManager.GetLogger with the GetCurrentMethod().DeclaringType).
I want to be able to easily mock, or "nullify" the logger for unit testing (i.e I don't want to have the logger work), without running into NullReferenceExceptions for not initializing the logger.
Now, I know there are some questions (and even answers) around here, but I couldn't seem to find any that pointed me in the right direction.
I'll appreciate any help (even a "you bone-head" it's here! Linking to something I should have noticed).
This is the default behavior of the extension
Don't use Ninject to create the object under test in your unit tests. Create an instance manually and pass what ever you want for the logger.
Best you have a look at the unittests. https://github.com/ninject/ninject.extensions.logging/blob/master/src/Ninject.Extensions.Logging.Tests/Infrastructure/CommonTests.cs