Skip to content
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

Avoid locking the lazy provider when the value is cached #519

Closed
wants to merge 3 commits into from

Conversation

SentryMan
Copy link
Collaborator

@SentryMan SentryMan commented Mar 11, 2024

  • no longer locks the thread for every lazy provider request
  • change ProviderPromise to retrieve the provider from the bean map when get is called

@SentryMan SentryMan changed the title Avoid locking the lazy provide if cached Avoid locking the lazy provider when the value is cached Mar 11, 2024
@rob-bygrave
Copy link
Contributor

change ProviderPromise to retrieve the provider from the bean map when get is called

Why do that? This is changing the semantics?

@SentryMan
Copy link
Collaborator Author

Why do that?

I'm getting null pointer exceptions when trying to use a provider within a Beanscope.

@SentryMan
Copy link
Collaborator Author

SentryMan commented Mar 11, 2024

due to certain peculiarities with re-authenticating mongo I'm trying to register a Provider that will rotate the credentials and give the updated MongoCollection. It seems though that when I call get after wiring this happens

Cannot invoke "jakarta.inject.Provider.get()" because "this.provider" is null

Example Code:

class MyRepoImpl {

  final Provider<MongoCollection> cProv;

  MongoCollection coll;

  RepoImpl(Provider<MongoCollection> cProv){
    this.cProv = cProv;
    coll = cProv.get(); // dies here
  }
  
  getRotatedMongo() {
    coll = cProv.get();
  }

  someOperation() {
 
    //if some Auth Error
   getRotatedMongo()
  }
}

@rbygrave
Copy link
Contributor

Well ok but I think that means we need 2 separate PRs. We need to document the NPE bug as a bug with ideally a stack trace that folks might be able to find etc. Plus we need the history as people read it via the PR titles to reasonably reflect the change (and so currently the title does not reflect anything about a NPE bug).

So yeah, I think we need to split this into 2 PRs for those reasons.

@rbygrave
Copy link
Contributor

It seems though that when I call get after wiring this happens

Technically the get is being called during wiring. That is the constructor is called during wiring (and wiring has not completed yet and this is why the NPE). I think the expectation would have been to use a @PostConstuct here - Hmm.

rbygrave added a commit that referenced this pull request Mar 12, 2024
Note that with `Supplier<T>` its a little different than `Provider<T>` in that `Provider<T>` is used to support circular dependency wiring so its a way to delay the wiring (until after all the constructors are called).

We don't have that limitation with Supplier.
@rbygrave
Copy link
Contributor

My thought is that instead of Provider<MongoCollection> a Supplier<MongoCollection> could have been used here, a bit like: https://github.com/avaje/avaje-inject/pull/521/files

In this way the Supplier.get() method can be called inside the constructor (during wiring).

rbygrave added a commit that referenced this pull request Mar 12, 2024
Note that with `Supplier<T>` its a little different than `Provider<T>` in that `Provider<T>` is used to support circular dependency wiring so its a way to delay the wiring (until after all the constructors are called).

We don't have that limitation with Supplier.
@SentryMan SentryMan closed this Mar 12, 2024
auto-merge was automatically disabled March 12, 2024 13:28

Pull request was closed

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

Successfully merging this pull request may close these issues.

3 participants