dpolishuk/atinject

Automatically exported from code.google.com/p/atinject

atinject's Issues

support custom injection annotations?

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

Ditch @Named

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

Must an injected method return void?

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

Allow annotationless injection

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

make Injection optional

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

Implement TCK for annotation API

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

Need to specify memory effects (if any) of @Inject

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

Should Provider.get() throw?

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

repostitory has been deleted

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

should a single argument taking constructor be allowed as an injection point without requiring @Inject?

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

Add tck to maven central repository

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

Cannot run JSR330 TCK tests

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

Provider.get() should throw a subclass of RuntimeException, not a RuntimeException

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

Specification should be updated for Java 8 type annotations

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

What's the meaning of "once" for @Singleton?

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

Should we support multiple qualifier annotations?

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

Add OSGi manifest elements

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

Support for empty collection injection when there is no injection candidates

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

Make value member of @Named optional

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

@Inject on static fields and methods?

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

Should @Target be allowed on @Qualifier and @Scope?

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

Missing META-INF/MANIFEST.MF in jar

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

Add a simple pom so Maven2 can be used to build an artifact

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:

• pom.xml

"only covers" should be "covers only"

Good catch, Doug.

Original issue reported on code.google.com by [email protected] on 29 Jun 2009 at 4:36

Addition for testcase needed to TCK

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

Startable & Disposable interfaces

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

Should we get rid of the "optional" attribute from @Inject?

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

Ordering of field/method injection in the presence of subclassing?

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

Where is Guice 2.1?

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