Is there a way to filter installers when using IWindsorContainer.Install( IWindsorInstaller[] )?
The reason I am asking is that I have optional features packaged in installers in the same assembly
Yes, you can pass in an instance of a type that derives InstallerFactory to do the selection for you.
Related
I have two situations I need a checkstyle check for. Let's say I have a bunch of objects with the annotation #BusinessLogic. I want to do a first pass through all *.java files creating a Set with the full classnames of these objects. Let's say ONE of the classes here is MyBusinessLogic. NEXT, and as part of a custom checkstyle checker, I want to go through and fail the build if there is any lines of code that say "new MyBusinessLogic()" in any of the code. We want to force DI when objects are annotated with #BusinessLogic. Is this possible with checkstyle? I am not sure checkstyle does a dual pass.
Another option I am considering is some gradle plugin perhaps that scans all java files and writes to a file the list of classes annotated with #BusinessLogic and then running checkstyle after that where my checker reads in the file?
My next situation is I have a library delivered as a jar so in that jar, I also have classes annotated with #BusinessLogic and I need to make sure those are also added to my list of classes that should not be newed up manually and only created with dependency injection.
Follow up question from the previous question here after reading through checkstyle docs:
How to enforce this pattern via gradle plugins?
thanks,
Dean
Is it possible to write a dual pass checkstyle check?
Possible, yes, but not officially supported. Support would come at https://github.com/checkstyle/checkstyle/issues/3540 but it hasn't been agreed on.
Multi-file validation is possible with FileSets (still not officially supported), but it becomes harder with TreeWalker checks. This is because TreeWalker doesn't chain finishProcessing to the checks. You can implement your own TreeWalker that will chain this finishProcessing to implementation of AbstractChecks.
You will have to do everything in 1 pass with this method. Log all new XXX and classes with annotation #YYY. In the finishProcessing method, correlate the information obtained between the 2 and print a violation when you have a match.
I have a library delivered as a jar
Checkstyle does not support reading JARs or bytecode. You can always create a hard coded list as an alternative. The only other way is build your own reader into Checkstyle.
I have this code from old castle:
IoC.Container.Register(
AllTypes
.FromAssemblyNamed(a)
.Pick().WithService.FirstInterface()
.Configure(o => o.LifeStyle.PerWebRequest));
When I upgrade to castle 3.2 I get this error:
Castle.MicroKernel.Registration.AllTypes' is obsolete
And this error for o.LifeStyle.PerWebRequest :
Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement
How can I fix this?
Like #charleh said, AllTypes was replaced with Classes so fixing this problem is a simple find and replace.
Actually if you look at the compiler warning it should say:
'AllTypes' has been deprecated and will be removed in future releases.
Use 'Classes' static class (if you want to just register concrete
classes) or 'Types' static class (if you want to register interfaces
or abstract classes too) instead. It exposes exactly the same methods.
The reason for this change was that AllTypes was a lie - it was only matching concrete (non-abstract) classes, so Classes is a much better name that better tells you what it really does.
As for the other problem, changing the property call to a method call will fix it:
Container.Register(
Classes.FromAssemblyNamed(a)
.Pick().WithServiceFirstInterface()
.Configure( o => o.LifestylePerWebRequest()));
Or simpler yet, skipping the Configure:
Container.Register(
Classes.FromAssemblyNamed(a)
.Pick().WithServiceFirstInterface()
.LifestylePerWebRequest());
Windsor ships with BreakingChanges.txt file which describes breaking changes and how to upgrade.
The first issue is that AllTypes is equivalent to Classes (I actually learned this this morning!)
So instead of
IoC.Container.Register(AllTypes.etc)
Use
IoC.Container.Register(Classes.etc)
Not sure about the other but quick bit of searching seems to suggest that the lifestyles are pluggable in 3.2, you may be missing a reference
Edit:
Ah: Looks like you have referenced the client build of Castle.Windsor dll - there's another build against the full .NET profile which contains the type you need - check your references
PerWebRequest Lifestyle missing in Castle Windsor 3.2
I'm following this guide http://javaeenotes.blogspot.com/2011/06/short-introduction-to-jmock.html
I've received the error
java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package.
In the guide the author says:
The solution is make sure the jMock libraries are included before the
standard jUnit libraries in the build path.
What makes up the "standard jmock libraries" and the "junit libraries"?
Junit only has one jar so that's easy, but jmock comes with over 10 different jars.
I've been using: j-unit4.10, jmock-2.5, hamrest-core and hamcrest-library
What are the hamcrest core and library classes for?
i'm a committer on both libraries. JMock depends on hamcrest to help it decide whether an call to an object is expected. I suggest just using the hamcrest-all jar. The split between hamcrest core and library was to separate the fundamental behaviour of matching and reporting differences from a convenient implementations of the most common cases.
Finally, if you're using hamcrest, I suggest you use the junit-dep jar to avoid clashes with some features of hamcrest that are included in the junit.jar
JUnit is used to do Unit test in order to test your methods. JMock is used to test your program inside a context, You will have to know what you are expecting to send to the context (ENV) and what will answer the context.
JMock use JUnit, that is why, in order to avoid dependency conflicts, you need to include it before JUnit.
The 10 libraries of JMock are kind of add-ons if you need to use JMock script or any other functionnality not available in the JMock core.
You don't need to know about Hamcrest-core library to use JMock. Just follows the guide on the web site (don't use version 1 of JMock) and Organize your libraries in the correct order (JUnit should be last in order to avoid your error)
mock frameworks licke jmock do some black magic behind the scenes
( including, but not limited to runtime byte code manipulation )
to provide mock methods classes and whatever. To be able to do this,
some tweaks in basic junit classes are necessary, and the only way to do this is to
register itself as java agent before JU classes are loaded.
Also, put your mock framework before junit in classpath
I am curious about the usage of the feature known as open classes or monkey-patching in languages like e.g. Ruby, Python, Groovy etc. This feature allows you to make modifications (like adding or replacing methods) to existing classes or objects at runtime.
Does anyone know if major frameworks (such as Rails/Grails/Zope) make (extensive) use of this opportunity in order to provide services to the developer? If so, please provide examples.
Rails does this to a (IMHO) ridiculous extent.
.Net allows it via extension methods.
Linq, specifically, relies heavily on extension methods monkey-patched onto the IEnumerable interface.
An example of its use on the Java platform (since you mentioned Groovy) is load-time weaving with something like AspectJ and JVM instrumentation. In this particular case, however, you have the option of using compile-time weaving instead. Interestingly, one of my recent SO questions was related to problems with using this load-time weaving, with some recommending compile-time as the only reliable option.
An example of AspectJ using load-time (run-time) weaving to provide a helpful service to the developer can be Spring's #Configuration annotation which allows you to use Dependency Injection on object not instantiated by Spring's BeanFactory.
You specifically mentioned modifying the method (or how it works), and an example of that being used is an aspect which intercepts am http request before being sent to the handler (either some Controller method or doPost, etc) and checking to see if the user is authorized to access that resource. Your aspect could then decide to return – prematurely – a response with a redirect to login. While not modifying the contents of the method per se, you are still modifying the way the method works my changing the return value it would otherwise give.
I would like to have Windsor inject multiple implementations of a service to a constructor.
My scenario is that I have multiple search providers that implement a common interface. I would like to register each of these with windsor and then inject them into my search service so it can query each on in turn.
Is such a thing possible with Windsor? Is there a better approach than injecting multiple implementations into the constructor?
See Inversion of Control and Dependency Injection with Castle Windsor Container - Part II at DotNetSlackers. It shows how to pass an array of the same service interface to an object.