Can I Inject x Class?

[Joe DeSantis]

I was working with a JUnit 5 extension for Guice, and we had the need to 
determine if a particular class was able to be injected by an injector.
The only solution we came up with is attempting to get an instance with 
that Injector. (Literally calling the getInstance method, in a try/catch 
block).
So my question is simply, what is the best way of determining if you can 
get an instance of a particular class given an injector.

The discussion on the implementation is here for anyone who is curious,
https://github.com/JeffreyFalgout/junit5-extensions/commit/adf2f4ece977e834ba9b4f1563ebc568784ad3a4#commitcomment-29425765

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-guice/dbbc0674-7e82-47de-97ee-6bdf9258d2fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic binding inference

[Stephan Classen]

I guess then you are on your own.

I don't think Guice provide such a feature out of the box.
You could write a custom Module which reads the properties files and 
creates bindings for each and every one.
As long as all of them are simple just like the examples you gave I 
think you should be able to get this done in a few lines of code.
But I don't know Spring enough to tell if there are complex cases which 
you would also need to support...


Good luck

And if you have any concrete question don't hesitate to ask



On 19.06.2018 17:17, 'Mariano Gonzalez' via google-guice wrote:
The reason for binding as properties is basically backwards 
compatibility. This is a legacy system originally built with spring. 
I'm trying to move to guice because spring is way too heavy and takes 
a long time to start, but all of this works out of the box.


Unfortunately, having each plugin ship with a module is not an option 
in this case, which is why I'm looking for a way to leverage guice 
goodies while while keeping spring's behavior.


Thanks

On Tue, Jun 19, 2018, 12:09 PM Stephan Classen > wrote:


I don't think this would be a good approach. And I am not even
sure if guice would allow it.
I would rather propose that every plugin comes with a Module which
is then passed to the injector creation method.
This way every plugin can bind whatever it needs.
If multiple plugins try to bind the same thing you could always
encapsulate a plugin in a private module and only expose a limited
set of bindings.

If I miss the point here then maybe try to explain why you are
passing bindings in properties files...



On 19.06.2018 16:45, 'Mariano Gonzalez' via google-guice wrote:

Thank you.

Yes I looked at Multibinders but this still requires the brute
force approach. Each of my plugins can register any random
object, I don't know the universe of interfaces before hand. I
was more looking in the direction of somehow tapping into how the
bindings are processed  so that when Guice realises that it
cannot serve @Inject FooService I can catch that and calculate
that binding on demand?

Is this or something like that possible?

Thanks

On Tuesday, June 19, 2018 at 11:36:08 AM UTC-3, scl wrote:

You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings

Then bind all possible implementations of an interface and
use the value from the properties to select the one out of
the set.



On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:

Hello,

I have a case in which a portion of the binding are
dynamically provided through a properties file with the
following format:

|
exampleService=ExampleServiceImpl
fooService=FooServiceImpl

|

Unlike Guice's approach, the key is not a type but an actual
Name. For now, I'm just binding those concrete types to
themselves, like
/bind(FooServiceImpl.class).to(bindFooServiceImpl.class)/

Of course this approach doesn't work because then the
following injection would fail:

|
publicclassFoo{


@Inject
privateFooServicefooService;


}
|

There's no default way in which Guice would figure out that
FooService can actually be served by FooServiceImpl. The
alternative that I have thought about so far is to
introspect those types and generate bindings for each
superclass and implemented interface.

I was wondering is there's a less "brute force" approach.

Thanks
-- 
You received this message because you are subscribed to the

Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at
https://groups.google.com/group/google-guice.
To view this discussion on the web visit

https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the

Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to google-guice+unsubscr...@googlegroups.com
.
To post to this group, send email to
google-guice@googlegroups.com .
Visit this group at