In a junit5 test class can weldinitiator config be specific (i.e different behaviour of mocks) for each method of the test class? Because I could only do and I only found one weldinitiator config for the whole test class but never for test methods specifically. Thank you.
No, you cannot. WeldInitiator effectively provides a configuration for JUnit 5 extension that weld-junit uses to bootstrap itself and it is class-wide.
If you have an idea (pseudo code) of how this could look like, please create a GitHub issue on the project.
Personally, I cannot imagine a way in which it wouldn't introduce more mess then order into testing.
It is true that you can boot Weld on a per-test-method basis (in fact I think that's the basic mode), so in theory it could exist, but in the same time you can "workaround" this by creating an abstract class as a parent with your test logic and then as many subclasses as you like, each of which will have its own configured WeldInitiator - that should achieve exactly the same goal.
Related
I have several helper methods I'd like to include on all of my plugins (things like manipulating lists in persistent storage or setting up config templates), however it looks like from the docs (and in practice) that plugins must inherit from BotPlugin and BotPlugin only. This scuppers my initial idea of having my own base bot class that includes all of these useful behaviors and then having individual plugins inherit from there.
I'm curious why errbot was setup this way and if there might be a reasonable workaround to enable inheritance of plugin classes?
For example:
class BaseBot(BotPlugin):
# common methods
from base_bot import BaseBot
class MyPlugin1(BaseBot):
# doesn't work, errbot won't detect the plugin
however it looks like from the docs (and in practice) that plugins must inherit from BotPlugin and BotPlugin only.
This is correct and the reasons for this mostly have to do with the fact that we use yapsy as our plugin manager. It must know which class from a plugin to actually load (in case a plugin contains multiple classes).
The BotPlugin class also contains all the methods a plugin has at it's disposal (and all the callbacks it may implement) so it also serves as a framework for that.
Now, on to your actual question, you could use a mixin for the shared functionality. Define a common class (lets say, class CommonFunctionalityMixin) which can be imported by all your plugins, then let those plugins inherit from it in addition to BotPlugin:
class MyPlugin(BotPlugin, CommonFunctionalityMixin):
# ...has all of BotPlugin as well as CommonFunctionalityMixin
See errcron for a real-world example of this technique.
We are working on plugin for ReSharper and we want to make our plugin extensible. Seems, we should use ShellComponent attribute to do it but we can not find any examples. Could anybody enplane how to define custom extension point and how to manage extension. Example of code of extension point and extension implementation would be very helpful.
Thanks.
If you're looking to write a plugin that can extend ReSharper, you need to tell ReSharper about the classes in your plugin, by marking them with the [ShellComponent] or [SoutionComponent] attributes. These attributes have different lifetimes - a shell component lasts the lifetime of ReSharper itself, and a solution component is created when a solution is opened and disposed when the solution is closed.
To make ReSharper do something useful with your components, they typically have to implement an interface, such as ICodeCompletionItemsProvider, and sometimes have to use a different attribute, such as [CodeCleanupModule] (which itself derives from ShellComponentAttribute). There are many extension points in ReSharper, and the one that's appropriate for you depends on what you're trying to do - refactoring, unit test provider, code cleanup, code completion items, etc. The devguide provides a good introduction to the more common extension points.
But if you want to make your own plugin extensible, then your component needs to work with a kind of provider pattern, by deferring work to multiple provider instances. For example, code cleanup works by deferring to multiple code cleanup modules, each responsible for cleaning up a different aspect of your code (whitespace, ordering, etc). To do this, your component should take in a collection of providers in the constructor. ReSharper's component model will automatically create a collection of these types and pass them to. More specifically, you should have a constructor that takes an IEnumerable<T> or IViewable<T>, where T is the interface of the provider you're going to define and call. The IEnumerable<T> will give you a simple collection of providers, but IViewable<T> represents an observable collection, and allows you to subscribe to notifications of new providers being made available from the component model.
First of all, excuse me if I say something obvious because I did not research the answer to this question, it's just something that came to mind and couldn't find an answer to with a quick google search (I also don't know Groovy well).
I'm reading Groovy in action (1st ed) and in section 7.6 it states that "If you want a usual Java class to be recognized as a Groovy class, you only have to implement the GroovyObject interface. For convenience, you can also subclass the abstract class GroovyObjectSupport, which provides default implementations."
So I'm trying out some Java/Groovy (trying to find ways to make coding in Java faster/easier), and I'm instantiating this object Person, which is a Java object and the Person class does not have anything to do with Groovy (i.e. doesn't implement GroovyObject or anything). Person has a protected field, name, with getters/setters. I am able to access this like so in a groovy test case (extends GroovyTestCase), which btw is in a different package and should not be accessible like this:
Person person = new Person('joe')
println "Name: ${person.name}"
Isn't that using the meta info which a Groovy object would have i.e. Groovy would intercept, get the "name" part of "person.name" and call the getName() method or something like that? But person is a Java object... i.e. it shouldn't have that logic available.
I have not implemented GroovyObject or extended GroovyObjectSupport, yet it seems like this Java object has Groovy features I can use.
My question is, what can I assume from Java objects used in Groovy? There is obviously something being done behind the scenes to augment Java defined classes with some Groovy features... but, which features?
So, I guess my question boils down to: "What is done to Java classes when used within a Groovy context?"
Any info regarding the subject would be appreciated, thanks :)
Groovy indeed enhances your Java classes. The problem is when you want to use these enhanced Java classes from Java. Then you need to go for the GroovyObject and GroovyObjectSupport strategy.
About what you can expect, you can check the groovy docs:
the groovy-jdk shows the Groovy enhancements to the JDK
the groovy-api shows the stuff specific from the Groovy library
Also the eclipse plugin works great in autocompleting your Java classes from Groovy.
Java objects are enhanced through Groovy's Meta Object Protocol (MOP), which intercepts and makes its own dispatch to methods and attributes. That is why you can intercept stuff and that's how new methods are added to Java's final classes.
The Groovy's MOP uses cached strategy and reflector classes to achieve a good performance.
You can also read Groovy objects via ObjectInputStream by overriding the resolveClass method and changing the class loader.
See http://www.feiteira.org/2013/04/reading-groovy-objects-from-java.html
I am looking for a refreshable groovy classloader,I want to let groovy file change on fly,I know
GroovyScriptEngine do the thing,but if I have AClass.groovy and BClass.groovy, and I write in AClass:
Class pageClass = ClassUtils.forName("BClass", this.getClass().getClassLoader());
and auto reloading BClass is not work when BClass.groovy is not work.
I think the best solution is need a refreshable ClassLoader,but I can not find the exisiting implemention.
And I am not using spring-groovy and grails,I want a independent implemention.
Thanks
Not exactly what you want I'm sure but if you want to do something ONLY with Groovy (no Spring or Grails) that allows you to change stuff and not have to restart your application, you might look at doing some initial work with Groovlets -> http://groovy.codehaus.org/Groovlets
This is only for servlet container work and probably won't be extremely useful as your application gets large but it would allow you to initially change things frequently and simply refresh with a call to the Groovlet.
If you did consider using Spring, scripted beans are 'refreshable' and you can implement that yourself using Java's dynamic language support but I'd suggest simply letting Spring do it for you.
I want to be able to dynamically create a new class that has all of the methods of another class. In particular, I want to make my own kind of remoting proxy.
class ApiProxy extends haxe.remoting.Proxy { }
The new class ApiProxy would have all of the same method names and signatures as Api, and would be compile time checked. Only every invocation is done over the wire, instead of handled locally.
I think that remoting.Proxy is a magic internal class - is this true? Do regular users have the ability to define a class that is as powerfully static as this? I've never seen this done in Java and I'm impressed with it's capabilities in Haxe.
How would I implement my own class like remoting.Proxy?
you can achieve this with macros
take a look at this post to get the idea:
http://haxe.1354130.n2.nabble.com/Macros-Are-Awesome-tc5945711.html
You can write, save to filesystem and register a new Class inside of a Macro, based on type information that was passed to the function.
haxe.remoting.Proxy is indeed "magic", it is described that way in the source comments:
http://code.google.com/p/haxe/source/browse/trunk/std/haxe/remoting/Proxy.hx?r=3592
You can't replicate with "normal" haxe code. Adding/modifying functionality to haxe.remoting.Proxy for your own class will be difficult, but maybe not impossible.
Check the tutorial for the "equivalent" api implementing code:
http://haxe.org/doc/remoting/proxy
However, something like this is probably possible with macros:
http://haxe.org/manual/macros
Working with macros is challenging right now. There is little in the way of documentation or examples, and the macro feature is still under development. However, it lets you have a some control over the compiler during the compilation process, which can be amazingly useful at times.
good luck!