felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tuomas Kiviaho (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-3912) Support for static field injections and callback invocations
Date Fri, 01 Mar 2013 06:25:12 GMT

     [ https://issues.apache.org/jira/browse/FELIX-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tuomas Kiviaho updated FELIX-3912:
----------------------------------

    Description: 
I've got a case (JUnit tests) where static field injections and callback invocation would
be more than welcome. I'm succesfully using DependencyManager in the same manner as Sonatype
Sisu for my integration tests, but test execution times become quite high when using @TestRule
instead of @ClassRule.


{code}
TestCase {

  @ClassRule
  public static TestRule testRule = new DependencyManagerTestRule(MyTest .class); // apply
more magic to get test inheritance working

  @ServiceDependency
  private static LogService log;

  @ServiceDependency
  ...

  @Test
  public void test1() {};

  @Test
  public void test2() {};

  @Test
  ...

}
{code}

The codebase seems to be crafted statics in mind since there are only handful of locations
which prevent this. The biggest blocker is Component.setImplementation that would need an
information preventing instantiation. The same information would be used to determine at callbacks
and field injections whether to perform these or not.

I guess that the most pain would come from annotation api where possibility of method overloading
should be taken into account, but that could get static support later on. 

I could provide a patch if this idea gets wind under it. Personally I dislike the idea of
using statics anywhere else that within unit/integration tests.

  was:
I've got a case (JUnit tests) where static field injections and callback invocation would
be more than welcome. I'm succesfully using DependencyManager in the same manner as Sonatype
Sisu for my integration tests, but test execution times become quite high when using @TestRule
instead of @ClassRule.

The codebase seems to be crafted statics in mind since there are only handful of locations
which prevent this. The biggest blocker is Component.setImplementation that would need an
information preventing instantiation. The same information would be used to determine at callbacks
and field injections whether to perform these or not.

I guess that the most pain would come from annotation api where possibility of method overloading
should be taken into account, but that could get static support later on. 

I could provide a patch if this idea gets wind under it. Personally I dislike the idea of
using statics anywhere else that within unit/integration tests.

    
> Support for static field injections and callback invocations
> ------------------------------------------------------------
>
>                 Key: FELIX-3912
>                 URL: https://issues.apache.org/jira/browse/FELIX-3912
>             Project: Felix
>          Issue Type: Improvement
>          Components: Dependency Manager
>            Reporter: Tuomas Kiviaho
>
> I've got a case (JUnit tests) where static field injections and callback invocation would
be more than welcome. I'm succesfully using DependencyManager in the same manner as Sonatype
Sisu for my integration tests, but test execution times become quite high when using @TestRule
instead of @ClassRule.
> {code}
> TestCase {
>   @ClassRule
>   public static TestRule testRule = new DependencyManagerTestRule(MyTest .class); //
apply more magic to get test inheritance working
>   @ServiceDependency
>   private static LogService log;
>   @ServiceDependency
>   ...
>   @Test
>   public void test1() {};
>   @Test
>   public void test2() {};
>   @Test
>   ...
> }
> {code}
> The codebase seems to be crafted statics in mind since there are only handful of locations
which prevent this. The biggest blocker is Component.setImplementation that would need an
information preventing instantiation. The same information would be used to determine at callbacks
and field injections whether to perform these or not.
> I guess that the most pain would come from annotation api where possibility of method
overloading should be taken into account, but that could get static support later on. 
> I could provide a patch if this idea gets wind under it. Personally I dislike the idea
of using statics anywhere else that within unit/integration tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message