This is not the first time I work with Inversify, but never had a problem like such. Currently what I have in my project is just a bunch of decorated (properly, constructor injections) services, therefore I assume it's failing on building the metadata.
I'm getting Error: #inject called with undefined this could mean that the class X has a circular dependency problem. You can use a LazyServiceIdentifer to overcome this limitation. whenever I start the application (bear in mind - I don't have a container yet).
Following the "circular dependency problem" part I built a dependency graph using dependency-graph package and it shows no circular dependencies in my project, it also managed to properly generate registration order.
I'm wondering if there's any way to avoid using LazyServiceIdentifier everywhere in the project?
Additionaly I'm trying to understand how is it even possible for this error to occur when using constructor injection (and having no circular dependencies of course)?
Related
I'm extracting JPA entities into a separate Fat/Uber jar for external system to use.
ProGuard is used through com.github.wvengen:proguard-maven-plugin to shrink all other unused code.
I want to keep all methods in JPA entities except ones annotated by #javax.persistence.Transient annotation. I've found "!transient" for field modifiers in ProGuard rules, but seems that !#javax.persistence.Transient for methods does not work :(
Can I reach the same effect somehow for methods by other way ?
Unfortunately I've not got an answer on this question and was not be able to solve this by ProGuard+MavenPlugin directly, but I've resolved this problem with one additional step before run a ProGuard. I've just used ByteBuddy + Maven plugin on Maven phase before you run ProGuard Maven plugin and it will then optimize/remove the rest unused stuff, see details about byte-buddy instrumentation step here: byte-buddy remove/strip methods
"The ambiguity, is in the box" - Monty Python.
Autofac is having a problem resolving an interface. See attached solution.
The Interface, IAmbiguous, is defined in project ACommon. It is implemented in project AInjectable. The AInjectable project does not / cannot reference ACommon. The AInjectable project defines IAmbiguous as an existing item brought in with a file link.
The UI project calls ACommon Inject and attempts to register the AInjectable assembly. IAmbiguous is not ambiguous initially but after a builder.RegisterAssemblyTypes command it becomes "ambiguous in the namespace." There is no error thrown when the container is built but the registration is not there.
Registration can be done "AsImplementedInterfaces" if Named and Keyed is not used. But then there is no way to Resolve the registration because the service IAmbiguous is "ambiguous in the namespace."
This question was double-posted as an issue on Autofac. It is not an Autofac problem. I will copy/paste the answer from the issue in here; for future readers, if you want to see the repro solution, go check out the full issue
What you're doing by including the same interface in two different assemblies isn't something you should be doing. Note that by doing that, your AInjectable class is not implementing the interface from the ACommon project. It's implementing a different but identically named interface.
This sort of thing is a problem - having the same type (interface, class, whatever) name in two different assemblies. We even had a problem (#782) where we had a System.SerializableAttribute in Autofac as a shim for .NET Core. You really just can't do that.
You'll also see the same thing if you try to make a static extension method class that has the same namespace and name as some other static extension method class. Ambiguous references.
Without doing Reflection.Emit style code generation, you won't be able to declare an interface in one assembly ("Assembly A") and implement that interface in a different assembly ("Assembly B") without having Assembly B reference Assembly A. That's just how .NET works. What you're seeing is a manifestation of that when you use Autofac, but it's not caused by Autofac. It's caused by you doing something you shouldn't be doing in .NET.
The fix is to define your interfaces in a separate assembly that everyone implementing the interfaces can reference. (Or you can try to dynamically generate code using Reflection.Emit or Roslyn or something, but that's waaaay harder.)
After migrating to Play-2.1 I stuck into problem that routes compiler stopped working for my routes file. It's been completely fine with Play-2.0.4, but now I'm getting the build error and can't find any workaround for it.
In my project I'm using cake pattern, so controller actions are visible not through <package>.<controller class>.<action>, but through <package>.<component registry>.<controller instance>.<action>. New Play routes compiler is using all action path components except for the last two to form package name that will be used in managed sources (as far as I can get code in https://github.com/playframework/Play20/blob/2.1.0/framework/src/routes-compiler/src/main/scala/play/router/RoutesCompiler.scala). In my case it leads to situation when <package>.<component registry> is chosen as package name, which results in error during build:
[error] server/target/scala-2.10/src_managed/main/com/grumpycats/mmmtg/componentsRegistry/routes.java:5: componentsRegistry is already defined as object componentsRegistry
[error] package com.grumpycats.mmmtg.componentsRegistry;
I made the sample project to demonstrate this problem: https://github.com/rmihael/play-2.1-routes-problem
Is it possible to workaround this problem somehow without dropping cake pattern for controllers? It's the pity that I can't proceed with Play 2.1 due to this problem.
Because of reputation I can not create a comment.
The convention is that classes and objects start with upper case. This convention is applied to pattern matching as well. Looking at a string there seems to be no difference between a package object and normal object (appart from the case). I am not sure how Play 2.1 handles things, that's why this is not an answer but a comment.
You could try the new # syntax in the router. That allows you to create an instance from the Global class. You would still specify <package>.<controller class>.<action>, but in the Global you get it from somewhere else (for example a component registry).
You can find a bit of extra information here under the 'Managed Controller classes instantiation': http://www.playframework.com/documentation/2.1.0/Highlights
This demo project shows it's usage: https://github.com/guillaumebort/play20-spring-demo
I'm facing an issue where I have App1.ClassA Importing App2.ClassB which itself needs to import App2.ClassC in a property. App1 and App2 are 2 different xaps
App1.ClassA invokes ComponentInitializer.SatisfyImports(this) in its initializing code. However this chain of satisfying imports does not seem to cascade down across assemblies.
I cannot specify ComponentInitializer on ClassB, since it is exporting itself (and MEF throws an error).However, ClassC is not being imported into the property of ClassB without this invocation.
Is this the expected behaviour or am i seeing some other bug due to which ClassC is not getting loaded ?
I went through this post -http://forums.silverlight.net/forums/t/202811.aspx, but the difference may be that i am crossing over Xaps in my scenario
Thanks in advance
i am crossing over Xaps in my scenario
By default, ComponentInitializer will find only parts in the current XAP. You can override this default host configuration by calling CompositionHost.Initialize.
The chain of resolving imports was being respected even when crossing over xap boundries. I'm guessing that xap boundries are not even an issue for xap, as it works at assembly level and as long as the assembly is available, it will resolve all the imports in the dependency chain.
The mistake i made was not realizing that the imports are not resolved during class instantiation( so the resolved elements are not available in the constructor). I had to hook up for the IPartInitialized Notification, and take action when this event is raised.
I'm marking this as the correct answer not to boost standings but to guide anyone facing the same issue.
I'm trying to work through groovy's Implementing Local AST Transformations tutorial, but whenever I clean my project I get this error in each file that has the #WithLogging annotation in it:
Groovy:Could not find class for Transformation Processor AC.LoggingASTTransformation declared by AC.WithLogging
So you have a package named "AC" that contains both "WithLogging.groovy" and "LoggingASTTransformation.groovy" classes? Does it also contain any classes that implement the "WithLogging" interface?
If so, I'd suggest you move the class(es) that use your annotation to a location outside of the annotation defining package (the default will suffice, for diagnostic purposes) - Order of compilation matters with transformations. See this post on the groovy users mailing list for more on that.
Also try changing the annotation from #WithLogging to #AC.WithLogging.
As far as cleaning with Eclipse is concerned, I had a similar issue and found that I had to make a trivial modification after a clean to any file that contained my annotation. IE, add a space somewhere. Then save the file. This should rebuild everything properly.