Skip to content

Bug: D/I container selects the wrong class #604

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bart-degreed opened this issue Oct 31, 2019 · 5 comments
Closed

Bug: D/I container selects the wrong class #604

bart-degreed opened this issue Oct 31, 2019 · 5 comments

Comments

@bart-degreed
Copy link
Contributor

Description

I have an EF model with two entities: User and Content. Created controllers etc according to getting-started documentation.

I wanted to override filtering for Content, so created custom classes:

public class ContentResourceService : EntityResourceService<Content, long> { }
public class ContentEntityRepository : DefaultEntityRepository<Content, long> { }

Registered them as described at https://json-api-dotnet.github.io/#/layer-overview:

services.AddScoped<IResourceService<Content, long>, ContentResourceService>();
services.AddScoped<IEntityRepository<Content, long>, ContentEntityRepository>();

Now getting a list of content works as expected, but getting a list of users returns:

{
  "errors": [
    {
      "title": "InvalidCastException",
      "detail": "Unable to cast object of type 'ApiFrameworkTryout2.Controllers.ContentResourceService' to type 'JsonApiDotNetCore.Services.IResourceService`2[ApiFrameworkTryout2.Models.User,System.Int64]'.",
      "status": "500",
      "meta": {
        "stackTrace": [
          "System.InvalidCastException: Unable to cast object of type 'ApiFrameworkTryout2.Controllers.ContentResourceService' to type 'JsonApiDotNetCore.Services.IResourceService`2[ApiFrameworkTryout2.Models.User,System.Int64]'.\r",
          "   at object lambda_method(Closure, IServiceProvider, object[])\r",
          "   at Func<ControllerContext, object> Microsoft.AspNetCore.Mvc.Controllers.ControllerActivatorProvider.CreateActivator(ControllerActionDescriptor descriptor)+(ControllerContext controllerContext) => { }\r",
          "   at Func<ControllerContext, object> Microsoft.AspNetCore.Mvc.Controllers.ControllerFactoryProvider.CreateControllerFactory(ControllerActionDescriptor descriptor)+CreateController(ControllerContext controllerContext)\r",
          "   at Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted)\r",
          "   at async Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()\r",
          "   at async Task Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextExceptionFilterAsync()"
        ]
      }
    }
  ]
}

Version used: 4.0.0-alpha3

@maurei
Copy link
Member

maurei commented Nov 1, 2019

@bart-degreed there's nothing evidently wrong with the code you're sharing. If you can share your ApiFrameworkTryout2 repository or a similar small reproduction repository I can look into it further.

@bart-degreed
Copy link
Contributor Author

I have created a minimal repro solution: ApiDependencyBugRepro.zip

See code in Startup.cs:

const bool showError = true;

if (showError)
{
    var mvcBuilder = services.AddMvcCore();

    services.AddJsonApi(options =>
    {
        options.Namespace = "api";
    }, mvcBuilder, discovery => discovery.AddCurrentAssembly());
}
else
{
    services.AddJsonApi<AppDbContext>(options =>
    {
        options.Namespace = "api";
    });
}

the first block throws, while the second (showError == false) works as expected. Moving my custom registrations above or below this code fragment does not seem to make a difference.

@maurei
Copy link
Member

maurei commented Nov 1, 2019

I ran your code and tried true and false for showError while triggered the /api/content route. In neither cases I can reproduce the error you reported. The constructor of both custom services are triggered.

Can you double check your repro?

Got it: api/user route. Investigating

@maurei
Copy link
Member

maurei commented Nov 1, 2019

The problem is an issue with the auto discovery not correctly determining to which resource your custom service belongs to. It has already been fixed in v4 in #591. You can check out the latest version of the master branch for this fix, I'm planning on doing an alpha release next week.

(There are a bunch of breaking changes among which an update to .net core 3, so I'm hoping to create a first draft of the migration guide before doing so)

Thanks for reporting the issue nevertheless :)

@maurei maurei closed this as completed Nov 1, 2019
@bart-degreed
Copy link
Contributor Author

Thanks for looking into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants