No @Inject required
JodaStephen
points, but it currently it has a number of points holding me back.
There appears to be a key philosophical decision to requires @Inject
in the classes being injected in order to show that some magic is
occurring. Firstly, if this is philosophy then that needs to be
documented clearly somewhere on the website.
The problem is that adding @Inject means its no longer a POJO in my
book. I am being asked to import a class that is framework related,
and that's against the original thrust of the POJO approach. Requiring
the attribute also requires editing the source code of the class being
injected, which often isn't viable.
So how can this have reached 1.0 without you guys seeing this as a
problem? To many people reviewing Guice, this appears to be a
showstopper. Perhaps because this is an internal Google framework
where you have free rein to edit all the source code around you?
Perhaps because you don't actually notice another com.google...
import?
Which is why I started with philosophy. What is it that convinces you
that adding the @Inject is sufficiently worthwhile to justify the loss
of POJOness?
There have been a number of hints that some kind of solution might be
being thought about. But I can't seem to find any design concept or
idea written down. To me, judging whether to use Guice right now, that
makes the task really hard.
Looking forward, I would like to see this declarable at the module
definition point (with the ability to declare a default):
bind(Foo.class).to(FooImpl.class).wiring(injectAnnotation()); //
default
bind(Foo.class).to(FooImpl.class).wiring(constructor());
bind(Foo.class).to(FooImpl.class).wiring(setters());
bind(Foo.class).to(FooImpl.class).wiring(fields());
bind(Foo.class).to(FooImpl.class).wiring(myWiringRules());
I thought I could write a ConstructorWiringProvider, but that doesn't
seem to work:
bind(Foo.class).toProvider(new
ConstructorWiringProvider(FooImpl.class));
So, am I emphasising the importance of no @Inject enough? If you could
sketch out your design ideas, perhaps someone might actually implement
it!
Stephen
Ben
class A implements Itf {
A(X x, Y y);
}
class AProvider implements Provider<A> {
@Inject X x;
@Inject Y y;
A get() {
return new A(x,y);
}
}
bind(Itf.class).toProvider(AProvider.class);
Secondly, I do think it is a good direction to allow custom injection point, which has been discussed in several different threads here.
Dhanji R. Prasanna
Your objects depend on frameworks all the time. Services import logging api, persistence interfaces, web services utilities, all kinds of stuff. If you define losing "pojoness" as having to import a non jdk class then there are no pojos in this world outside homework assignments and hello worlds. Even Java EE applications that claim to be standards-based and portable usually bind to some vendor extensions or couple to an OSS library of some kind.
The true advantage to iocs like spring working off pojos is that you can decouple client code from a service provider, so that it is easier to swap out for testing and so on; and you can still do this with guice without much difficulty.
Let's not kid ourselves, if you have a project of any size and you're using spring or hivemind odds are you've got tons of xml which is doing all kinds of wiring work for you. Your code is coupled to spring, it's just in xml. I have heard architects pontificate about how easy it would be to swap out spring for another ioc and how important that is. Yet I have never seen ANY project nor heard of ANYone who switched from spring as a trivial exercise (usually if they left spring, it meant they were throwing out everything else too).
The argument that the codebase does not need to be recompiled to rewire certain parts of it is an enormous straw man. Just ask yourself how many times a day you run ant or maven?
Instead of setting up a block on religious grounds, why not look at really how much code you save writing when using guice (both xml AND java) and compare it to other options? I think you will find guice is more amenable to refactoring and rewiring than you originally thought (and certainly easier than spring), and just as flexible. I also will point out how much easier it is to read guice-annotated code than to read naked "pojos" and then trawl through xml to see how they are deployed.
If you are looking for extensibility (i.e. using guice to inject @Resource for instance) this is more of a service-provider requirement, and I believe there is a solution in the works for that. Sorry to sound annoyed but I REALLY dont see anything special about the "pojo" philosophy for its own sake.
Stephen Colebourne
I have managed to get a ConstructorWiringProvider to work. This is not
production quality, but does work, picking the constructor with most
arguments (!). This kind of code needs to be within the DSL though,
not exposed and manually written.
Stephen
=====================
bind(Foo.class).toProvider(
new ConstructorWiringProvider<Foo>(FooImpl.class));
=====================
public class ConstructorWiringProvider<T> implements Provider<T> {
private Class<? extends T> type;
@Inject
private Injector inj;
public ConstructorWiringProvider(Class<? extends T> type) {
this.type = type;
}
@SuppressWarnings("unchecked")
public T get() {
try {
Constructor<T>[] cons = type.getConstructors();
Constructor<T> selected = null;
for (Constructor<T> con : cons) {
if (selected == null ||
selected.getParameterTypes().length <
con.getParameterTypes().length) {
selected = con;
}
}
Class<?>[] params = selected.getParameterTypes();
Object[] args = new Object[params.length];
for (int i = 0; i < params.length; i++) {
args[i] = inj.getInstance(params[i]);
}
return selected.newInstance(args);
} catch (InstantiationException ex) {
throw new IllegalStateException(ex);
} catch (IllegalAccessException ex) {
throw new IllegalStateException(ex);
} catch (InvocationTargetException ex) {
throw new IllegalStateException(ex);
}
}
}
=======================
Stephen Colebourne
> Your objects depend on frameworks all the time. Services import logging api,
> persistence interfaces, web services utilities, all kinds of stuff. If you
> define losing "pojoness" as having to import a non jdk class then there are
> no pojos in this world outside homework assignments and hello worlds. Even
> Java EE applications that claim to be standards-based and portable usually
> bind to some vendor extensions or couple to an OSS library of some kind.
can use a library because thats easily portable. The questions are
always over the frameworks. Particularly, whether your class is tied
to that framework. Being able to write a class and have it not import
anything from a particular framework is important. It may even be
mandated within an organisation.
> Instead of setting up a block on religious grounds, why not look at really
> how much code you save writing when using guice (both xml AND java) and
> compare it to other options? I think you will find guice is more amenable to
> refactoring and rewiring than you originally thought (and certainly easier
> than spring), and just as flexible. I also will point out how much easier it
> is to read guice-annotated code than to read naked "pojos" and then trawl
> through xml to see how they are deployed.
I wasn't asking for xml! I understand the refactoring issue and I
really like the concept of Java based config which maps interfaces to
implementations.
But I'm questioning the choice Guice has made of invading the POJO to
enable this. I've already demonstrated a hacked together
ConstructorWiringProvider can avoid the need for @Inject.
If anything, I'm bemused that this got to 1.0 without a means of
injecting into third-party libraries. Bear in mind that many large
companies (perhaps not Google?) have different departments producing
code used by others. 'Just adding@Inject' isn't a viable solution in
many cases.
Stephen
Dhanji R. Prasanna
Being able to write a class and have it not import
anything from a particular framework is important. It may even be
mandated within an organisation.
That's a silly mandate if you ask me--"use this framework but make it look like you're not."
Then again I run into these all the time so Im with you on this one. The provider interception api is a robust solution to this and the problem of using arbitrary metadata for wiring (as you can do with picocontainer). So maybe 1.1 is the release you should be vetting against pojoness ;)
If anything, I'm bemused that this got to 1.0 without a means of
injecting into third-party libraries. Bear in mind that many large
companies (perhaps not Google?) have different departments producing
code used by others. 'Just adding@Inject' isn't a viable solution in
many cases.
agreed, but as Ben pointed out you can do this easily with a custom type-safe provider.
Third party libs really arent something guice "cant" inject into. In spring you wire it in xml, in guice you wire it in java code. that's really the analog.
If you have lots of classes that absolutely cant import guice, then use lots of providers (though they're a LOT more verbose than @Inject but perhaps not much more than xml).
I think it's because it *appears* as though providers are an edge case and @Inject is the canonical case that it looks like guice is incapable of not intruding in your objects.
My argument is, if you code to interface and then bind them to impls at runtime, who cares what your classes import?
Stephen
Dhanji
Ben
Kevin Bourrillion
The basic truth is that I am struggling to try to put myself into the frame of mind that sees an annotation as invasive. To me -- annotations are inert. They don't do anything. They're post-it notes. Do they make a class no longer a POJO? I just don't believe that they do. To me a class is a POJO right up until the point that unit testing that class suddenly becomes less than completely straightforward. Then they go from POJO to OMFG.
I've also noticed in many discussions that as soon as the Guice response becomes, "then implement a Provider", most people are scandalized and say, oh my word, a custom Provider, I don't want to have to do that, this means guice is a big icky failure! And this is the other mindset I have trouble understanding. To me, the most powerful way to "configure" something is to write the code that produces what you want. Code is precise. Code is good.
Anyway. Guice isn't going to please all of the people all of the time, and I don't have any fantasies of it doing so. We'll add features that we think are worth the cost *and that we believe make Guice more Guicy*, and we'll stay quite busy doing that, I'm sure. Because of that, plenty of people will conclude that Guice isn't what they want to use, and that's okay by me.
(Drives Bob crazy though.) :-)
Thanks all,
K
P.S. Would it help even a *little* if we include a guice-minimal.jar of some kind that would have only @Inject and the couple of other things necessary?
Stuart McCulloch
>
> P.S. Would it help even a *little* if we include a guice-minimal.jar of some
> kind that would have only @Inject and the couple of other things necessary?
>
Sounds good to me, I don't mind compiling against a small API jar.
If only there were 'standard' IoC annotations, cf. javax.persistence.
What I'd like to avoid is adding a dependency to Guice just to get the
annotation, only to find Maven starts dragging in shedloads of jarfiles.
--
Cheers, Stuart
Stephen Colebourne
> The
> provider interception api is a robust solution to this and the problem of
> using arbitrary metadata for wiring (as you can do with picocontainer).
design specs? Emails? Any code yet (I can't see any in Fisheye)?
Tentative thoughts for how long to 1.1?
Stephen
Dhanji R. Prasanna
There have been some discussions on the group list (search for "post-processing")
Here was one I found:
http://groups.google.com/group/google-guice/browse_thread/thread/6f19ba13977b4643/60e818b7d3c8fc1b?lnk=gst&q=post+process&rnum=1#60e818b7d3c8fc1b
this is the issue for it -- nothing there yet :(
http://code.google.com/p/google-guice/issues/detail?id=78&can=2&q=
Stephen Colebourne
> The basic truth is that I am struggling to try to put myself into the frame
> of mind that sees an annotation as invasive. To me -- annotations are
> inert. They don't do anything. They're post-it notes. Do they make a
> class no longer a POJO? I just don't believe that they do. To me a class
> is a POJO right up until the point that unit testing that class suddenly
> becomes less than completely straightforward.
Well, a POJO with an @Inject requires a large jar to be imported in
order to run the test. And nothing from that jar is actually being
used. That is less than completely straightforward. The question is
whether the downside is justified by an upside elsewhere.
Separately, I also think that the JavaEE @Resource should be able to
be handled. Hence it might as well be any annotation. Its just a
compromise Guice needs to adopt IHMO as it grows out into the wider
world (outside relatively closed environments).
> Code is precise. Code is good.
Well I agree on the Code is precise Code is Good point. The one key
benefit Java has over Ruby/Groovy is static typing, yet we (the Java
community) have spent years missing the static typing benefit with
tons of xml et al.
> I've also noticed in many discussions that as soon as the Guice response
> becomes, "then implement a Provider", most people are scandalized and say,
> oh my word, a custom Provider, I don't want to have to do that, this means
> guice is a big icky failure! And this is the other mindset I have trouble
> understanding. To me, the most powerful way to "configure" something is to
> write the code that produces what you want.
I think there is an expectation of a framework provider that it
removes the grunt work of writing an application. And I see a
mechanism for injecting a class where you can't add @Inject to be
grunt work, and a framework essential. Basically, writing a new
separate Provider seems like an overhead, when there are probably only
4 or 5 patterns for these kinds of providers.
The thing that really comes to mind though is FCM closures -
http://docs.google.com/Doc?id=ddhp95vd_0f7mcns. This would provide
type-safe alternatives to @Inject that are non-invasive:
bind(GetPerson.class).toConstructor(GetPersonFromDatabase#(Foo,Bar));
bind(GetPerson.class)
.to(GetPersonFromDatabase.class)
.injecting(GetPersonFromDatabase#setFoo(Foo))
.injecting(GetPersonFromDatabase#setBar(Bar));
> Would it help even a *little* if we include a guice-minimal.jar of some
> kind that would have only @Inject and the couple of other things necessary?
Yes, it helps. Even better if it was an injectalliance.jar, like
aopalliance (this would help with political rather than technical
blocks). Although I'm not sure who there is to ally with!
Stephen
Tim Peierls
wrote:
> The thing that really comes to mind though is FCM closures -http://docs.google.com/Doc?id=ddhp95vd_0f7mcns. This would provide
> type-safe alternatives to @Inject that are non-invasive:
>
> bind(GetPerson.class).toConstructor(GetPersonFromDatabase#(Foo,Bar));
Until that day arrives, I could live very well with these kinds of
things:
bind(GetPerson.class).toConstructor(GetPersonFromDatabase.class).withParameterTypes(Foo.class,
Bar.class)
.injectingMethod("configure").withParameterTypes(Configuration.class);
bind(GetPerson.class).toConstructor(GetPersonFromDatabase.class).annotatedWith(MyInject.class);
.injectingMethodsAnnotatedWith(MyInject.class);
And that's if I was really bothered by having to import
com.google.inject from a non-minimal jar. I'm not.
--tim
Dhanji R. Prasanna
bind(GetPerson.class).toConstructor(GetPersonFromDatabase.class).annotatedWith(MyInject.class);
.injectingMethodsAnnotatedWith(MyInject.class);
And that's if I was really bothered by having to import
com.google.inject from a non-minimal jar. I'm not.
Agreed. I am also perplexed by why the size of the jar is at issue, barring ME envrionments (most of the use cases we have heard appear to refer to EE environments--mention of @Resource etc.), 500k is a trivial size. If there are parts of the jar that are not in use, there are plenty of nice zapper tools to reduce them further to suit whatever deployment configuration. While I can understand the necessity to package units that have external dependencies separately (spring integration, servlet etc.), it seems silly for guice to have to provide all these base combinations out of the box.
Bob Lee
The issue here is one of standards. Guice is not a standard so there
is a reluctance to use it in code, and rightly so IMO. A framework is
fine if it is standardised, like J2EE annotations for instance,
otherwise it is regarded as proprietary, and I don't want to see
proprietary frameworks in code, particularly business logic, if at all
possible and I'm sure this is true of a lot of people.
I'm sorry, but I don't buy it. We used log4j for years before there was a standard (some still do). We use Joda Time, and its standard is probably further off than Guice's. Don't forget Hibernate. Spring users write reams of Spring-specific XML and paper over standard APIs with proprietary wrappers.
Depending on a proprietary API is part of the price you pay as an early adopter. If you can't afford it, you just have to wait for a standard.
If you decide you want to strip Guice out at some point in the future, you can write a trivial script to do so. Or, if you have someone who wants to reuse your code without depending on Guice at runtime, create a version of @Inject with compile time retention.
Bob
Dhanji R. Prasanna
I'm sorry, but I don't buy it. We used log4j for years before there was a standard (some still do). We use Joda Time, and its standard is probably further off than Guice's. Don't forget Hibernate. Spring users write reams of Spring-specific XML and paper over standard APIs with proprietary wrappers.
Depending on a proprietary API is part of the price you pay as an early adopter. If you can't afford it, you just have to wait for a standard.
Amen. Let's not forget many JSR standards come about thru the widespread use of defacto standards like hibernate/toplink (JSR-220 JPA) and disparate-but-similar frameworks like Hibernate validator, commons, springmodules, etc. (JSR-303). Some standards are totally dead too--i.e. Entity beans, and I still dont know anyone who'd rather use java.util.logging over log4j in a real world project.
This seems to come up a lot, but it is simply not a trivial task to switch your dependency injection model, no matter what anyone says about keeping framework-agnostic pojos. You cant do it with spring or pico and you cant do it with guice.
Dhanji
Justin Rudd
Guice would :) Hudson (https://hudson.dev.java.net/) does. It is
very annoying to have to replace the default logging.properties file.
And since I'd have to write a formatter to match my log4j appender
(which is very very specific), I generally just have 2 log files - 1
for JDK logger and 1 for log4j.
But logging is a religious battle just like "Vim vs. Emacs", "Java vs.
.NET", etc. Personally I prefer Simple Log
(https://simple-log.dev.java.net/). I think Log4j is a kitchen sink
now. And given that it is being "replaced" with logback. What the
hell is a developer to do?
I just can't believe that almost more than a decade later we still
discuss logging. And we are still writing logging libraries :)
OK...back to your regular Guice programming...
Justin Rudd
Dhanji R. Prasanna
> I still dont know anyone who'd rather use java.util.logging over log4j in a real world project.
Guice would :) Hudson (https://hudson.dev.java.net/) does. It is
very annoying to have to replace the default logging.properties file.
Well lots of frameworks try to in order to reduce a dep on an external jar. Projects (consumers of frameworks) dont really have this requirement. I honestly have never seen a j.u.l deployed project. I know maintainers who would resign if you did that =)
But you're right it is a religious battle, which, I hope spring/guice does not become (atleast on the grounds of @Inject).
Brian Pontarelli
I've deployed many applications (5 or so at this point) into the real
world that only use JUL and had to pull in log4j or commons logging
because of a framework. In most cases I just use JUL unless a client
absolutely demands we don't.
Just as an example, http://www.naymz.com uses only JUL except has to
pull in log4j and commons due to frameworks.
-bp
Dhanji R. Prasanna wrote:
>
>
> On 4/9/07, *Justin Rudd* <justi...@gmail.com
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To post to this group, send email to google...@googlegroups.com
> To unsubscribe from this group, send email to
> google-guice...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
jet...@gmail.com
> P.S. Would it help even a *little* if we include a guice-minimal.jar of some
> kind that would have only @Inject and the couple of other things necessary?
>
>
Can Guice add support to specify custom annotation(s) to behave the
same as @Inject, either at the global level or per module? Supporting
this feature can help remove all dependencies on Guice except at the
bootstrapping package. There won't even be a need for a standard
@Inject annotation if the popular frameworks support annotation
aliasing like this.
Jet
Stuart McCulloch
The benefit of standardizing on an @Inject annotation is that I'd be
able to grok your code far more quickly than if you used @Wibble.
Especially if another module used @Wibble for something else...
Just my 2 sen ;)
>
> Jet
>
>
> >
>
--
Cheers, Stuart
Kevin Bourrillion
It's filed here: http://code.google.com/p/google-guice/issues/detail?id=70&can=1&q=annotation
I think what will have to happen is that Bob and I will have to arm wrestle over it. I'm in training...
K
Gregory Kick
providing support for other annotations. Stuart mentioned the
possibility of the @Wibble annotation and that it doesn't at all
indicate injection (kinda like @Resource if you ask me...), but I
worry much more about @Wibble, @Wobble and @Wumpus all being
"injection annotations". Suddenly, you have developers, albeit stupid
ones, saying "hey, I have something that I'd like injected and it
already has an annotation on it. why don't i just register that with
guice?" Half of the battle with metadata is to make sure that it
accurately describes something. Now, instead of one, well-known
annotation that actually means something, we have any number of
annotations that can be registered to mean something that may or may
not be accurate. I'm waiting for injection on @SuppressWarnings....
well, if it had runtime retention...
--
Gregory Kick
http://kickstyle.net/
Dhanji R. Prasanna
I have to go against popular opinion and give my vote for _not_
providing support for other annotations.
I too, cast my lot in with this side of the arm-wrestling table (thus raising its popularity by 1).
Dhanji.
Raymond Feng
I think we need to have a good balance here. To provide such a flexibility
doesn't mean to promote the abuses. I won't imagine that end users of Guice
will have to play with customized annotations. But it would be key for other
frameworks/containers to adopt/embed Guice as the IoC engine. SCA
(http://www.osoa.org) is an example as I brought up on this ML before. If
Guice cannot inject on @Reference annotations, then we cannot use it to
implement the SCA spec.
Thanks,
Raymond
Dhanji R. Prasanna
Hi,
I think we need to have a good balance here. To provide such a flexibility
doesn't mean to promote the abuses. I won't imagine that end users of Guice
will have to play with customized annotations. But it would be key for other
frameworks/containers to adopt/embed Guice as the IoC engine. SCA
(http://www.osoa.org) is an example as I brought up on this ML before. If
Guice cannot inject on @Reference annotations, then we cannot use it to
implement the SCA spec.
Yea, agreed; but this is more of a SPI concern. I dont see why guice should support "any" annotations as part of its API.
Dhanji.
Hani Suleiman
greenfields project or a very 'standalone' one, using @Inject
everywhere is not an issue. In other more standards obsessed places,
selling @Resource is much easier.
Nobody is forced to use wibbles, and if someone does use them, then
it's an internal issue that's not exposed to the world. It's somewhat
obnoxious to say that 'nobody shall use wibble because we don't trust
them to know how to do it'.
Gregory Kick
that last one... Let me clarify that my main objection to supporting
_any_ annotation as a drop-in replacement for @Inject is that it runs
the risk of breaking whatever contract the annotation is expected to
indicate.
Let's take @Resource for example. If we were to have something like
addInjectionAnnotation(Resource.class), the assumption would be that
everywhere Guice sees @Resource, it would just treat it like @Inject
right? Unfortunately, @Resource and @Inject aren't synonyms. You
can't put @Resource on a constructor and you can't put @Inject on a
class. Guice has you set your scope in a module whereas @Resource
give you shareable. The differences go on because the intents were
similar, but not quite the same. How should that be handled? Only
support @Resource for the aspects in which it overlaps with @Inject?
Probably not a good idea... When somebody uses shareable=true and
Guice doesn't honor it, we've just started using standards in a
non-standard way.
And the same thing applies to @Wibble... If someone has defined their
own annotation to be exactly like @Inject, then it's not a big deal.
However, if they're using @Wibble instead of @Inject, chances are it's
because they _are_ different. It's probably not too much of an issue
if @Wibble was built to be used with Guice, but I really don't like
the notion of being able to give any old annotation meaning
after-the-fact. How can an annotation properly describe what Guice is
going to do with it and how can Guice guarantee that it will handle
the annotation as intended if they were each designed to know nothing
about the other?
And finally, I do think that you've got a solid point in that selling
@Resource is easy. "Hey look, it's package starts with javax!"
Honestly, having Guice support @Resource might not be a bad idea, but
it would have to support _all_ of @Resource. Given the differences in
semantics, and that @Resource was designed to be used with
@PostConstruct and @PreDestroy, it seems like it would be a pretty
substantial effort to shoehorn all of that in there. Plus, issue 62
seemed to close the debate on the whole lifecycle thing so it looks
pretty bleak for those annotations...
Dhanji R. Prasanna
And finally, I do think that you've got a solid point in that selling
@Resource is easy. "Hey look, it's package starts with javax!"
Honestly, having Guice support @Resource might not be a bad idea, but
it would have to support _all_ of @Resource. Given the differences in
semantics,
There are also other issues. @Resource on a field means lookup the resource indicated by that field's name in textual equivalence.
So guice would have to map them to @Named("fieldName")-style bindings, which is awfully confusing and seems like a hack.
@Resource also exposes resources via jndi, guice would just ignore that. It also has authentication semantics, guice would ignore that
(even though there may be security provided by aop, or acegi integration or whatever).
Imo shareable is an edge-case, the spec even discourages using it--I wouldnt consider that my strongest argument against guice's support
for @Resource. Every resource is shareable by default anyway, except very low-level ones, and in any case it doesnt apply to guice as you
can't annotated classes with @Inject as mentioned before.
Lifecycle isnt that big an issue (nowhere does it say @Resource's *must* have @PostConstruct and @Predestroy), but I agree that a partially
implemented version of this just makes it look like it was shoehorned in (quite awkwardly too). Support for javax.interceptor would be a much
better battle to be fighting =)
But what is really wrong with exposing guice thru a spi? Where you can totally hack up guice's usage semantics to your liking... why isnt
anyone crazy about that!! =(
Dhanji.
Hani Suleiman
>
> Ok, I'll admit that my rant to substance ratio was a little high on
> that last one... Let me clarify that my main objection to supporting
> _any_ annotation as a drop-in replacement for @Inject is that it runs
> the risk of breaking whatever contract the annotation is expected to
> indicate.
>
> Let's take @Resource for example. If we were to have something like
> addInjectionAnnotation(Resource.class), the assumption would be that
> everywhere Guice sees @Resource, it would just treat it like @Inject
> right?
No! I had talked with Bob about this, and the idea is to allow
generic annotation processors. The processor is free to do whatever
it needs to, which includes deviating from @Inject behavior! A simple
alias is useless syntactic sugar, and I agree that it's pointless
adding that.
Some examples:
@EJB annotation: The implementation would create a provider for the
field for example that would look up an EJB to inject
@PersistenceContext(name="whatever"): Injecting a JPA entity manager
Both of those annotations are standards, with no dependencies on
guice. What they do though looks (to my untrained eye) to be fairly
simple stuff that is well within guice's capabilities.
Stuart McCulloch
>
> On Apr 30, 2007, at 2:14 AM, Gregory Kick wrote:
>
> >
> > Ok, I'll admit that my rant to substance ratio was a little high on
> > that last one... Let me clarify that my main objection to supporting
> > _any_ annotation as a drop-in replacement for @Inject is that it runs
> > the risk of breaking whatever contract the annotation is expected to
> > indicate.
> >
> > Let's take @Resource for example. If we were to have something like
> > addInjectionAnnotation(Resource.class), the assumption would be that
> > everywhere Guice sees @Resource, it would just treat it like @Inject
> > right?
>
> No! I had talked with Bob about this, and the idea is to allow
> generic annotation processors. The processor is free to do whatever
> it needs to, which includes deviating from @Inject behavior! A simple
> alias is useless syntactic sugar, and I agree that it's pointless
> adding that.
>
This sounds ok - keep guice-core with @Inject, then have add-on
processors like guice-ejb to implement other container standards.
Requiring people to write a processor should also provide enough
of a barrier to stop people doing silly things just for convenience,
like aliasing annotations.
> Some examples:
>
> @EJB annotation: The implementation would create a provider for the
> field for example that would look up an EJB to inject
> @PersistenceContext(name="whatever"): Injecting a JPA entity manager
>
> Both of those annotations are standards, with no dependencies on
> guice. What they do though looks (to my untrained eye) to be fairly
> simple stuff that is well within guice's capabilities.
>
> >
>
--
Cheers, Stuart
Brian Pontarelli
I keep seeing a lot of new guicers state that they love everything and
just can't stand @Inject because it is a dependency. I'd like to
separate this out for some discussion because I think this is an
interesting topic.
My stance on this is that dependencies are like death and taxes. You can
probably get away with just the JDK (of course your life might be
completely miserable depending), but for the most part we introduce
dependencies. I guess my question is, are you really trying to remove a
dependency or is this really just about you feel unclean about importing
classes from com.google in your code? What if these just happened to be
placed in java.inject instead? They are really just imports right?
Along those same lines, what if the annotations were in a separate JAR
file? Annotations are really just meta-data and absolutely no impact on
the runtime whatsoever. Is it that you don't want to carry the entire
Guice JAR around and would rather have the annotations separate?
Or is there some other aspect I'm missing of this discussion because I
can't really wrap my head around exactly why folks want their own
annotations for injection?
-bp
Kevin Bourrillion
My interest in *possibly* supporting user-specified annotations is only to combat an issue of *perception*. And as such it doesn't make for such a strong argument, does it? :-)
K
Hani Suleiman
>
> Or is there some other aspect I'm missing of this discussion because I
> can't really wrap my head around exactly why folks want their own
> annotations for injection?
The things I'd like to do are entirely practical, and the 'guice way'
would have me defining new annotations when there's a perfectly
sensible and functional way of doing what I want.
Take @PersistenceContext for example. This is used to inject an
EntityManagerFactory or EntityManager into a field. There's a bit of
magic in obtaining one. This isn't very complex, but I *dont* want to
use @Inject for it because I the 'custom' annotation is clearer,
specialised for the task at hand, and does not require that
developers learn yet another annotation. Guice's philosophy in fact
recognises that custom annotations that provide specialised @Inject
behaviour are useful, and supports them.
The problem is that its idea of custom annotations are ones that are
coupled to guice, so you can't reuse any annotations from elsewhere.
There's a little bit of hypocrisy involved in saying 'live with the
dependency' if it's guice, but 'rewrite it to use guice' if it's a
dependency on something else. Why is my dependency on guice
legitimate, and but the dependency on @Resource/@PersistenceContext/
@EJB/@PostConstruct is not?
Bob Lee
The problem is that its idea of custom annotations are ones that are
coupled to guice, so you can't reuse any annotations from elsewhere.
There's a little bit of hypocrisy involved in saying 'live with the
dependency' if it's guice, but 'rewrite it to use guice' if it's a
dependency on something else. Why is my dependency on guice
legitimate, and but the dependency on @Resource/@PersistenceContext /
@EJB/@PostConstruct is not?
We don't care who else you depend on. We also don't give you a hook which would enable other frameworks to get their hands in on object creation, but we need to.
Bob
Brian Pontarelli
>> Or is there some other aspect I'm missing of this discussion because I
>> can't really wrap my head around exactly why folks want their own
>> annotations for injection?
>>
>
> The things I'd like to do are entirely practical, and the 'guice way'
> would have me defining new annotations when there's a perfectly
> sensible and functional way of doing what I want.
>
> Take @PersistenceContext for example. This is used to inject an
> EntityManagerFactory or EntityManager into a field. There's a bit of
> magic in obtaining one. This isn't very complex, but I *dont* want to
> use @Inject for it because I the 'custom' annotation is clearer,
> specialised for the task at hand, and does not require that
> developers learn yet another annotation. Guice's philosophy in fact
> recognises that custom annotations that provide specialised @Inject
> behaviour are useful, and supports them.
>
injection annotation in the traditional sense. It is a container
annotation that allows an EJB container to setup so VERY well defined
context and then create an instance of an EntityManager or Factory based
on that very well defined context. This instance is then injected. So,
in fact this is somewhat heavy weight when compared to DI.
Regardless, I do see the point somewhat in that you want your service to
be usable inside and outside of a container, which you might or might
not actually encounter. My point here is that you could easily do this:
public class ServiceImpl implements Service {
private EntityManager entityManager;
@Inject
@PersistenceContext
public void setEntityManager(EntityManager entityManager) {
}
}
This would allow this code to be Guice injected and EJB injected as long
as Guice is setup with a provider or instance for the EntityManager.
Since these are just meta-data, there is really no harm in putting both
in there.
Now, I will concede that this is duplicate, but it is really just an
extra 7 characters that have no impact on the runtime.
So, I guess I still don't really see the need for this stuff.
-bp
Gregory Kick
>
> >
> > Ok, I'll admit that my rant to substance ratio was a little high on
> > that last one... Let me clarify that my main objection to supporting
> > _any_ annotation as a drop-in replacement for @Inject is that it runs
> > the risk of breaking whatever contract the annotation is expected to
> > indicate.
> >
> > Let's take @Resource for example. If we were to have something like
> > addInjectionAnnotation(Resource.class), the assumption would be that
> > everywhere Guice sees @Resource, it would just treat it like @Inject
> > right?
>
> No! I had talked with Bob about this, and the idea is to allow
> generic annotation processors. The processor is free to do whatever
> it needs to, which includes deviating from @Inject behavior! A simple
> alias is useless syntactic sugar, and I agree that it's pointless
> adding that.
Ok, so we're not talking about the suggestions that started issue 70...
>
> Some examples:
>
> @EJB annotation: The implementation would create a provider for the
> field for example that would look up an EJB to inject
> @PersistenceContext(name="whatever"): Injecting a JPA entity manager
>
> Both of those annotations are standards, with no dependencies on
> guice. What they do though looks (to my untrained eye) to be fairly
> simple stuff that is well within guice's capabilities.
I think you're right about those examples. I could maybe see this
working out, but I still have my doubts about @Resource. In order to
get true support for that annotation Guice would have to have both
class-injection and support at least @PostConstruct. Dhanji was right
that it's not _required_ but it'd be pretty rough to go from
constructor-injection to nothing at all... And the idea of mixing and
matching javax.annotation stuff with provider interceptors isn't
thrilling.
Are the proposed annotation processors going to be flexible enough to
work at the class level?
What happens with the lifecycle?
I think that the simple cases are pretty trivial to implement, but the
edge cases are what's going to hurt...
Hani Suleiman
>
> This is an interesting assertion. This annotation really isn't an
> injection annotation in the traditional sense.
Sure it is, it's just like any Provider backed annotation, it's not a
simple 'call injectee setter with new Foo()', but instead the value
to be injected is calculated at runtime. The container can be a full
blown appserver, guice running inside of an appserver, or a
standalone unit test. From the POV of the injectee it shouldn't
matter. It's only heavyweight because persistence providers take a
year or two to start up, and it about as heavy as any dependency that
need to talk to a database.
> public class ServiceImpl implements Service {
> private EntityManager entityManager;
>
> @Inject
> @PersistenceContext
> public void setEntityManager(EntityManager entityManager) {
> }
> }
>
This won't work unless I modify PersistenceContext to have
@BindingAnnotation specified, will it? That's what I meant by guice's
annotation support not allowing third party annotations. I don't mind
if all I have to do is add the @Inject marker, but from what I can
tell, the other annotation also needs to be guicified.
> Now, I will concede that this is duplicate, but it is really just an
> extra 7 characters that have no impact on the runtime.
Well, 7 chars and a big fat fu to DRY ;)
Gregory Kick
>
> On Apr 30, 2007, at 3:10 PM, Brian Pontarelli wrote:
>
> >
> > This is an interesting assertion. This annotation really isn't an
> > injection annotation in the traditional sense.
>
> Sure it is, it's just like any Provider backed annotation, it's not a
> simple 'call injectee setter with new Foo()', but instead the value
> to be injected is calculated at runtime. The container can be a full
> blown appserver, guice running inside of an appserver, or a
> standalone unit test. From the POV of the injectee it shouldn't
> matter. It's only heavyweight because persistence providers take a
> year or two to start up, and it about as heavy as any dependency that
> need to talk to a database.
>
> > public class ServiceImpl implements Service {
> > private EntityManager entityManager;
> >
> > @Inject
> > @PersistenceContext
> > public void setEntityManager(EntityManager entityManager) {
> > }
> > }
> >
> This won't work unless I modify PersistenceContext to have
> @BindingAnnotation specified, will it? That's what I meant by guice's
> annotation support not allowing third party annotations. I don't mind
> if all I have to do is add the @Inject marker, but from what I can
> tell, the other annotation also needs to be guicified.
Now that's actually, a pretty good idea... Did I miss something in
the code or is something else done with @BindingAnnotation aside from
checking that it's there and that there's only one of them? Instead
of using pluggable replacements for inject, why not just specify which
annotations are being treated as binding annotations in your modules?
@Inject says that it's being handled in that guicy way that we all
know and love while the custom annotation can be handled using
whatever provider you can dream up... It seems that nobody's really
convinced that @Inject is invasive so we might get the best of both
worlds.
>
> > Now, I will concede that this is duplicate, but it is really just an
> > extra 7 characters that have no impact on the runtime.
>
> Well, 7 chars and a big fat fu to DRY ;)
Awesome.
Brian Pontarelli
> On Apr 30, 2007, at 3:10 PM, Brian Pontarelli wrote:
>
>
>> This is an interesting assertion. This annotation really isn't an
>> injection annotation in the traditional sense.
>>
>
> Sure it is, it's just like any Provider backed annotation, it's not a
> simple 'call injectee setter with new Foo()', but instead the value
> to be injected is calculated at runtime. The container can be a full
> blown appserver, guice running inside of an appserver, or a
> standalone unit test. From the POV of the injectee it shouldn't
> matter. It's only heavyweight because persistence providers take a
> year or two to start up, and it about as heavy as any dependency that
> need to talk to a database.
>
configuration and context in order to set this up. The EJB container
decides when to create the EM instance from the EMF and all that jazz.
So you are correct that it is injection, I guess I just feel awkward
when a container is doing lots for me and jumped the gun a bit ;)
>> public class ServiceImpl implements Service {
>> private EntityManager entityManager;
>>
>> @Inject
>> @PersistenceContext
>> public void setEntityManager(EntityManager entityManager) {
>> }
>> }
>>
>>
> This won't work unless I modify PersistenceContext to have
> @BindingAnnotation specified, will it? That's what I meant by guice's
> annotation support not allowing third party annotations. I don't mind
> if all I have to do is add the @Inject marker, but from what I can
> tell, the other annotation also needs to be guicified.
>
I'm pretty certain this will work. You can add any number of annotations
to any method, parameter, etc. Therefore, Guice will be perfectly happy
with your @Inject and EJB3 will be happy with your @PersistenceContext
annotation (someone correct me if I'm wrong here). Why did you think
this wouldn't work?
>> Now, I will concede that this is duplicate, but it is really just an
>> extra 7 characters that have no impact on the runtime.
>>
>
> Well, 7 chars and a big fat fu to DRY ;)
>
Haha. I guess. AbstractModule DRYs things by 6 characters, so by Guice
standards this is repetitive. I personally think this actually is useful
and not repetitive because it is clearly stating that my service is
Guice injectable in any application that uses Guice and EJB injectable
for any application that uses EJBs. I think it is actually a clear
distinction. Otherwise I might have to go figure out one or the other
based on configuration elsewhere. This makes it obvious up front. Plus,
I'll beat the dead horse, these things don't do anything to the class so
you can add annotations forever and not effect the runtime. Having both
doesn't impact anything.
-bp
Brian Pontarelli
>>>
>> This won't work unless I modify PersistenceContext to have
>> @BindingAnnotation specified, will it? That's what I meant by guice's
>> annotation support not allowing third party annotations. I don't mind
>> if all I have to do is add the @Inject marker, but from what I can
>> tell, the other annotation also needs to be guicified.
>>
>
> Now that's actually, a pretty good idea... Did I miss something in
> the code or is something else done with @BindingAnnotation aside from
> checking that it's there and that there's only one of them? Instead
> of using pluggable replacements for inject, why not just specify which
> annotations are being treated as binding annotations in your modules?
> @Inject says that it's being handled in that guicy way that we all
> know and love while the custom annotation can be handled using
> whatever provider you can dream up... It seems that nobody's really
> convinced that @Inject is invasive so we might get the best of both
> worlds.
>
you meant ;) I think your brain was like 5 steps ahead of mine here. I
do that a lot... Anyways, are you thinking that Guice allow you to
specify the a different binding annotation instead of BindingAnnotation
and use that annotation to find custom binding annotations?
If that is what you were getting at, I'm still not convinced that it
really buys anything. The only thing I could think of is that you are
handed a class you can't modify that uses something like @Foo and you
say, "Hey, I think @Foo means inject me. So, if I make Foo the
BindingAnnotation, I'm totally set!" But I'd probably just use a
provider at that point because I wouldn't trust @Foo to stick around
when versioning kicks in nor to not be refactored horribly.
-bp
Gregory Kick
@Inject
@PersistenceContext
public void setEntityManager(EntityManager entityManager) {...}
Hani's comment was that this "wouldn't work" unless
@PersistenceContext was annotated with @BindingAnnotation. I took
that to mean that while we can still bind EntityManagers all we want,
we'd be doing it without recognizing the @PersistenceContext because
guice will ignore everything that's not a binding annotation. So,
@PersistenceContext(name="blah1") vs.
@PersistenceContext(name="blah2") would be irrelevant and render the
whole thing as useless as it ever was. But, if we can say that
@PersistenceContext is a binding annotation with something like
Binder.addBindingAnnotation(PersistenceContext.class), we can do all
of the same sorts of things that we do with @Named for binding and use
providers to create the EntityManager.
Does that make any more sense?
Dhanji R. Prasanna
But, if we can say that
@PersistenceContext is a binding annotation with something like
Binder.addBindingAnnotation(PersistenceContext.class), we can do all
of the same sorts of things that we do with @Named for binding and use
providers to create the EntityManager.
Does that make any more sense?
It again feels like the concept is being shoehorned in. What you are really after is to use @PersistenceUnit or @PersistenceContext in its natural form ( i.e. as specified by JSR-220). The guice post-process interceptors (issue #blah?, target 1.1) give you the opportunity to get in there and mess around with an object after instantiation. You can use whatever logic to grab EMs or EMFs or just about anything you want and slap it on an object. You can even honor type-level annotations like @Interceptors by returning the object wrapped in a proxy.
You dont *need* to add @Inject behind every occurrence of @PersistenceUnit; and you can apply it in its correct (specified) usage. Why try to shave off or pad semantics of the standard just to contort it into guice's contract?
Post processors is how Spring injects @PersistenceUnit in its JPA support module. To me this is a much more elegant solution than trying to retrofit these annotations into guice's injection point markers (no matter whether you do it with @Inject or a binding annotation replacement), which makes the currently simple guice contract abstruse and overweight.
Dhanji.
Brian Pontarelli
> It again feels like the concept is being shoehorned in. What you are
> really after is to use @PersistenceUnit or @PersistenceContext in its
> natural form ( i.e. as specified by JSR-220). The guice post-process
> interceptors (issue #blah?, target 1.1) give you the opportunity to
> get in there and mess around with an object after instantiation. You
> can use whatever logic to grab EMs or EMFs or just about anything you
> want and slap it on an object. You can even honor type-level
> annotations like @Interceptors by returning the object wrapped in a
> proxy.
same injection, but post processing would also work, and would remove
the need for the additional annotation. I would assume that post
processing would account for the same amount of code as a provider and
Guice @Inject of my example, but might have more reflection and type
safety nuances.
But, once again, adding the second annotation (which is how I'm handling
JPA just fine) or some other JPA BindingAnnotation derivative both with
a provider is fine as well. Some overhead, yes, but really not that
large of an issue to me. Plus, unless you are frameworking, the cases of
using Guice and an EJB3 container are minimized. So, if you are battling
with a solution to JPA with Guice only, drop the EJB3 annotations and
just use Inject, you'll feel better.
Okay, back on topic... That was a good discussion for frameworking and
possible reusable code scenarios. Are there any others that would really
require the changing of the semantics of injection and require the use
of no Guice annotations?
-bp
Brian Pontarelli
> It again feels like the concept is being shoehorned in. What you are
> really after is to use @PersistenceUnit or @PersistenceContext in its
> natural form ( i.e. as specified by JSR-220). The guice post-process
> interceptors (issue #blah?, target 1.1) give you the opportunity to
> get in there and mess around with an object after instantiation. You
> can use whatever logic to grab EMs or EMFs or just about anything you
> want and slap it on an object. You can even honor type-level
> annotations like @Interceptors by returning the object wrapped in a
> proxy.
Brian Pontarelli
> It again feels like the concept is being shoehorned in. What you are
> really after is to use @PersistenceUnit or @PersistenceContext in its
> natural form ( i.e. as specified by JSR-220). The guice post-process
> interceptors (issue #blah?, target 1.1) give you the opportunity to
> get in there and mess around with an object after instantiation. You
> can use whatever logic to grab EMs or EMFs or just about anything you
> want and slap it on an object. You can even honor type-level
> annotations like @Interceptors by returning the object wrapped in a
> proxy.
Brian Pontarelli
> It again feels like the concept is being shoehorned in. What you are
> really after is to use @PersistenceUnit or @PersistenceContext in its
> natural form ( i.e. as specified by JSR-220). The guice post-process
> interceptors (issue #blah?, target 1.1) give you the opportunity to
> get in there and mess around with an object after instantiation. You
> can use whatever logic to grab EMs or EMFs or just about anything you
> want and slap it on an object. You can even honor type-level
> annotations like @Interceptors by returning the object wrapped in a
> proxy.
Brian Pontarelli
> It again feels like the concept is being shoehorned in. What you are
> really after is to use @PersistenceUnit or @PersistenceContext in its
> natural form ( i.e. as specified by JSR-220). The guice post-process
> interceptors (issue #blah?, target 1.1) give you the opportunity to
> get in there and mess around with an object after instantiation. You
> can use whatever logic to grab EMs or EMFs or just about anything you
> want and slap it on an object. You can even honor type-level
> annotations like @Interceptors by returning the object wrapped in a
> proxy.
Brian Pontarelli
finish Internet 2.0!?
Dhanji R. Prasanna
But, once again, adding the second annotation (which is how I'm handling
JPA just fine) or some other JPA BindingAnnotation derivative both with
a provider is fine as well. Some overhead, yes, but really not that
large of an issue to me.
Yea, that's fine if people want to use custom binding annotations to mimic the standardized javax... ones.
Plus, unless you are frameworking, the cases of
using Guice and an EJB3 container are minimized.
I disagree entirely. Using JPA outside an EJB3 container is the *mainstream* case imo. Just look at any number of hibernate/spring projects. And JPA is intended for use in pure SE environments too. In that light, standardized access to the JPA persistence context is certainly a valid use case in guice, spring or any DI-based app whether EJB contained or otherwise.
Spring's support of @PersistenceUnit et al, is still the best idea Ive seen; and it fits in nicely with post-processors/provider interceptors.
Okay, back on topic... That was a good discussion for frameworking and
possible reusable code scenarios. Are there any others that would really
require the changing of the semantics of injection and require the use
of no Guice annotations?
nooooooo!
Dhanji =)
Ben
But still, I do feel it is a valid use case to use Guice on a non-guicy pojo. i.e. spring style setter based injection or pico style ctor based injection. If there are some spring managed or pico managed pojos, it'd be nice to not having to change the source code in order to manage them in Guice.
Hani Suleiman
On May 1, 2007, at 9:07 AM, Ben wrote:
> I can't think of any case where I'd want to use a custom use case.
> I was thinking about @Resource, but am somewhat talked out of it
> now. :-)
>
Yeah the fact that everyone is constantly having to be 'talked out of
it' is pretty fishy to me. Clearly it's something that many people
want to do, and all the naysaying at this point is starting to look
like trying to justify one of the 'facts of life' rather than
questioning that fact and whether it should be a 'fact'!
Ben
bind(SomeInterface.class).toProvider(SetterBasedProvider.instance(SomePojo.class));
So, potentially a custom Provider can also be created to handle @Resource? such as
bind(SomeInterface.class).toProvider( CustomAnnotationProvider.instance(Resource.class, SomePojo.class));
Not as easy as I originally expected, but I can live with it.
Clearly if this is to be implemented as a 3rd-party Provider, an aweful amount of code is needed.
Ben.
Bob Lee
So, potentially a custom Provider can also be created to handle @Resource? such as
bind(SomeInterface.class).toProvider( CustomAnnotationProvider.instance(Resource.class, SomePojo.class));
Not as easy as I originally expected, but I can live with it.
Clearly if this is to be implemented as a 3rd-party Provider, an aweful amount of code is needed.
Yeah, you really want these things to be compositional so you can use @Resource and setter injection and Guice's injection all on the same object. Guice also does not currently provide the hooks necessary to check your dependencies at startup, but it will.
Bob
Brian Pontarelli
Bob Lee wrote:
> On 5/1/07, *Ben* <ajoo....@gmail.com <mailto:ajoo....@gmail.com>>
composition or does it come back to changing the
BindingAnnotation/Inject handling of Guice? My guess is that it makes
sense to use a chain of sorts and not change Guice's handling:
bind(SomeInterface.class).toInjectionChain().withProvider(SomeProvider.class).
withAnnotation(MyAnnotation.class);
That's a bit rough, but gets the gist.
-bp
Brian Pontarelli
> Plus, unless you are frameworking, the cases of
> using Guice and an EJB3 container are minimized.
>
>
> I disagree entirely. Using JPA outside an EJB3 container is the
> *mainstream* case imo. Just look at any number of hibernate/spring
> projects. And JPA is intended for use in pure SE environments too. In
> that light, standardized access to the JPA persistence context is
> certainly a valid use case in guice, spring or any DI-based app
> whether EJB contained or otherwise.
will be writing a service for BOTH. Or maybe you didn't miss it....
Anyways, if you are writing a service for a framework, I could see that
you would want to cover you bases and ensure it could be dropped into an
EJB3 container. But if you are writing an application service, it is
probably gonna be deployed in Guice and therefore ditching the EJB
annotations should be fine because you know the environment it will run in.
I could be near-sighting this issue a bit, but I can't really think of
other cases.
>
> Okay, back on topic... That was a good discussion for frameworking and
> possible reusable code scenarios. Are there any others that would
> really
> require the changing of the semantics of injection and require the
> use
> of no Guice annotations?
>
>
> nooooooo!
Haha!
-bp
Bob Lee
True, but do you feel that the provider is sufficient to handle the
composition or does it come back to changing the
BindingAnnotation/Inject handling of Guice? My guess is that it makes
sense to use a chain of sorts and not change Guice's handling:
bind(SomeInterface.class).toInjectionChain().withProvider(SomeProvider.class).
withAnnotation(MyAnnotation.class);
That's a bit rough, but gets the gist.
I think I'll start off with constructor interceptors and go from there (like method interceptors, only for constructors). We should even re-implement field and method interception to use it. Then, you could add another constructor interceptor to the end of the interceptor chain which calls methods annotated with @Resource, and another which calls methods annotated with @PostConstruct, and so on.
Bob