Replacement for @New to force the creation of a new instance of a Bean at injection point

I am currently migration to CDI4.0 and I was using @New annotation to force the creation of a new instance of a bean at injection point. What can be used now for such behavior?
Here is a small example on the usage I have for now. Injecting two executor services and I expect to have two different thread pools.
@ApplicationScoped
public class MyExecutorService implements ExecutorService {
}

@Singleton
public class ExecutorServiceProvider  {

    private final ExecutorService executor1;
    private final ExecutorService executor2;

    @Inject
    ExecutorServiceProvider(
        ExecutorService executor1,
        @New(MyExecutorService.class) ExecutorService executor2
    )

@New has been deprecated since CDI 1.1 with the suggestion to use @Dependent beans.
I'm not sure if your code relies on MyExecutorService being @ApplicationScoped outside of ExecutorServiceProvider, but if not, changing the scope of MyExecutorService to @Dependent would do what you need.

Yes I do need the ApplicationScoped for the MyExecutorService bean, it is a thread pool and I don't want a new thread pool to be created for each new injection.

I don't want a new thread pool to be created for each new injection

except for ExecutorServiceProvider ;-)
I guess you could have an "internal" @Dependent-scoped bean that is "wrapped" into an "external" @ApplicationScoped MyExecutorService bean. Or you could create the 2nd instance of MyExecutorService manually.

If I use a wrapper it is quite risky I end up with several thread pools where I don't expect them. I think I'll create manually the bean but it's sad this feature have been removed even if it is not widely used.

but it's sad this feature have been removed even if it is not widely used

Well, it got deprecated 10 yrs ago - see CDI-170. The issue description is IMO a bit misleading because a @New injection point receives a bean instance that is not bound to the scope, but has dependency injection performed and interceptors applied (because the @New bean has the same interceptor bindings).
But one of the problems I can see is that you can't use other qualifiers on a  @New injection point. This is not a problem for class-based beans where each bean has a different bean class but a unique bean class is not required for custom/synthetic beans.
I'd recommend you to use two different beans. The first would be @ApplicationScoped  and would represent a shared ExecutorService. The other one would be @Dependent and would represent a ExecutorService instantiated for each injection point. These two beans can extend a class with common logic/injection points etc. You can either use the specific type for an injection point or introduce a new qualifier for the @Dependent variant.

The annotation was not annotated as @java.lang.Deprecated so we haven't realized it was deprecated.
Creating a new hierarchy looks a bit complex to me to assign a specific scope to the bean (ParentExecutorService with two childs SingletonExecutorService and NewExecutorService) but anyway I guess it's the only way for CDI without adding other complexities.
I have instantiated manually the bean to solve my problem.

The annotation was not annotated as @java.lang.Deprecated so we haven't realized it was deprecated.

You're right and I have no idea why. Maybe it was a JCP/Java EE requirement or something like this.

I have instantiated manually the bean to solve my problem.

+1


Can't create an Either that has the same type for success and error

The create method for either uses the type to disambiguate between the success and error case. So code such as this will not compile:
var x = Either<string, string>.Create("hello"); <-- doesn't compile
I'm not sure if this was a design decision made on purpose?
If it is not by design then some suggestions for the change are:
public static Either<Success, Error> Error(Error value) =>
            new ErrorContainer(value);
public static Either<Success, Error> Success(Success value) =>
            new SuccessContainer(value);

Or
public static Either<Success, Error> CreateError(Error value) =>
            new ErrorContainer(value);
public static Either<Success, Error> Create(Success value) =>
            new SuccessContainer(value);

However, in either case (lol), the implicit operator will stop working for one of the cases. Perhaps it could work for the success case and the error case must be explicitly created? This would make the change a breaking change.

Hmm, that first case is definitely just an oversight, I think it'd be a good idea to Obsolete that create method and replace it with Success and Error.

The implicits can't really work - I think it would be better to throw an ambiguous type error or maybe try to create a specialised version when Error == Success. I don't know if we can express that in C# though?

Ok, so this commit will at least allow you to use the type, but I don't think there's anyway to order the implicits.
The only way to get that behaviour would be to drop the implicit operator for Error, which I don't think is worth the breaking change.
I'd accept a monomorphic Either<A> PR, or a PR which adds your desired behaviour to a new type in a seperate namespace, like what has been done with unsafe option.

I'm not so sure that an Either<A> is a good idea.
For example, how would map work? You could force users to provide two mappers like this:
public Either<NextT> Map<NextT>(Func<T, NextT> successMapper, Func<T, NextT> errorMapper) { ... }
But that is no longer a standard map signature and it seems unlikely to be useful because the common usage of a map would be to change the success type and leave the error type unchanged.
I guess you could also add a method to map to Either<Success,Error>:
public Either<Success, T> MapToEither<Success>(Func<T, Success> mapper) { ... }
But there is no way to constrain the types so that Success != T.
It seems like a bad idea.

Closing since the original problem is fixed.


Nft catalog not working in web enviroment

Issue:

when importing the npm package into a react app, the app does not load at all
the app crashes with Uncaught (in promise) ReferenceError: global is not defined

Possible cause:

https://github.com/dapperlabs/nft-catalog/blob/11c950f97512a46d5dc8df5fcd1be3a0da1fca68/webpack.config.js#L4 defined the target as node, https://stackoverflow.com/questions/45175521/referenceerror-global-is-not-defined-at-eval (similar issue on stackoverflow)

Again, thanks for developing this package :+1: helps a lot :)

What npm version of the package are you using?
Are you able to share the code that you are using to import and use the package?

The latest from the npm, I dont have my PC here, but I literaly started working with it today. 0.1.1 I think.
I can't really share the my code, but my guess is that it will be the same issue sinple create-react-app since the bundle.js uses global which is not accessible in the browser. At least according to that stack overflow issue.

I am also running a react app and having the same "Global is not defined" issue.

i think the problem is in the webpack config. nft-catalog is being bundled up for use in a node app: https://github.com/dapperlabs/nft-catalog/blob/main/webpack.config.js#L4
we can add a secondary config that bundles this up for client-side consumption