I use Web API 2 and here is configuration of my unity container (i configure my rabbitmq dependencies):
container.RegisterInstance(new ConnectionFactory {
Uri = AppSettings.RmqConnectionString
});
container.RegisterType<IConnection, AutorecoveringConnection>(
new InjectionConstructor(typeof(ConnectionFactory), "tm.resource-server.api"),
new InjectionMethod("Init")
);
Right now i can't figure out, what's the default lifetime of this dependencies?
What time they would be created or resolve already existing instances.
Should i use my own lifetimemanager or use already existing (PerThreadLifetimeManager for example)?
RegisterInstance's default lifetime is ContainerControlledLifetimeManager
RegisterType's default lifetime is TransientLifetimeManager
Related
I want to configure the properties of the Tomcat JDBC Pool with custom parameter values. The pool is bootstrapped by the spring-cloud (Spring Cloud Connector) environment (Cloud Foundry) and connected to a PostgreSQL database. In particular, I want to set the minIdle, maxIdle and initialSize properties for the given pool.
In a "spring-vanilla" environment (non-cloud) the properties can be easily set by using
application.properties / .yaml files with environment properties,
#ConfigurationProperties annotation.
However, this approach doesn't transfer to my Cloud environment, where the URL (and other parameters) are injected from the environment variable VCAP_SERVICES (via the ServiceInfo instances). I don't want to re-implement the logic which Spring Cloud already did with its connectors.
After some searching I also stumbled over some tutorials / guides, which suggest to make use of the PoolConfig object (e.g. http://cloud.spring.io/spring-cloud-connectors/spring-cloud-spring-service-connector.html#_relational_database_db2_mysql_oracle_postgresql_sql_server). However, that way one cannot set the properties I need but merely the following three:
minPoolSize,
maxPoolSize,
maxWaitTime.
Note that I don't want to set connection-related properties (such as charset), but the properties are associated with the pool itself.
In essence, I would like to do the configuration similarly to https://www.baeldung.com/spring-boot-tomcat-connection-pool (using spring.datasource.tomcat.* properties). The problem with that approach is that the properties are not considered if the datasource was created by Spring Cloud. The article https://dzone.com/articles/binding-data-services-spring, section "Using a CloudFactory to create a DataSource", claims that the following code snippet makes it so that the configuration "can be tweaked using application.properties via spring.datasource.* properties":
#Bean
#ConfigurationProperties(DataSourceProperties.PREFIX)
public DataSource dataSource() {
return cloud().getSingletonServiceConnector(DataSource.class, null);
}
However, my own local test (with spring-cloud:Greenwich.RELEASE and spring-boot-starter-parent:2.1.3.RELEASE) showed that those property values are simply ignored.
I found an ugly way to solve my problem but I think it's not appropriate:
Let spring-cloud create the DataSource, which is not the pooled DataSource directly,
check that the reference is a descendant of a DelegatingDataSource,
resolve the delegate, which is then the pool itself,
change the properties programmatically directly at the pool itself.
I do not believe that this is the right way as I am using internal knowledge (on the layering of datasources). Additionally, this approach does not work for the property initialSize, which is only considered when the pool is created.
I have spring boot micro-service with database credentials define in the application properties.
spring.datasource.url=<<url>>
spring.datasource.username=<<username>>
spring.datasource.password=<<password>>
We do not use spring data source to create the connection manually. Only Spring create the database connection with JPA.(org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration)
We only provide the application properties, but spring create the connections automatically to use with the database connection pool.
Our requirement to enhance the security without using db properties in clear text. Two possible methods.
Encrypt the database credentials
Use the AWS secret manager. (then get the credential with the application load)
For the option1, jasypt can be used, since we are just providing the properties only and do not want to create the data source manually, how to do to understand by the spring framework is the problem. If better I can get some working sample or methods.
Regarding the option-2,
first we need to define secretName.
use the secertName and get the database credentials from AWS secret manager.
update the application.properties programatically to understand by spring framework. (I need to know this step)
I need to use either option1 and option2. Mentioned the issues with each option.
What you could do is use environment variables for your properties. You can use them like this:
spring.datasource.url=${SECRET_URL}
You could then retrieve these and start your Spring process using a ProcessBuilder. (Or set the variables any other way)
I have found the solution for my problem.
We need to define org.springframework.context.ApplicationListenerin spring.factories file. It should define the required application context listener like below.
org.springframework.context.ApplicationListener=com.sample.PropsLoader
PropsLoader class is like this.
public class PropsLoader implements ApplicationListener<ApplicationEnvironmentPreparedEvent> {
#Override
public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
ConfigurableEnvironment environment = event.getEnvironment();
String appEnv = environment.getProperty("application.env");
//set new properties based on the application environment.
// calling other methods and depends on the enviornment and get the required value set
Properties props = new Properties();
props.put("new_property", "value");
environment.getPropertySources().addFirst(new PropertiesPropertySource("props", props));
}
}
spring.factories file should define under the resources package and META-INF
folder.
This will set the application context with new properties before loading any other beans.
I attempted to reproduce the method described in this great article by Andrew Lock. However, I am unable to get this running in a .NET core 1.1 console application. When the appsettings.json file is changed and saved, the changes are not reflected in the application without restarting it.
There are multiple files involved, so I created the smallest example I could come up on github. I also provided details in the README.MD file on github.
Any help in resolving this would be most appreciated. Please keep in mind I am new to .NET core, and not an experienced developer. And this is my first question on stackoverflow... Thanks in advance!
The key thing to understand is scope.
There are three scopes in ASP.NET Core - transient, scoped, and singleton. IOptionsSnapshot is configured as a scoped service.
In ASP.NET Core, a scope is started for every request, so every request, you would get a new instance of IOptionsSnapshot, with updated configuration values.
In the example you provided, you are creating an IServiceProvider, and are fetching an instance of IMyService directly from the top level provider:
IServiceCollection services = new ServiceCollection();
Startup startup = new Startup();
startup.ConfigureServices(services);
IServiceProvider serviceProvider = services.BuildServiceProvider();
while (true)
{
var service = serviceProvider.GetService<IMyService>();
var reply = service.DoSomething();
Console.WriteLine(reply);
}
Essentially, you're always using the same scope for every request to the service provider, so you're always getting the same instance of IOptionsSnapshot. Effectively, if you never create a new scope, all of your scoped services become singletons!
The way to fix this is to create a new scope each time you fetch the service:
IServiceCollection services = new ServiceCollection();
Startup startup = new Startup();
startup.ConfigureServices(services);
IServiceProvider serviceProvider = services.BuildServiceProvider();
while (true)
{
using (var scope = serviceProvider.CreateScope())
{
var service = scope.ServiceProvider.GetService<IMyService>();
var reply = service.DoSomething();
Console.WriteLine(reply);
}
}
This also becomes important if you're doing things like creating an EF Core DbContext outside the context of a request in ASP.NET Core app (or in a console app). Always create a new scope before accessing services from the service provider!
P.S. I've created a pull request to fix your sample :)
So I already success implement SSO using spring session and redis on development localhost domain.
But when I deploy to server using two sub domain.
login.example.com
apps.example.com
They always create new session Id on each sub domain.
I already try to configure using Context in tomcat configuration.
<Context sessionCookieDomain=".example.com" sessionCookiePath="/">
But no luck.
Spring session moves the session management on application level, so no surprise that trying to configure the container (in your case tomcat) has no effect. Currently there is a TODO in spring-session code to allow setting the domain, but is not implemented.
Maybe it is best to open an issue to allow setting the domain or comment/vote on https://github.com/spring-projects/spring-session/issues/112.
Meanwhile a workaround would be to go with your own implementation of MultiHttpSessionStrategy based on CookieHttpSessionStrategy.
Finally I succeeded to setdomain on application level.
You're right, I hope in the future they implement the feature to set domain.
For now I create CustomCookieHttpSessionStrategy for my own implmentation.
private Cookie createSessionCookie(HttpServletRequest request,
Map<String, String> sessionIds) {
...
sessionCookie.setDomain(".example.com");
// TODO set domain?
...
}
And then register bean as HttpSessionStrategy.
I am quite sure I am missing a very basic and simple thing here.
I am using Autofac and it's multitenant container as below
var builder = new ContainerBuilder();
// Registratino of modules here
var container = builder.Build();
var tenantStrategy = new AppSettingsTenantIdentifier(appSettings);
var mtc = new MultitenantContainer(tenantStrategy, container);
//Registration of tenant specific modules here
var resolver = new AutofacWebApiDependencyResolver(mtc);
GlobalConfiguration.Configuration.DependencyResolver = resolver;
This is called from Application_Start. After above is called, I try to resolved one of the registered classes as below
var webApiConfig = GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof (WebApiConfig)) as WebApiConfig;
One of the dependencies on this class is registered as InstancePerAPiRequest. At this point I get following error.
No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario.) Under the web integration always request dependencies from the DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
I am not sure how can I fix this. I Know that I can create a new lifetime scope with tag AutofacWebRequest and then resolve using that lifetime scope but that does not look right to me.
If you register something as InstancePerRequest or InstancePerApiRequest then you can't resolve it outside of a request.
If you need to resolve a dependency outside of a request lifetime (outside an actual API request), choose a different lifetime for it. InstancePerLifetimeScope is very close to InstancePerApiRequest and will work on a per-request basis, too.
But be careful: If you resolve something outside a request from the container and it is IDisposable then the object will stick around for the lifetime of the application because Autofac will hold onto it and try to dispose it for you. If you're unaware of the behavior, this can be a slow memory leak. You can read more about that on the Autofac wiki.