Is there an idiomatic way to get a prototype scope

[killbulle]

Hi avaje teams
First of all thanks for this very compact and powerful framework !
i've a little question , i've played recently with avaje inject,
and ask my self if there is an idiomatic way to get a spring like prototype scope or to craft it
Regards
marc

[rbygrave]

idiomatic way to get a spring like prototype scope or to craft it

So I'll say no but it depends on whether a custom scope is appropriate.

Background: Prototype scope is not Spring specific but a scope available in many DI libraries like Guice etc. An alternative to using prototype scope is of course just create the instance ourselves in application code (via using new or factory methods). As I see it, the reason why we might want prototype scope is because we want the DI library to create that particular 'bean' rather than create it ourselves. The issue here is that I've never desired this myself in all my time using Spring, Guice over many years. The reason for that is that - it makes no sense to wire a prototype scoped bean into a bean of any other scope and the alternative to prototype scope is just plain application code (new or factory method).

That is, we can really only inject a prototype scope bean into other beans that are also prototype scope. We can inject beans of other scopes into prototype scope beans but this generally is better done using a simple factory method instead - we don't need DI for this.

So the question becomes, when is it desirable to have DI prototype scope rather than just using just using new or a factory method in application code?

Custom scope

With avaje-inject we can use a custom scope to build a group of 'beans' and have application code control the scope, effectively this allows us to support "singleton/optional singleton scope" or "request scope" or even "prototype scope" on all the beans defined in that custom scope. That is, the scope is controlled in application code for all the beans in that scope rather than the scope controlled on a per bean basis.

---

Can you explain your use case more? I'd like to know why there could be a preference for prototype scope (vs just using new or factory method).

Thanks, Rob.

[killbulle]

Thanks for this great response and your precious time!
I was also pretty sure of your response also :P
I'am also not a regular user of prototype beans and their usage a quite uncomon
The only usage i saw in the past (and my need today in fact but it know it can be easlys workarounded with "new")
is more to create instance of objects with depencencies to singletons
and then i can specialize later with some specific configuration object per prototype.
So it more "singleton per configuration object" need you see.
Also i've played also with your modul system and find it very easy to use.
I've benchmarked guice and dagger, and i'am an long time spring / micronaut user also
Avaje + Avaje config are so compact and easy and well documented
thanks for your great job
Regards marc

[rbygrave]

Right. The questions are:
Q1) Whether it would be a net positive if avaje-inject added prototype scope
Q2) Can we identify scenarios where we absolutely must have it. Scenarios we can't instead just use new or a factory method.

At the moment my thinking is:

• Adding it might not be net-positive assuming there are not cases where we absolutely need it.
• We have not yet hit known cases where we absolutely need it. For myself, I believe this changes if people build libraries on top of avaje-inject and those libraries use injection but allow for some customisation via components (and those customisation components could desire prototype scope due to having state that isn't thread safe) - so more a mix of application code that customises a third party library that uses avaje-inject ?

It might be a case of doing an investigation to see what complexity it would add and more taking the view that people won't be too confused and use it appropriately.

[rbygrave]

FYI: I added support for @Prototype via #188 ... and that is released with version 6.22 | 5.22 so you can try that option out if you like.

Adding support didn't add much complexity at all so hopefully people don't get too confused by it, we will find out in time :)

Cheers, Rob.

[killbulle]

thks i will give a try !
awesome

[rbygrave]

I'm going to add a second use case for @Prototype which is when we are looking to inject a "Builder". That is, we want to inject a "builder of thing" rather than the "thing" itself.

That is, "Builders" by their nature most often want to be prototype scope.

For example, let's say we want to use something like a FooBuilder, where some of the builder configuration is done in DI and some is done in the code/class that is going to use that builder.

In this case we might have a @Factory method returning a @Prototype @Bean like:

@Factory
MyFactory {

 @Prototype 
 @Bean
 FooBuilder fooBuilder() {
   ... // returning a "builder of thing" rather than "thing"
  }

}

And code using the FooBuilder would have a Provider<FooBuilder> injected into it.

Actually, code using the builder can just get the builder injected. Each time builder is injected it's a new builder instance not shared with anything else.

MyHttpClientUser {

  final FooBuilder builder; // this instance is not shared

  MyHttpClientUser(FooBuilder builder) {
    this.builder = builder;
  }
 
  void doStuff() {
   ..
   builder.set(...) // maybe do some configuration on the builder
   Foo foo = builder.build(); // gets its own unique instance of foo
   ...
  }

}

We could also inject a Provider<FooBuilder> like below, but really that isn't necessary.

MyHttpClientUser {

  final Provider<FooBuilder> provideBuilder;

  MyHttpClientUser(Provider<FooBuilder> provideBuilder) {
    this.provideBuilder = provideBuilder;
  }
 
  void doStuff() {
   ..
   FooBuilder builder = provideBuilder.get(); // builder is not a shared instance
   builder.set(...) // do some configuration on the builder maybe
   Foo foo = builder.build(); // gets its own unique instance of foo
   ...
  }

}

[avertx]

Kinda scratching my head with this one... I've never used DI before since I didn't like its "no arg constructors" ick and such.. when I heard of Avaje-inject, I jumped at the idea it could be useful for my "enforcement" constructor ideology. Alas, where is the ability to create prototype beans with arguments?

TLDR; like Spring's BeanFactory#getBean(String name, Object... args)

The simple use case is I'm implementing an abstract class from a thirdparty lib that has final variables set by calling super(), but would like some other fields of "mine" to be injected.

more discussions:
stackoverflow prototype-scoped-bean-with-runtime-arguments

stackoverflow.com spring-bean-with-runtime-constructor-arguments

using functions...

[SentryMan]

for something like this, my first thought is that I'd create a bean supplier and wire that.

@Singleton
public class MyBeanSupplier {

  private final InjectedBean injected;

  
  public MyBeanSupplier(InjectedBean injected) {
    this.injected = injected;
  }

  public MyBean supply(String customArg) {
    return new MyBean(injected, customArg);
  }
}

and use it like.

var scope = BeanScope.builder().build();
var beanSupplier = scope.get(MyBeanSupplier.class)
MyBean = beanSupplier.supply("");

you effectively get the same behavior

[SentryMan]

but would like some other fields of "mine" to be injected.

also by "mine" I'm assuming you mean that they are not managed by the bean scope. If they are managed you can do something like:

@Prototype
public class MyBeanSupplier extend ThirdParty {

  private final String custom;
  
  public MyBeanSupplier(InjectedBean injected, String custom) {
    super(injected);
    this.custom = custom;
  }
}