javax-inject / javax-inject Goto Github PK

From [email protected] on January 10, 2010 10:12:59

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: http://code.google.com/p/atinject/issues/detail?id=21

From bokowski on September 10, 2009 09:54:42

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: http://code.google.com/p/atinject/issues/detail?id=16

From [email protected] on June 18, 2009 17:03:09

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: http://code.google.com/p/atinject/issues/detail?id=8

From [email protected] on September 09, 2009 05:40:36

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: http://code.google.com/p/atinject/issues/detail?id=15

Please add a MANIFEST.MF with a Automatic-Module-Name to the deployed JAR-File.
For better support and stability in projects using the Java Platform Module System (JPMS).

The current javadocs on @Qualifier provide very little information about what a qualifier is. It effectively says "[@Qualifier] identifies qualifier annotations.... A qualifier annotation ... is annotated with @Qualifier", and the rest of the doc describes implementation details.

It would be helpful if the docs could be clarified to describe when and why an annotation should be marked @Qualifier, and what semantics can be expected of such an annotation.

Guice's Binding Annotations doc goes into some additional detail (e.g. "The [qualified] annotation and type together uniquely identify a binding. This pair is called a key.") though even those docs are somewhat lacking.

From [email protected] on June 17, 2009 12:34:03

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: http://code.google.com/p/atinject/issues/detail?id=7

From ogregoire on September 07, 2009 16:00:42

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 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: http://code.google.com/p/atinject/issues/detail?id=14

From [email protected] on June 29, 2009 09:36:19

Good catch, Doug.

Original issue: http://code.google.com/p/atinject/issues/detail?id=11

From [email protected] on July 01, 2009 09:30:54

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: http://code.google.com/p/atinject/issues/detail?id=12

From [email protected] on December 11, 2014 11:59:52

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: http://code.google.com/p/atinject/issues/detail?id=29

From bokowski on September 10, 2009 20:58:46

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: http://code.google.com/p/atinject/issues/detail?id=18

From [email protected] on July 28, 2009 02:42:32

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: http://code.google.com/p/atinject/issues/detail?id=13

From BigMichi1 on May 29, 2012 02:54:24

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: http://code.google.com/p/atinject/issues/detail?id=27

Micronaut had its first milestone release a short while back and includes an implementation of JSR-330.

The tests are here https://github.com/micronaut-projects/micronaut-core/tree/master/inject-java/src/test/java/org/atinject/tck/auto

Please let me know if there is any other information I can provide

From [email protected] on December 01, 2009 23:34:29

like @Autowired(required=false) in spring

@Inject(required=false)
private UserService userService;

or

@Inject
@optional
private UserService userService;

Original issue: http://code.google.com/p/atinject/issues/detail?id=20

If the community is to succeed in migrating to java 9 modules then the basic dependencies such as javax.inject should at least reserve their automatic module name.

See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013233.html for a discussion on what that name could be. Suggested: 'java.inject'

A new release on maven central of javax.inject should become available.

From bokowski on September 10, 2009 09:59:04

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: http://code.google.com/p/atinject/issues/detail?id=17

From [email protected] on July 18, 2011 22:33:49

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
[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\INTERS1\AppData\Local\Temp\2\null905322556
[junitreport] Loading stylesheet jar:file:/C:/javaeetck/tools/ant/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optio
nal/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 938ms
[junitreport] Deleting: D:\Users\INTERS1\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: http://code.google.com/p/atinject/issues/detail?id=24

From [email protected] on April 08, 2014 08:44: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 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: http://code.google.com/p/atinject/issues/detail?id=28

From [email protected] on June 16, 2009 13:07:16

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: http://code.google.com/p/atinject/issues/detail?id=2

Dagger and more recent Guice versions pass the TCK, and should be listed. How should this be validated? (I've grandfathered in those already listed on the older google-code wiki)

From [email protected] on June 24, 2009 04:39:44

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: http://code.google.com/p/atinject/issues/detail?id=10

From [email protected] on December 13, 2011 06:56:53

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 contributedStuff;

void aMethod() {
// Externally contributed stuffs
for (StuffContributor contributor : contributedStuff) {
// ...
}
}
}

Original issue: http://code.google.com/p/atinject/issues/detail?id=25

The present repository is a rescue of the abandoned one at googlecode.com. I don't have rights to push to sonatype, so any edits made here must be consumed elsewise. However, this project was created with the intention of supporting the working group for JSR-330, so I will seek out the appropriate contributors from the working group, and see who has sonatype push authorization, so we can put packaging fixes in for issues like java9 modules (see #33)

From [email protected] on June 16, 2009 17:46:48

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: http://code.google.com/p/atinject/issues/detail?id=4

From [email protected] on June 07, 2010 08:23:00

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): https://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: http://code.google.com/p/atinject/issues/detail?id=22

From [email protected] on June 17, 2009 07:25:57

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: http://code.google.com/p/atinject/issues/detail?id=6

Specification version
JSR 330 Direct Injection

Coordinates of the challenged test(s)
https://github.com/javax-inject/javax-inject
http://download.eclipse.org/ee4j/cdi/jakarta.inject-tck-1.0-bin.zip

TCK version & exclude list versions
1.0

Implementation under test.
Open Liberty, IBM Corporation
https://openliberty.io/
OpenJDK 1.8.0_222

Full test names:
All Tests

Description
The TCK has a dependency on an SE container and runs within that container. Providing an SE Container is not a requirement for Java EE / Jakarta EE. The TCK should provide an option for running within an EE container.

From [email protected] on February 17, 2012 13:29:18

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: http://code.google.com/p/atinject/issues/detail?id=26

Dagger 1, Dagger 2 and toothpick process @Inject related annotations at compile time. Thus they don't need the retention= runtime for those annotations.

On Android, all classes that have fields / methods with runtime retained annotations will be included in the first dex. Having the jsr 330 annotations with this retention leads to first dex exceeding the limit.

It would be very nice to have you guys deploying 2 artifacts to central, with a modifier so that DI libs can decide which annotation retention they wanna use.

https://code.google.com/archive/p/atinject/ doesn't appear to mention this repo anywhere - assuming it's the canonical updated location it'd be helpful if the Google Code page included a pointer to this one.

From [email protected] on June 23, 2009 18:32:10

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: http://code.google.com/p/atinject/issues/detail?id=9

From [email protected] on June 16, 2009 16:21:01

currently Provider.get() does not throw any (checked) Exception, should it?

Original issue: http://code.google.com/p/atinject/issues/detail?id=3

From [email protected] on June 16, 2009 13:03:32

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: http://code.google.com/p/atinject/issues/detail?id=1

From [email protected] on September 17, 2009 18:01:24

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

Attachment: pom.xml

Original issue: http://code.google.com/p/atinject/issues/detail?id=19

From [email protected] on June 16, 2009 18:58:21

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: http://code.google.com/p/atinject/issues/detail?id=5