Activities of "LW"

Hi, that won't matter. For some reason the module initalization tries to initialize the scheduler twice if I have two tests. The problem is in the initalization, not in how I get the scheduler in my tests.

Hello, thank you for your answer. I wasn't quite clear on what I was testing. I'm not trying to test the Quarz library, I'm just using it as a tool in my test to assert my logic.

public Ctor(Guid tenantId, string tenantName, string scheduleDefinition)
		{
			Check.NotNullOrEmpty(tenantName, nameof(tenantName));
            Check.NotNullOrEmpty(scheduleDefinition, nameof(scheduleDefinition));

			JobDataMap jobDataMap = new()
			{
				{ "TenantId", tenantId }
			};
			JobDetail = JobBuilder.Create<ScheduledControlValueCalculationBackgroundWorker>()
				.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
				.SetJobData(jobDataMap)
				.Build();
			Trigger = TriggerBuilder.Create()
				.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
				/* 
				 * Put the schedule to the definition and do the rescheduling based on that info. No other easy way to check
				 * if the triggers are really the same. 
				 */
				.WithDescription(scheduleDefinition)
				.WithCronSchedule(scheduleDefinition, options => options.WithMisfireHandlingInstructionFireAndProceed() )
				.Build();
			
			ScheduleJob = async scheduler =>
			{
				if (!await scheduler.CheckExists(JobDetail.Key))
				{
					await scheduler.ScheduleJob(JobDetail, Trigger);
				}
				else
				{
					// If the job already exists there might be changes to the schedule so reschedule the job if so
					IJobDetail jobDetail = await scheduler.GetJobDetail(JobDetail.Key);
					
					var trigger = await scheduler.GetTrigger(Trigger.Key);
					if(trigger.Description != Trigger.Description)
					{
						await scheduler.RescheduleJob(trigger.Key, Trigger);
					}
				}
			};
		}
  • ABP Framework version: 4.4.0

  • UI type: Angular

  • DB provider: EF Core

  • Tiered (MVC) or Identity Server Separated (Angular): yes

  • **Exception message and stack trace olo.Abp.AbpInitializationException : An error occurred during the initialize Volo.Abp.Modularity.OnApplicationInitializationModuleLifecycleContributor phase of the module Volo.Abp.Quartz.AbpQuartzModule, Volo.Abp.Quartz, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null: An exception was thrown while activating λ:Quartz.IScheduler.. See the inner exception for details. ---- Autofac.Core.DependencyResolutionException : An exception was thrown while activating λ:Quartz.IScheduler. -------- Quartz.SchedulerException : Scheduler with name 'QuartzScheduler' already exists.

    Stack Trace: ModuleManager.InitializeModules(ApplicationInitializationContext context) AbpApplicationBase.InitializeModules() AbpApplicationWithExternalServiceProvider.Initialize(IServiceProvider serviceProvider) AbpIntegratedTest1.ctor() BackgroundProcessesTestBase1.ctor() SchedulerCreationFailingTestExample.ctor() ----- Inner Stack Trace ----- ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ResolvePipeline.Invoke(ResolveRequestContext ctxt) <42 more frames...> AsyncHelper.RunSync[TResult](Func1 func) <>c.<ConfigureServices>b__1_1(IServiceProvider serviceProvider) <>c__DisplayClass3_0.<Register>b__0(IComponentContext context, IEnumerable1 parameters) DelegateActivator.ActivateInstance(IComponentContext context, IEnumerable1 parameters) DelegateActivator.<ConfigurePipeline>b__2_0(ResolveRequestContext ctxt, Action1 next) DelegateMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) DisposalTrackingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next)

  • **Steps to reproduce the issue:

I'm tring to unit test my Quarz background workers. Whenever I run multiple tests where I initialize a backround worker the tests fail because the IScheduler is already created with another test. My tests are integration tests since I need some registered services in my workers. I dosen't make a difference if I use a new scheduler for the actual scheduling in my tests like this:

	IScheduler scheduler = await GetNewScheduler();

    // Act
    ISchedulerListener listener = Substitute.For<ISchedulerListener>();
    scheduler.ListenerManager.AddSchedulerListener(listener);
    await worker.ScheduleJob.Invoke(scheduler);

My test module depend on a module that depends on AbpBackgroundWorkersQuartzModule and through that the Quartz gets initialized. It seems to me that AbpIntegratedTest initialization doesn't take into account that the Quartz cannot be initialized multiple times. I realize that this is possibly a Quarz problem but is there a some way to change the Quarz initialization so that IScheduler implementation will be initialized only once.

OK, I have done that. How can I share this with you?

  • ABP Framework version: 4.4.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): yes
  • Exception message and stack trace:
  • Autofac.Core.DependencyResolutionException: 'An exception was thrown while activating Volo.Abp.SettingManagement.EntityFrameworkCore.SettingManagementDbContext -> λ:Microsoft.EntityFrameworkCore.DbContextOptions`1[[Volo.Abp.SettingManagement.EntityFrameworkCore.SettingManagementDbContext, Volo.Abp.SettingManagement.EntityFrameworkCore, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null]].'

ArgumentNullException: Value cannot be null. Arg_ParamName_Name (ConnectionString)

  • Steps to reproduce the issue:"

I created a new console application with the cli generator. After that I created a module that depends on the settings module. Apparently this brings a dependency to SettingManagementDbContext. My intend was to create a unit test module to test the module and I mimiced the Domain.test -project initilaziation from another application. However this time the initilization wants to use the real database instead of the in memory -database for SettingManagementDbContext.

What should I do in the test base initialization to make a generic module to use in memory-database?

Not publicly unless I do a new similar but generic project.

  • ABP Framework version: 4.4.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): yes

I Have two questions:

  1. I Created a background process console application to handle longer, scheduled calculations. In that application I defined calculation scheduling settings provider:
	public class TenantCalculationTimeSettingProvider : SettingDefinitionProvider
	{
		public override void Define(ISettingDefinitionContext context)
		{
			context.Add(
				new SettingDefinition("CalculationTimeCronConf"
				, "0 */1 * ? * *"
				, new LocalizableString(typeof(TenantCalculationTimeSettingProvider), "configuration for time scheduled calculation")
				,new LocalizableString(typeof(TenantCalculationTimeSettingProvider), "configuration for time scheduled calculation")
			));
		}
	}

I cannot get the Define-method to fire no matter what I try. I have added the dependency to AbpSettingsModule and tried to register the provider manually



   public override void ConfigureServices(ServiceConfigurationContext context)
		{
			Configure<AbpSettingOptions>(options =>
			{
				options.DefinitionProviders.Add<TenantCalculationTimeSettingProvider>();
			});
		}

If I add the same provider in my main web application it works. I'm I missing some dependency in my new application for the Define to work?

2 If I define the setting this way, is there an Angular component (In commersial package perhaps) that enables viewing and editing this setting?

  • ABP Framework version: v4.4.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): yes

Hello, is there a reason why no foreign key constraints are create from the audit fields CreatorId and LastModifierId to the user? Is is preferred to keep that way or could we add such contraints? Our use case is to show the last updater user in UI.

Ok, thank you. I get the impression that you would not prefer DbContext inheritance in any case. What problems do you see in that approach?

Thank you for your answer! Can you please clarify what this means "To not have problem in your migration, don't include this mapping in the unified migration." If I create the "dublicate" entity into module A. I have to have entity configuration to map the entity into the same table. How would I then exclude the configuration from migration creation?

Showing 41 to 50 of 56 entries
Made with ❤️ on ABP v8.2.0-preview Updated on March 25, 2024, 15:11