Which Structuremap v3 Lifecycle is recommended to replace the old HybridLifecycle? Specifically for a UnitOfWork in a web app environment?
Add reference to StructureMap.Web Assembly.
Import these namespaces(they contain extension methods):
Imports StructureMap.Web
Imports StructureMap.Web.Pipeline
then you can use:
HybridHttpOrThreadLocalScoped
Related
I want to put a Java class in a Maven artifact that uses the Vaadin #Endpoint annotation (from com.vaadin.flow.server.connect.Endpoint), to use this class in multiple Vaadin projects.
Here is a simple example of such a class:
import com.vaadin.flow.server.connect.Endpoint;
import lombok.RequiredArgsConstructor;
import java.util.Optional;
#Endpoint
#RequiredArgsConstructor
public class SupportInfoEndpoint {
public Optional<String> getSupportInfo(){
return Optional.of("mailto:support#my.corp");
}
}
The Maven artifact includes the source code of the class. What do I have to do so this class is scanned in the using project, by the Vaadin build process, so that
the corresponding TypeScript code for the frontend is generated
the class is included in the Spring-Boot application (so the endpoint is actually available at run time)
Is it possible at all?
Like Erik said, it will be implemented with #9010.
But there is a workaround depending on some restrictions. If you have every class that the endpoint needs in the same jar, you could trigger the typescript generation in same the jar by calling the goal "build-frontend" of vaadin-maven-plugin, then the typescript is generated and it's just a matter of some maven magic to move them to META-INF/resources/frontend (something similar of what is being done here). Then you just can package the endpoints in the jar.
For registering the endpoint in the project, you need to do something similar to what this class is doing, basically a ServiceInitListener that will execute the method registerEndpoint of the EndpointRegistry by using reflection.
Unfortunately it is not currently possible, but it will be once #9010 is implemented.
It is my understanding that it is one of the highest priority features to implement for the Fusion team.
I am curious how I might set up the following:
Create a core Swift Package with some basic functionality.
Have other optional packages that dovetail with the core package (directly related). Could be 10+ function blocks of functionality.
So in a swift package, you hard-code in dependencies. I don't want that. To keep app size to a minimum and allowing developers to pick function blocks of code as they need, would one have a developer include the core package, and then other packages with specific functionality as they need - which somehow rely on the core package?
Would you just add the core swift package and then each function block swift package?
I am wondering how this could be set up to allow for flexibility for developers - keeping core function blocks separate so they would be pulled into a project as needed. Keeping things as simple as possible.
In a layered architecture there is typically no need for optional dependencies. In more messy dependency graphs, it can be really useful to have optional dependencies.
How to implement an optional dependency in a Swift Package?
A: Just don't add the dependency in the Package.swift file.
To use the Core package (lets call it MyCorePackage) the code will need to check if that package can be imported, like so:
#if canImport(MyCorePackage)
import MyCorePackage
#endif
struct MyRelatedType { ... }
#if canImport(MyCorePackage)
extension MyRelatedType {
var asCoreType: CoreType { ... }
}
#endif
aspnetBoilerplate is based on Domain Driven Design design pattern.
I see that aspnetBoilerplate compose an application using modules.
I didn't understand what a module is , i searched it's definition in the context of domain driven design and i found that it serves as a container for a specific set of classes of an application.
So does that means ,For example , in c# namespace is a module because it can contains many classes ?
But even with this definition , it's not clear in the context of aspnetBoilerplate, a module defintion in aspnetBoilerplate have this structure :
public class MyBlogApplicationModule : AbpModule
{
public override void Initialize()
{
IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
}
}
so it's just one class,that have one method !
Also what is the relationship between model and dependency injection ?
Why there is a registration of the model as a service in an IocContainer?
Abp module is just a way for you to organize your code under the same domain/layer and at the same time still being able to configure/interact with other modules
E.g. your module is a separate library project that contains certain domain logic, to initialize your module correctly, you can place the initialization code in module life cycle hooks
Note: register DI in the life cycle hooks is an example of interacting with the DI service (that might be configured outside of your project)
See
https://aspnetboilerplate.com/Pages/Documents/Module-System#lifecycle-methods
Abp provides convenient way to register classes that follows the convention
IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
Note: the recommended way is to only have a abp module per assembly
See
https://aspnetboilerplate.com/Pages/Documents/Dependency-Injection#registering-dependencies
What's the best way to use Dagger to inject dependencies into classes, especially zero-arg constructor classes like Activities, with Dagger? Will Dagger 2 possibly bring improvements to the situation?
Thanks in advance.
Since Kotlin M13 release, a new property has been especially added in order to support dependency injection (like with Dagger 1&2) and other frameworks.
It's called lateinit property. Taken from the documentation:
class Example {
#Inject
lateinit var bar: Bar
}
In a nutshell, bar has no initializers but is declared as a non-null type. If you try to read it before the initialization, an exception is thrown.
Otherwise, once it's initialized using Dagger, it can be used as a normal property.
Everything is well explained in the language doc and you can also check the blog post relative to the M13 release there.
I wasn't updating my answer for a while and it got outdated. Also noticed here new answer from #Ben that works for M13/M14.
Decided it would best if I redirect all of you interested to my template project which I try to keep up to date with latest Kotlin and Dagger 2 versios. Kotlin + Dagger 2 sample
I am describing there how to inject objects, including multiple annotations etc.
Dagger relies on annotation processing, which is not supported yet in Kotlin, as far as I know. But they say, it is planned. And while, you can either extend java classes with Dagger dependencies, or try some reflection based injection framework - Guice, Roboguice
for using dagger annotations in Kotlin
1- // dagger add dependencies in app level
implementation 'com.google.dagger:dagger:2.38.1'
kapt 'com.google.dagger:dagger-compiler:2.38.1'
add in app level/gradle
plugins {
id 'kotlin-kapt'
}
now you can use annotations like #Inject #Component etc
class Test{
#Inject
lateinit var name: String
}
I am using Castle Windsor to handle my Dependency Injection and it has been working great up until now.
However, i am now trying to extend my project and add some additional libraries - im now struggling to figure the best way to leverage Castle.
I currently have the following assemblies
MyProject.Interfaces (contains IDBContext interface)
MyProject.BusinessLogic (contains the Castle Windsor implementation)
MyProject.DataAccess (contains implementation of IDBContext)
I currently have an installer called DBContextInstaller and it simply implements the following:
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(AllTypes.FromThisAssembly()
.BasedOn<IDBContext>()
.WithService
.DefaultInterface()
.Configure(reg => reg.LifeStyle.PerWebRequest));
}
I now have a new Assembly in this project - lets call it MyProject.UserService and it happens to have a new concrete implementation of IDBContext.
So my question - how can i change my Container.Register statement to have it inspect multiple libraries. NOTE i totally expect to have more and more libraries added to this scenario in the future. I would love for this installer to just find all implementations.
TIA
You could use AllTypes.FromAssemblyInDirectory...
container.Register(AllTypes.FromAssemblyInDirectory(new AssemblyFilter(folderPath)));