dpolishuk / atinject Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/atinject
Automatically exported from code.google.com/p/atinject
There are a number of annotations in a variety of frameworks both JCP standards
(like JSR250, EJB3, JAXRS) as well as common open source libraries
(like Spring and Camel) which define annotations which act as custom injection
points. There's lots of them but for the purpose of this issue lets
just consider @Resource. (Others include @PersistenceContext from JPA, @Context
from JAXRS - there's quite a few of them around).
To perform injection of JSR250/EJB3 style values using JSR330 we'd currently
need to annotate @Resource with @Qualifier. Then we could use it as...
public class Cheese {
@Inject
@Resource
DataSource customerDb;
...
}
Now to JSR250/EJB3 folks this looks a bit noisy. They are more used to this...
public class NicerCheese {
@Resource
DataSource customerDb;
...
}
What if we could annotate @Resource with @Inject (or made @Inject optional when
using an annotation annotated with @Qualifier). Folks could then
ship a JSR330 aware version of JSR250 - or folks could do AOP/bytecode weaving
magic on class load to retrofit it.
So then a standard JSR330 implementation would see @Resource and treat it as an
injection point like the NicerCheese code above; acting as if the
@Inject were present as in the Cheese code. This would mean we'd be supporting
existing JSR250/EJB code with minimal impact on JSR330
providers (they'd just have to look for @Inject/@Qualifier on annotations
rather than just look directly for @Inject).
i.e. by allowing annotations to be annotated with @Inject - or by making
@Inject optional on annotations annotated with @Qualifier - not only does
code get a little less noisy (which a tool or IDE can easily visually identify
injection points if so desired) - but we can then easily support all of the
existing standard annotations used for injection points today.
Now you might think whats the big deal with supporting all that legacy code and
frameworks out there; the big win would be we could immediately
migrate all those mini-IoC frameworks which numerous RIs of JSR
250/EJB/JPA/JAXRS and others have created and replace them all with just
JSR330. While someone doing 100% pure JSR330 won't notice much difference;
someone using a mixture of JSR330 and JSR250/EJB/JPA/JAXRS and
others would have the benefit of a single IoC framework doing all of the IoC
across all of the frameworks and annotation flavours; which to end
users would lead to much better error handling & error messages - since a
single unified IoC engine would be doing all IoC whether using the older
or new & shiny annotations.
I don't want to hamper a new specification with legacy crap here; I'm just
thinking this is an easy win; allow a single, simple level of indirection - let
annotations be annotated with @Inject to define alternative injection points
while also keeping user code concise - yet keeping things easy to
understand from a programmer/tool perspective (as its purely a simple level of
direction thats trivial to navigate). The added benefit is lots of
frameworks and tools out there can then rip out all of their IoC code and just
replace it with a JSR330 provider :)
Thoughts?
Original issue reported on code.google.com by [email protected]
on 9 Sep 2009 at 12:40
Folks, let's just get rid of the qualifier @Named. We've gone to so much
effort to come up with a model that is typesafe and does not depend on
strings, why are we going and opening up that door again. Use of @Named as
a qualifier is lame and a bad practice.
If a user *really* wants to use named qualifiers, they can sooo easily
write their own @Named annotation. But it's not something we should
encourage by putting it in the spec. We should be doing everything we can
to encourage people to use @UserDatabase EntityManager instead of
@Named("userDatabase") EntityManager.
Original issue reported on code.google.com by [email protected]
on 19 Jun 2009 at 12:03
An argument can be made that the method should be able to return anything,
and the result would just be ignored when injected. On the other hand,
throwing away a result is a little bit weird (although I can't think of
any possible use that it could be to the injector).
It might come down to: Is it reasonable to have an injection method double
as a business method, and is this a use case that is really necessary to
cover? The question might be asked another way: If it is rare that the
injection method logic is also useful in business logic that returns a
result, would it be unreasonable to expect a user to have to declare a
separate method for injection in that case?
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 2:25
IMHO, JSR 330 should support annotationless injection. The main reason is
to to use DI in existing classes that we can't or don't want to change the
source and recompile it. By the way, as far as I know, this was one of the
main reasons to develop Spring.
Both Spring and Tapestry-IoC support this now, both using external
configuration (XML or Java code). The T-IoC difference is that it sets
some very well-defined rules for configurationless injection. They can be
found in http://tapestry.apache.org/tapestry5.1/tapestry-ioc/
overview.html, section "Dependency Injection". This could be used as a
starting point for JSR 330's annotationless injection.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 12:46
like @Autowired(required=false) in spring
@Inject(required=false)
private UserService userService;
or
@Inject
@Optional
private UserService userService;
Original issue reported on code.google.com by [email protected]
on 2 Dec 2009 at 7:34
We have about 30 days to do this. We'll provide some injectable classes,
some rules for what should be injected (each injector will be responsible
for converting the rules to injector-specific configuration), and code to
validate the classes after they're injected.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2009 at 4:30
The draft spec says nothing about how @Inject interacts with the Java
Memory Model (JMM), but it should.
For example, I think most people would make the implicit assumption that
there is a happens-before edge (with the very specific meaning of "happens-
before" in the JMM) between (A) the initialization by injection of a field
of an object of type Foo and (B) a subsequent read of that field in the
constructor of an object with an injected Foo parameter. But the spec needs
to spell it out before users can be sure that class Foo is thread-safe.
It's not easy to specify, however, and it gets trickier when you think
about the possibility of pathological user-supplied Providers.
To my knowledge, no existing DI framework specifies this kind of thing.
That doesn't let us off the hook.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 7:34
currently Provider.get() does not throw any (checked) Exception, should it?
Original issue reported on code.google.com by [email protected]
on 16 Jun 2009 at 11:21
The whole git repo seems to have been force-pushed with an empty repository. I
don't know who did this or why, or whether by accident, but it's weird. That
said, I had already cloned the repository over to
https://github.com/javax-inject/javax-inject.
We can either use that to push the commits back to this repository, or, since
everyone seems to be migrating to github, we can migrate the issues, and make
that the home of the jsr-330 spec (which I had proposed in an e-mail, but had
not gotten confirmation about, so I wouldn't want to presume it).
Original issue reported on code.google.com by [email protected]
on 11 Dec 2014 at 7:59
There's a ton of legacy Java code out there where folks have written a single
argument taking constructor.
For refactoring reasons (as folks might add new constructors with arguments
later on), its advisable for new code to use @Inject to pick the one
constructor the IoC framework should use.
Should the @Inject spec make it mandatory for classes with a single argument
taking constructor (and maybe a zero argument constructor) to
not be injected by default?
For purely tactical reasons (to avoid end users having to write more provider
methods than are really required or forcing folks to hack the
source/bytecode to add @Inject in), I'm tempted to allow objects with no
@Inject annotation which have a single argument taking constructor
which will be used by the IoC container. If there are 2 argument taking
constructors then it would fail. If folks add another constructor with
arguments to a class already having a non-zero argument constructor then it
breaks the IoC - unless folks add an explicit @Inject.
I know this has always gone against the grain with Guice folks :) What do
others on the EG think?
Note I'm not in favour of clever rules to 'pick the right one' if there are
multiple argument taking constructors. I'm just in favour of folks being
able to write a Java class with exactly one argument taking constructor and for
that to be enough for the class to be instantiated by JSR330;
while at the same time we know it makes sense to add the @Inject going forwards.
Original issue reported on code.google.com by [email protected]
on 28 Jul 2009 at 9:42
Could the tck be added to the maven central repository?
That would make it easier for implementations that depend on the tck to be
added to the maven central repository.
Original issue reported on code.google.com by [email protected]
on 10 Jan 2010 at 6:12
Hi
I apologize if this is the wrong place to post this issue - if someone could
direct me to where I can raise this issue in that case, I'd appreciate it.
I am trying to run the JSR330 TCK tests on Windows 2003.
According to the Readme accompanying the JSR330 TCK porting, I have installed
the 330 TCK, the 330 tck glassfish porting package (Dec 7, 2009 version), the
299 TCK (version 1.0.4SP1).
I update the build.properties file according to above installations and then I
invoke the ant run command to run the tests.
The following is the output from the run:
C:\jsr330\330-tck-glassfish-porting>ant run
Buildfile: build.xml
run:
[junit] Testsuite: org.jboss.weld.atinject.tck.AtInjectTCK
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] ------------- Standard Error -----------------
[junit] Jul 19, 2011 5:21:44 AM org.jboss.weld.bootstrap.WeldBootstrap <clinit>
[junit] INFO: WELD-000900 1.1.0 (is)
[junit] ------------- ---------------- ---------------
[junit]
[junit] Caused an ERROR
[junit] null
[junit] java.lang.reflect.InvocationTargetException
[junit] Caused by: java.lang.NoSuchMethodError: org.jboss.weld.bootstrap.WeldBootstrap.startContainer(Lorg/jboss/wel
d/bootstrap/api/Environment;Lorg/jboss/weld/bootstrap/spi/Deployment;Lorg/jboss/
weld/context/api/BeanStore;)Lorg/jboss/w
eld/bootstrap/api/Bootstrap;
[junit] at org.jboss.weld.mock.MockServletLifecycle.initialize(MockServletLifecycle.java:92)
[junit] at org.jboss.weld.mock.TestContainer.startContainer(TestContainer.java:84)
[junit] at org.jboss.weld.atinject.tck.AtInjectTCK.suite(AtInjectTCK.java:65)
[junit]
[junit] Test org.jboss.weld.atinject.tck.AtInjectTCK FAILED
report:
[junitreport] the file C:\tmp\output\TESTS-TestSuites.xml is not a valid
testsuite XML document
[junitreport] Processing C:\tmp\output\TESTS-TestSuites.xml to
D:\Users\INTERS~1\AppData\Local\Temp\2\null905322556
[junitreport] Loading stylesheet
jar:file:/C:/javaeetck/tools/ant/lib/ant-junit.jar!/org/apache/tools/ant/taskdef
s/optio
nal/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 938ms
[junitreport] Deleting: D:\Users\INTERS~1\AppData\Local\Temp\2\null905322556
[echo] Report written to /tmp/output
BUILD SUCCESSFUL
Total time: 5 seconds
Can someone help me run this JSR330 TCK successfully? Thanks!
Regards
Noman
Original issue reported on code.google.com by [email protected]
on 19 Jul 2011 at 5:33
I think that even if the specs mention that catching this exception
shouldn't be the responsibility of the callers, it might be the
responsibility of the caller to catch anything that went wrong in their
code, such as an IllegalArgumentException in the constructor thrown by the
provider.
Therefore shouldn't it be interesting to create a subclass of
RuntimeException, like javax.inject.InjectionException?
This would allow the programmer to have a specific behavior in the case of
an injection failure. For instance:
Provider<T> provider = ...;
try {
return provider.get();
} catch (InjectionException e) {
throw new InternalError("Oops, forgot to check this injection case", e);
} catch (RuntimeException e) {
// Sadly swallow the exception
return null;
}
Furthermore, I don't remind having seen a single method in the JavaSE
throwing a RuntimeException: only subclasses of it (but I might be mistaken
or I did not delve enough the javadoc).
Finally, very few are the packages that don't define their own exception,
just to say: "Hello! _We_ have a problem: not the other package you might
think of".
Original issue reported on code.google.com by ogregoire
on 7 Sep 2009 at 11:00
Java 8 adds the ability for annotations to be specified on types whenever they
appear. This means it's now possible to write
@Inject Provider<@Leather Seat> seatProvider;
instead of
@Inject @Leather Provider<Seat> seatProvider;
It would be nice if the spec could be updated to allow the first usage, and
explicitly disallow duplicate qualifiers like
@Inject @Leather Provider<@Fabric Seat> seatProvider;
Original issue reported on code.google.com by [email protected]
on 8 Apr 2014 at 3:44
The spec for @Singleton says: "Identifies a type that the injector only
instantiates once."
What kind of "once" is this? Once per VM? per classloader? per thread? per
thread group? per injector instance? - The last one (per injector instance)
would make the most sense to me.
Original issue reported on code.google.com by bokowski
on 10 Sep 2009 at 4:54
Options:
a) Only allow 0 or 1
b) Allow injectors to support more than one but require that they support 0
or 1
c) Require injectors to support N qualifiers
Original issue reported on code.google.com by [email protected]
on 16 Jun 2009 at 8:07
The built jar for the javax.inject API on maven's central repo is not usable in
an OSGi environment because it does not contain the necessary elements in the
META-INF/MANIFEST.MF file. This file should include the following elements:
Export-Package: javax.inject;version="1.0.0"
Bundle-Version: 1.0.0
Bundle-Name: Dependency Injection for Java
Bundle-ManifestVersion: 2
Bundle-SymbolicName: javax.inject
Original issue reported on code.google.com by [email protected]
on 17 Feb 2012 at 9:29
I post a new issue as it seems I can't reopen an existing issue.
So don't close this as a duplicate, but please answer this issue correctly.
You don't provide any consistent reason, neither #1 nor in #20, to not inject
empty collections when one knows there may not be any injection candidate.
For instance:
interface StuffContributor {
}
class StuffUser {
@Inject
private Collection<StuffContributor> contributedStuff;
void aMethod() {
// Externally contributed stuffs
for (StuffContributor contributor : contributedStuff) {
// ...
}
}
}
Original issue reported on code.google.com by [email protected]
on 13 Dec 2011 at 2:56
If we really are going to keep @Named, at least we should make the value
member optional, since I don't want to see people having to write stuff like:
@Inject @Named("foo") Foo foo;
Or in 299:
@Named("foo")
public class Foo { ... }
Just like with the EE 5 style injection annotations, the name of the
qualifier should be defaultable from the name of the field (or type), so
that we would get:
@Inject @Named Foo foo;
@Named
public class Foo { ... }
Original issue reported on code.google.com by [email protected]
on 24 Jun 2009 at 1:32
The JavaDoc for @Inject says "Identifies injectable constructors, methods,
and fields. May apply to static as well as instance members" but doesn't
give clear guidance on what injection for static members means.
I would expect different language here, for example "Identifies injectable
constructors, instance methods, and instance fields. <remove sentence
starting with "May apply"; insert rest of first paragraph> Injection for
static members annotated with @Inject is undefined".
Original issue reported on code.google.com by bokowski
on 11 Sep 2009 at 3:58
The doc seems to disallow @Target on scope or qualifier annotations.
I don't see why this restriction exists and would like to see it removed.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 1:58
currently online jars have no MANIFEST.MF so that the JarClassloader fail to
read it.
What is the expected output? What do you see instead?
please provide an META-INF/MANIFEST.MF in downloadable jar-files
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by BigMichi1
on 29 May 2012 at 9:54
Hi folks,
I have attached a pom.xml that could be added to this project so we could
quickly create a maven
artifact for repository deployment.
Cheers,
Justin
Original issue reported on code.google.com by [email protected]
on 18 Sep 2009 at 1:01
Attachments:
Good catch, Doug.
Original issue reported on code.google.com by [email protected]
on 29 Jun 2009 at 4:36
The TCK does not test if a generic type of annotation will result in proper
lookup if its used for two different services/beans.
First off is if this is the correct way to do the lookup, I think it is.
Very short the problem is how to resolve this scenario:
@Inject @Spare Tire tire;
@Inject @Spare Wrench wrench;
Example from my own project (my project previously only used the annotation
as registration name and could not get this test to work, but still passed
the TCK):
http://code.google.com/p/java-simple-utils/source/browse/trunk/simple-java-
utils/inject/src/test/java/test/org/hrodberaht/inject/AnnotationContainerUn
itT.java
Original issue reported on code.google.com by [email protected]
on 7 Jun 2010 at 3:23
public interface Startable {
void start();
void stop();
}
public interface Disposable {
void dispose();
}
--
Apache-Avalon had Startable, so does PicoContainer, and the need for components
with IoC life-cycle is clear IMO. Spring and PicoContainer also have support
for JEE5's PostConstruct and
PreDestroy lifecycle annotations. I'm against the view that lifecycle is just
JVM starting up, and
shutdown-hook initiated. For me it much more fine-grained. I'm also of the
opinion that the
ProstConstruct/PreDestroy is not what was wanted to solve this elegantly* and
the clue to that is
the human must/must-not rules baked into the Javadoc (see below).
For those new to it; start/stop is called by the container to signify the
starting or stopping of
daemon-like activities. Start could be called after a stop and so on. Dispose
is called when its
all over, and there is no intention to resurrect. MS's .NET has a IDispose
interface too so its not
without precedent.
It seems to me that Startable/Disposable are the purview of this JSR and I'll
hanker for it for
another 10 years if declined here :-)
The following of Startable/Disposable post-injection are responsibility of the
container. The
server incarnations of JBoss, Spring, Weblogic etc could act on implementors.
A container inside
a WAR file may map start/stop to context or application events. Perhaps for
WAR file contained
components requiring life-cycle in services like appengine, there's neither
socket listening or
thread-launching possibilities, due to restrictions. This does not negate the
need for
Startable/Disposable.
Links - http://www.j2ee.me/javaee/5/docs/api/javax/annotation/PostConstruct.html
http://www.j2ee.me/javaee/5/docs/api/javax/annotation/PreDestroy.html
* http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html
Original issue reported on code.google.com by [email protected]
on 24 Jun 2009 at 11:39
I don't think this feature carries its weight. It's very tricky to specify
and implement. I think it's better to just bind a default value explicitly.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2009 at 8:03
The spec for @Inject says: "Constructors are injected first, followed by
fields, and then methods. Fields and methods in superclasses are injected
before those in subclasses."
Maybe it's just me, but I am unsure about the intended ordering in the
presence of inheritance and both injectable methods and fields. Given a
class A and a class B that extends A, it is not clear if the order of
injection is fields(A),methods(A),fields(B),methods(B) or
fields(A),fields(B),methods(A),methods(B).
Original issue reported on code.google.com by bokowski
on 10 Sep 2009 at 4:59
It was used as the RI; a release is available through the JCP web site, or you
can build the latest (soon to be 3.0) from svn.
Original issue reported on code.google.com by [email protected]
on 8 Jul 2010 at 3:50
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.