I would like to have a central weld container that holds all my services and so on. This container would however be wrapped by a second container which contains local settings. The goal is if a dependency cannot be found in the outer container then I would like to then search the inner container.
How can I achieve this? I would prefer to do things in a standlike manner, without reverting to use of non standard WELD extensions.
I don't think you can do this. There is one BeanManager, which resolves dependencies by looking if any if its Contexts (related to scopes) contains the desired dependency.
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
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)?
While upgrading to 6.4, we ran pattern detector report and got below lines for ECU category. Is there any reference to fix this issue?
Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/projectteam referenced at
/apps/cq/core/content/projects/gadgets/xtrftranslationprojectsummary/jcr:content/content/items/form/items/fixedcolumns/items/column2/items/tabs/items/tab1/items/projectmembers
One more:
Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/wizard/properties/thumbnail referenced at
/apps/cq/core/content/projects/wizard/xtrftranslationproject/defaultproject/items/column1/items/cover
As per the official documentation on Extraneous Content Usage, this means that your custom code uses components that are considered internal and are not part of the API. Both errors say you referenced them so we're looking at simple use (rather than an overlay or inheritance based on sling:resourceSuperType). You just have a couple resources with the sling:resourceType values belonging to internal components whose use in this context is not something that's officially supported or tested.
They may break at some point when you upgrade to a newer version of AEM or try to apply a hotfix.
The best way to go forward would be to stop using them and replace them with other components that are considered public and therefore supported. If no suitable replacement is available, you should consider replacing them with custom code that you control.
I'm not familiar with either cq/gui/components/projects/admin/projectteam or cq/gui/components/projects/admin/wizard/properties/thumbnail so I can't recommend any replacements. Any potential replacement should have the mixin type of either granite:PublicArea (can be used, overlaid or inherited), granite:AbstractArea (can be inherited but not overlaid or used directly) or granite:FinalArea (can be used but not inherited).
I have tried almost everything, but I cannot get AutoMapper to map A => B when B doesn't have a parameterless constructor.
I'm using Unity and all the dependencies are registered conveniently but, how do I say to AutoMapper "hey, if the target instance needs some dependency in the constructor, ask Unity to build it, and do the mapping later.
I've tried with
Mapper.Initialize(configuration =>
{
configuration.ConstructServicesUsing(container.Resolve);
configuration.CreateMap<Person, PersonViewModel>();
});
But it doesn't work :(
EDIT: In fact, I lied a bit. I'm not using Unity. I'm using Grace, but didn't want to come up with a relatively unknown container asking about advances topics :)
I've solved the problem and it works as smooth as silk. The exact code is like this. Keep in mind that I'm using the Grace IoC Container (which I eagerly recommend).
Bootstrapper.Instance.Configure(new CompositionRoot());
Mapper.Configuration.ConstructServicesUsing(type => Bootstrapper.Instance.Container.Locate(type));
Mapper.CreateMap<Person, PersonViewModel>()
.ConstructUsingServiceLocator();
Like this:
configuration.CreateMap<Person, PersonViewModel>()
.ConstructUsingServiceLocator();
Do this for each mapping that should be created by your service locator.
In JOGL, there are lots of native jars for different OS x arch combinations. JOGL has several of its own mechanisms to load the right ones if you aren't using java.library.path, and supports a kind of "fat jar" layout.
In a fat jar layout, any native libraries need to be in a subdirectory ./natives/os.and.arch/. However, since the native jars themselves don't have any internal layout, similarly named so/dylib/dll files collide the flat hierarchy in the final jar.
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time. Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
Example
jogl-all-2.1.3-natives-android-armv6.jar is pulled in through a dependency.
$ jar -tf jogl-all-2.1.3-natives-linux-amd64.jar
META-INF/MANIFEST.MF
libjogl_mobile.so
libnewt.so
I'd like this to go here in the final jar:
./natives/
./natives/linux.and.amd64/
./natives/linux.and.amd64/libnewt.so
./natives/linux.and.amd64/libjogl_mobile.so
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time.
All merge strategies are invoked every time. MergeStrategy.deduplicate, which is the default strategy for most files, just happens to take effect only if there's a collision.
MergeStrategy.rename, applied for README and license files by default for example, will rename the file every time by appending the jar name.
Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
There's no strategy out of the box that does exactly that, but you can define a custom strategy similar to MergeStrategy.rename.
Just follow this rule as Xerxes explained here. There is then no longer any risk of collision. The official JogAmp forum is a better place to ask questions about all JogAmp APIs. If you don't follow my advice, GlueGen will be unable to extract and load the correct native libraries. In your case, natives/linux-amd64 is correct whereas natives/linux.and.amd64 isn't.