Can you provide a reproduceable use case? Include version of dropwizard.
On Fri, Oct 30, 2015 at 1:47 AM Vivek Kothari
wrote:
> I am facing the same issue.. did you find any solution for the same?
>
>
> On Saturday, 19 October 2013 05:16:44 UTC+5:30, Rohit Nigam
It's certainly not bad practice. Though, the context depends on your
situation entirely.
If you consider the example Guice provides:
https://github.com/google/guice/wiki/FrequentlyAskedQuestions#how-do-i-build-two-similar-but-slightly-different-trees-of-objects
It's certainly conceivable that in
Maybe you want to make CacheMonitor an optional dependency?
See: https://github.com/google/guice/wiki/Injections#optional-injections
On Thu, Sep 10, 2015 at 7:00 AM Michiel ten Hagen
wrote:
> All
>
> I have two classes, Cache and CacheMonitor. If someone binds the
In general this is an anti-pattern in Guice. If you have to pass instances
of every object in your graph to the guice module constructors then you're
not using Guice for any injection at all. What does your java version of
this use-case look like? It seems that you did not translate it to Scala
: Initializable) = {
injector.injectMembers(obj)
obj.init()
}
def inject(obj: AnyRef) = {
injector.injectMembers(obj)
}
}
On Monday, July 6, 2015 at 9:01:30 PM UTC+9:30, Nate Bauernfeind wrote:
In general this is an anti-pattern in Guice. If you have to pass
I've found that despite a few drawbacks, private modules are the way to go.
I seem to end up with complicated object graphs and have had some serious
issues (customer affecting) when something is used that was not
intentionally to be around for public consumption0 (like a single threaded
Luke, If you use annotations for everything that you intend to be private
then how do you re-use a class across more than one module?
For example, suppose I have an interface A. I have two different
implementations B and C. Both B and C are singletons for two different
modules (and each of the
, and we can just pretend T is its erased
type. So long as the user supplies us the T and we don't have to worry
about locating anything that references a T... there won't be any unknowns.
sam
On Wed, May 27, 2015, 1:08 AM Nate Bauernfeind nate.bauernfe...@gmail.com
wrote:
Sam, I don't see
Oh yeah, I forgot to mention, I love making my factories inner static
interfaces! It *really* helps keep relevant things together. Doing that
here is also a natural choice.
On Wed, May 27, 2015 at 12:17 AM Nate Bauernfeind
nate.bauernfe...@gmail.com wrote:
I want to say yes, but I'm afraid
servlet
and .get(request.getAction()).doAction();
Fred
On Tue, May 26, 2015 at 9:23 PM, Nate Bauernfeind
nate.bauernfe...@gmail.com wrote:
Oh yeah, I forgot to mention, I love making my factories inner static
interfaces! It *really* helps keep relevant things together. Doing that
here is also
/google/inject/assistedinject/FactoryProvider2.java
if you want to give it a go.
sam
On Tue, May 26, 2015 at 6:08 PM Nate Bauernfeind
nate.bauernfe...@gmail.com wrote:
Assuming you meant:
interface FooFactory {
T FooT create(T bar);
}
No, this does not work. It would require one-to-many
:
Action action = Action.parse(request.getAction());
action.doAction();
If I migrate them to static inner class, would it be like this?
Action action = ActionFactory.create(request.getAction()));
action.doAction();
klc
On Tuesday, May 26, 2015 at 11:54:56 PM UTC+8, Nate Bauernfeind wrote
What is it that you like about the pattern that you want to keep? Are you
looking for static inner classes? You can couple the pattern with an
assisted inject factory, or providers depending on your use case.
public abstract class Action {
public abstract double doAction();
public static
Assuming you meant:
interface FooFactory {
T FooT create(T bar);
}
No, this does not work. It would require one-to-many bindings, which, if
you read the recent forum's history, is not supported.
This is the closest you can get. I use it pretty frequently:
interface FooFactoryT {
FooT
David,
When I find myself wanting functionality such as one to many binding, I
usually realize what I want to accomplish doesn't really need Guice. Have
you thought about writing your own alert factory?
Something like:
public interface AlertFactory {
T extends Alert T newAlert(ClassT cls);
}
You probably want to call:
binder.requireExplicitBindings() in your Guice Module to catch these kinds
of errors earlier than later.
There are other methods that might solve your needs (like
requireAtInjectOnConstructors), see:
, cause the strict couple
between bean and register.
Am Dienstag, 10. Februar 2015 21:16:18 UTC+1 schrieb Nate Bauernfeind:
Couple of comments.
1. Resolving generic type dependencies can be done without named
annotations. The trick is to use a Guice TypeLiteral. See:
http://google.github.io/guice
Couple of comments.
1. Resolving generic type dependencies can be done without named
annotations. The trick is to use a Guice TypeLiteral. See:
http://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/TypeLiteral.html
Your bind becomes something more like:
bind(new
Sounds like this depends on exactly what behavior you want.
You can overwrite bindings in a module with an Override's module. See:
http://stackoverflow.com/questions/483087/overriding-binding-in-guice
You could use a PrivateModules to divide your object graph to control which
chunks get which
Have you tried using AbcModule as an override module?:
@Override
protected Injector getInjector()
{
return Guice.createInjector(Modules.override(new JerseyServletModule()
{
@Override
protected void configureServlets()
{
It sounds like you might want to use a childInjector pattern here.
Structure it something like this:
Global Injector binds everything that is truly a singleton in your project.
Then in the service(s) where you want to be able to set some state and
create a new object that references the global
).toInstance( )..
... I think that would work but there are edge cases I am probably
missings.
On Sunday, October 19, 2014 5:49:58 AM UTC-7, Nate Bauernfeind wrote:
It sounds like you might want to use a childInjector pattern here.
Structure it something like this:
Global Injector binds
Do you ever run two tasks simultaneously? If not, perhaps you can create a
special provider that you can swap out the Caller where you're currently
considering creating a new injector.
import com.google.inject.Provider;
import java.util.concurrent.atomic.AtomicReference;
public class
In my opinion, you have a few options:
1) You can create a class (and inject it) that optionally injects all of
the things you might shutdown, a la something like this:
class TestShutdownHelper {
@Inject(optional = true) public TimeoutManager timeoutManager = null;
...
public void
I've found that things that tend to run from command-line arguments tend to
not warrant Guice, and things that use Guice tend to warrant a
configuration file. I've come to really appreciate's Dropwizard's approach
which uses YML to configure and jackson to parse that into a POJO. I also
tend to
you do).
Nate
On Thu, Oct 2, 2014 at 8:52 AM, Nate Bauernfeind nate.bauernfe...@gmail.com
wrote:
I did a tiny code test, and it seems like this is already going to fail at
initial start time (note: not compilation time).
object Test {
import net.codingwell.scalaguice.InjectorExtensions
where it's injected.
I hope that all makes sense. I'm still fairly new to Guice...
On Wednesday, 1 October 2014 19:42:58 UTC-5, Nate Bauernfeind wrote:
Can you explain what you mean with a small amount of code? Can you
annotate the assisted inject factories? Maybe you can mix PrivateModule's
I've spoken about my approach to this elsewhere, apologies if you've
already come across this. I use Dropwizard which has a concept of Managed
classes which get started and stopped by dropwizard. Though, you could do
something like this yourself too if you are opposed to dropwizard.
My abstract
I'm going to point you in the direction of a Guice best-practice guideline
which strongly suggests not doing what you've chosen to do.
https://github.com/google/guice/wiki/InjectOnlyDirectDependencies
Specifically, months down the road what if MyObject also needs a
BarService? And then a
I should've read the example more closely, I guess the example is the other
way around (injecting a B into A so that A can get access to C through B).
Either way, I'm sure that assisted inject is a better practice ;).
On Thu, Oct 2, 2014 at 2:35 PM, Nate Bauernfeind nate.bauernfe...@gmail.com
of
time, that you need.
The object that's needed in the hypothetical 'if' block that I was talking
about would be created by the injector ahead of time.
It's a direct dependency...
On Thursday, October 2, 2014 11:35:30 AM UTC-7, Nate Bauernfeind wrote:
I'm going to point you in the direction
Can you explain what you mean with a small amount of code? Can you annotate
the assisted inject factories? Maybe you can mix PrivateModule's along with
AssistedInject factories to get the effect you're looking for (and
potentially exposing the factory with an annotation?).
Nate
On Wed, Oct 1,
I think this is a really good question and I think that your concern
centers around the difference between injection and initialization.
In the case of B depending on A initializing something this is my opinion:
Clearly, you have some dependency in the order in which things are
initialized. When
I think it's perfectly reasonable to use Guice this way. You may want to
make sure that you're being careful about not leaking memory (i.e. it looks
like your event bus is shared across calls, so you'll want to make sure
things like that aren't holding on to the object graph). Also, if you use
Yes please!
On Tue, May 27, 2014 at 3:31 PM, Sam Berlin sber...@gmail.com wrote:
What do folks think of the idea? It'd make accepting patches easier (with
pull requests, etc), and I'm sure there's other benefits for folks using
the code too.
We could also migrate issues if anyone knows a
Here's a short answer solution that should solve your problem, but it
results in two separate object-graphs as defined by A:
Y and Z should probably be private modules and they should only expose the
things that are being used. Being that they are third party, then I
strongly recommend creating a
I'm very excited about this; are you going to cut another beta release
anytime soon?
Is it possible to extend this to use other wrapper classes? I'd like to add
this to the Scala-Guice project for Scala's option class if possible.
On Apr 1, 2014 7:33 PM, Sam Berlin sber...@gmail.com wrote:
Ever
You can also create an injection listener which allows you to modify any
object that gets created by Guice.
Here is an example in scala that adds every object to a guava event bus:
bindListener(Matchers.any, new TypeListener {
def hear[I](typeLiteral: TypeLiteral[I], typeEncounter:
Can you move the property-file loading into a separate public module (named
something like ConfigurationModule)? It seems like the problem is that your
loading them in a private module and then not exposing any of the
properties. Or I could be missing the bigger picture.
On Tue, Mar 18, 2014 at
consuming the content. Whereas in the case
where the service maintains a listener list/mapping then there really can
only be one generator.
Nate
On Wed, Mar 12, 2014 at 1:29 PM, Dirk Olmes dirk.ol...@googlemail.comwrote:
On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
No actually you don't
Just finished reading through the stack overflow link; thanks for sharing
it. It reminded me of the following:
I've heard/read/adopted the policy that guice modules should sincerely
avoid any conditional logic. If you do find yourself with some conditional
logic try and split your module up by
..anyway that's my
fifty cent.
Den mandag den 10. marts 2014 22.36.27 UTC+1 skrev Mikkel Petersen:
Still, since not all classes are injectable (third party) you might need
to access them and populate them manually..
Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind
:31 PM, Dirk Olmes dirk.ol...@googlemail.com wrote:
On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
No actually you don't get already bound exceptions. Guice actually
treats the injection as a setter based injection (it doesn't care how
you name methods; but I tend to use the word register
be in one module..but perhaps the two do not have much in common logic
wise
than this object.
Den lørdag den 8. marts 2014 01.08.14 UTC+1 skrev Nate Bauernfeind:
I can't say that I've ever dealt with an experience of having 100+
unique modules (now if you want to talk about 100+ child
What about your use case prevents you from using a normal .to binding?
bind(SomeService.class).to(SomeService.class)
Nate
On Fri, Mar 7, 2014 at 4:13 PM, Mikkel Petersen mlp2...@gmail.com wrote:
Hello all
I have a slight problem with guice injection when using a method annotated
with
...@gmail.com wrote:
Because I want to receive other bindings:
public Service someService(@Inject Settings settings) {
SomeService s = new SomeService(settings.getHost())
inj.injectMembers(s)
return s
}
Den fredag den 7. marts 2014 23.32.42 UTC+1 skrev Nate Bauernfeind:
What about
) {
install(new FactoryModuleBuilder().implement(source,
klass).build(factoryKlass));
}
On Fri, Mar 7, 2014 at 4:54 PM, Nate Bauernfeind nate.bauernfe...@gmail.com
wrote:
It's a bit more work, but you could consider using assisted injection for
this kind of use-case. My typical pattern looks like
doesn't have the object graph injected.
Den fredag den 7. marts 2014 23.54.17 UTC+1 skrev Nate Bauernfeind:
It's a bit more work, but you could consider using assisted injection for
this kind of use-case. My typical pattern looks like this:
public class Example {
@Inject
public
at providers,
which allow dependencies to be injected into modules.
My application has at least 100 modules by now, and growing.
So far I have used static public objects, but as everyone knows, that is
bad practice.
Den lørdag den 8. marts 2014 00.07.22 UTC+1 skrev Nate Bauernfeind
I don't really understand what you're asking.
Perhaps, you don't realize that Guice does not require you to bind to an
interface. For example, why can't you bind each class?
bind(TestInstanceHelper.class).asEagerSingleton();
...
Then inject each instance into your DeliverableHelper?
Or if you
FWIW, I use AssistedInject Factories for dynamic content.
So for example, I've written a monitoring system where nodes announce
themselves in real-time (via Zookeeper) and user-input information like
alert configuration gets stored in a simple key-value store (and also shows
up dynamically).
And which module is your C3 class bound in, and what does it's binding look
like?
Are you using a specific dropwizard-Guice library?
On Oct 18, 2013 6:51 PM, Rohit Nigam tanuro...@gmail.com wrote:
Hi
I am using dropwizard and it is not able to handle the injections in the
dependent jars. For
constructor (so long as there's a default no-args constructor).
sam
On Sep 20, 2013 12:02 AM, Nate Bauernfeind nate.bauernfe...@gmail.com
wrote:
Hmph, I was using a Module where I called 'requireExplicitBindings' under
the covers. But it turns out that parameterization does not apply
My suggestion was to do this to your HistoricalExtension constructor:
@Inject
public HistoricalExtension(
Injector injector
)
{
this.val = injector.getInstance(CharSequence.class);
}
Which results in output of this:
===
I think this is the easiest way to do this (written in Scala purely for
terseness):
class A
class B @Inject() (a: A)
class TestModule extends PrivateModule {
def configure() {}
@Provides
def createB(a: Provider[A]): B = {
new B(a.get())
}
}
If you change Provider[A] to A you get
and the extension.
On Thu, Sep 19, 2013 at 9:10 PM, Nate Bauernfeind
nate.bauernfe...@gmail.com wrote:
I think this is the easiest way to do this (written in Scala purely for
terseness):
class A
class B @Inject() (a: A)
class TestModule extends PrivateModule {
def configure
struggling with the
generic bind as the bind is bind(Class).to(Class) but I would effectively
need bind(Class).to(Mocked instance of Class).
-Dave
On Tuesday, September 3, 2013 4:03:37 PM UTC-5, Nate Bauernfeind wrote:
Have you considered crawling all of your classes and writing a generic
In this kind of situation I would try to put my non-reusable code behind
[well-thought] interfaces as much as possible. Think about all the [known]
use-cases and really try and separate the common logic from the custom
logic. If you can hide the state behind a logical interface that has always
Have you considered crawling all of your classes and writing a generic bind
method that you can call for any found class that extends View? (see:
http://www.javaworld.com/javaworld/javatips/jw-javatip113.html?page=2)
On Tue, Sep 3, 2013 at 3:44 PM, David Parish dpar...@gmail.com wrote:
We use
matches(Class subclass) {
return superclass.isAssignableFrom(subclass);
}
--
It sadly does the same thing than what I explicitly do.
On Tuesday, August 20, 2013 10:44:28 PM UTC-4, Nate Bauernfeind wrote:
Did you try using Matchers.subclassesOf(**InitableAfterCreation.class
Did you try using Matchers.subclassesOf(InitableAfterCreation.class)?
On Tue, Aug 20, 2013 at 8:20 PM, electrot...@gmail.com wrote:
Sorry that I'm still not 100% sure, and I do not have a test case to show,
but I'm pretty sure I did find the main cause of this issue in my
application.
I
The pattern that seems to make the most sense to me is to use assisted
injection to create your a's (if they take more than just a b) and then you
can add Named annotations to each b binding. Our create a custom
annotation, which is my preference since ide's track usage.
On Aug 16, 2013 9:40 AM,
62 matches
Mail list logo