I will, thank you.
On Tuesday, August 20, 2013 10:44:28 PM UTC-4, Nate Bauernfeind wrote:
Did you try using Matchers.subclassesOf(InitableAfterCreation.class)?
On Tue, Aug 20, 2013 at 8:20 PM, elect...@gmail.com javascript: wrote:
Sorry that I'm still not 100% sure, and I do not have a
Let me a couple of days (this weekend) and I will try to simply my original
issue to a test case. I still think that maybe something funny is going on
under some specific conditions.
On Tuesday, August 20, 2013 10:57:47 PM UTC-4, Sam Berlin wrote:
Interesting. I haven't fully digested it,
*simplifly*
--
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
As a side note, if you don't have a required inheritance hierarchy in
your context, you can make an AbstractInitableWidget which has a
default, overridable init() and implements IInitableAfterCreation, just
to cut down on boilerplate. It would be good if Matching on the
subclassesOf bit works
Indeed, thank for the idea.
The problem is that my project is some kind of framework, and I would like
to say to developers that they only have to implements *IInitableAfterCreation
*on their objects for the framework to automatically calls init() on them!
Otherwise I would have to explain
Not uncommon. I don't actually like the solution I proposed, but it can
clean up some boilerplate in some cases - possibly not yours, sadly.
c.
On 21 Aug 2013, at 9:15, electrot...@gmail.com wrote:
Indeed, thank for the idea.
The problem is that my project is some kind of framework, and I
In *com.google.inject.matcher.Matchers$SubclassesOf*
--
public boolean 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
I was just about to suggest annotating the init method on the interface
with the @Inject annotation.
Turns out, that doesn't work either.
On Wed, Aug 21, 2013 at 11:31 AM, electrot...@gmail.com wrote:
In *com.google.inject.matcher.Matchers$SubclassesOf*
--
public boolean
Actually, I'm now pretty sure this was the cause of my issue. All my tests
now passed if I use *IInitableAfterCreation *on the interfaces instead of
on the concrete classes.
So, except if I find a case where the bindListener involving assisted
factories doesn't seems to be the core of the
I'm on vacation atm without access to a pc, but afaict you're matching on
Binding.getKey which is the from part of the binding. Without
assistedinject there will be a just-in-time untargetted binding that
matches; ie the implementation type, equivalent to bind(MyImpl.class);
With assistedinject
I think what Stuart is saying is that the Binding itself doesn't expose the
info because, well, it doesn't have the info. You need to use
theAssistedInject SPI
extensionhttps://code.google.com/p/google-guice/wiki/AssistedInject#Inspecting_AssistedInject_Bindings_(new_in_Guice_3.0)to
get the info
Thanks Sam. By reading about those SPI extensions, I found the way to get
the implementation type in the matches() method :
https://gist.github.com/electrotype/6299241
So it's now working! All my tests passed even with the *IInitableAfterCreation
*interface set on the implementation classes.
Hrm. It seems like your particular problem is because ProvisionListener is
designed to notify you when a particular binding is provisioned, and the
binding it supplies is the one for the exact thing being provisioned. So
take this example:
interface Foo {}
class FooImpl implements Foo {}
If it's necessary to check for those types, then you could just have the
matcher return 'true' always for provider bindings, and your onProvision
method will be the same (because it already does the instanceof check).
Now I feel very stupid for not having thought of that! :-)
Do you
There's some performance overhead for having ProvisionListeners installed,
but not much. I think most big servers here at have them installed, and
we're getting along well with pretty high QPS on many of them. So it
shouldn't be a big problem (unless, of course, you measure it to be a
problem...
I'm currently trying Guice 4.0-beta.
I still have a problem with this issue (
http://code.google.com/p/google-guice/issues/detail?id=743 ).
The problem is that, even with the new patch, listeners are still called
with the reference being cached.
In
Thanks for following up on this. A simplified test case would he much
appreciated.
sam
On Aug 20, 2013 7:26 PM, electrot...@gmail.com wrote:
I'm currently trying Guice 4.0-beta.
I still have a problem with this issue (
http://code.google.com/p/google-guice/issues/detail?id=743 ).
The
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
Interesting. I haven't fully digested it, but if its causing surprising
behavior that you're having trouble explaining, then I think a test case
would be useful. If only so we can examine it more closely and figure out
if there is indeed a bug.
On Aug 20, 2013 9:20 PM, electrot...@gmail.com
You are right, my test is not the best to represent the issue. Of course my
real code is more complex than that, but I've updated the test to show that
the issue occures even if there is no overflow possible :
https://gist.github.com/electrotype/5105100
Thanks for the help!
On Wednesday,
Excellent, thanks! I think this is exactly what I need.
On Wednesday, March 6, 2013 9:59:28 PM UTC-5, Stuart McCulloch wrote:
You might want to look at the ProvisionListener hook that's been added in
trunk:
https://groups.google.com/d/msg/google-guice/wRPmutuepmM/5TbMHMm3wJUJ
Hummm It doesn't seem to work! Maybe I'm missing something?
https://gist.github.com/electrotype/5108107
I use :
dependency
groupIdorg.sonatype.sisu/groupId
artifactIdsisu-guice/artifactId
version3.1.3/version
/dependency
On 7 Mar 2013, at 13:39, electrot...@gmail.com wrote:
Hummm It doesn't seem to work! Maybe I'm missing something?
Unfortunately not - by tracing through your test I can see it still hits the
issue with the constructionContext reference since that's only removed after
all the provisioning
While writing, I considered notifying a ProvisionListener to still be part
of the construction. I remember wondering about this specific part
(whether the finally should be inside or outside), and ended up settling on
outside. But, I can't really give you any concrete reason of why I
settled on
Since I don't want to mess with Guice code directly, I'll wait for the next
release before trying to use those listeners.
My temporary workaround will be to lazily call the init() methods the
first time my objects are *used*, which is not a big deal in my case since
they only have one main
On 7 Mar 2013, at 15:18, Sam Berlin wrote:
While writing, I considered notifying a ProvisionListener to still be part
of the construction. I remember wondering about this specific part (whether
the finally should be inside or outside), and ended up settling on outside.
But, I can't
First, here's a unit test for the issue
:https://gist.github.com/electrotype/5105100
I'm trying to use a listener to call an init() method on my classes when
they are constructed. I also use AssistedInject factories.
I think the problem is that in *
You might want to look at the ProvisionListener hook that's been added in trunk:
https://groups.google.com/d/msg/google-guice/wRPmutuepmM/5TbMHMm3wJUJ
http://code.google.com/p/google-guice/issues/detail?id=78#c16
It lets you intercept after an instance has been completely
28 matches
Mail list logo
