jsr330

JSR-330 support in Picocontainer : @Inject … @Named("xxx)

天涯浪子 提交于 2020-01-15 06:56:48
问题 We have found code like private String string = "Not injected."; @Inject public void setString(@Named("s") String s) { this.string = s; } (utilitzing JSR-330 annotations) to be very useful to pass in a string value for "s". We would like to be as flexible as possible regarding which container to use, hence also Picocontainer. As written, Picocontainer silently ignores the inject. How would I hint to PicoContainer to inject e.g. "String injected!" here? 回答1: Stable pico 2.x does not have full

Practical advice on using Jersey and Guice for RESTful service

牧云@^-^@ 提交于 2019-12-29 10:06:14
问题 From what I can find online, the state of the art for Guice + Jersey integration has stagnated since 2008 when it appears both teams reached an impasse. The crux of the issue is that JAX-RS annotations perform field and method injection and this doesn't play nicely with Guice's own dependency injection. A few examples which I've found don't go far enough to elucidate: Iqbalyusuf's post on Jersey + Guice on Google App Engine Java suffers from a lot of boilerplate (manually getting and calling

Threaded Beans doesn't get Environment @Autowired to them in Spring when using JSR330 Provider

别来无恙 提交于 2019-12-23 03:12:37
问题 Hope the Question is self explanatory ClassA.java @Component @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) public class ClassA implements InterB { private static int counter=0; private int objectid = 0; @Autowired InterA abcd; public ClassA() { super(); this.objectid = ++counter; } @Override public void dododo() { System.out.println("instance number "+objectid++); abcd.doit(); } } ClassB.java @Component @Conditional(OracleDBEngineCondition.class) public class ClassB extends DummyParent

What are the best debugging tricks with Weld/CDI?

时间秒杀一切 提交于 2019-12-20 09:21:43
问题 One of the beauties with Java EE 6 is the new dependency injection framework - CDI with the Weld reference implementation - which has prompted us to start migrating internally to JSR-330 in an implementation agnostic manner, with the explicit target of being able to have a core jar which is frozen, and then being able to add extra jars providing new modules replacing functionality in the core jar. I am now in the process of making the above work with Weld, and to be frank there is simply too

How to make Jersey work with Dagger dependency injection?

流过昼夜 提交于 2019-12-17 20:18:05
问题 Jersey normally uses HK2 dependency injection, but I would like to use Jersey with Dagger 2. Both Dagger and HK2 implement JSR 330, which I have taken as evidence that this should be possible without too much effort. I found ways to make Jersey work with CDI (e.g. Weld), Spring DI and Guice, but I can't find anything on Dagger. To provide some context: I'm running a Grizzly–Jersey server in an SE environment, not in an EE container. My Maven project has com.google.dagger:dagger and org

Does spring-context support JSR-330 Qualifier on bean instances?

假如想象 提交于 2019-12-10 15:54:27
问题 Spring has its own Qualifier annotation, I think it's equivalent to the javax.inject.Named annotation, which in turn is a concrete qualifier in JSR-330. So, I'm wondering which version of Spring, if any, supports Qualifier? Here is my example usage, unfortunately it doesn't work with spring-context 3.0.5: @Retention(RUNTIME) @javax.inject.Qualifier public @interface Version { String value(); } @Configuration public class MyConfig { @Bean("book-12") @Version("a") Book book12a() { ... } @Bean(

Custom Message Key in Hibernate validator not working with message.property

空扰寡人 提交于 2019-12-08 05:06:14
问题 I am working on Spring Boot, I have used Hibernate Validator to validate my beans. I have added a custom key with the @NotEmpty annotation, and add thos key/value pair in message.properties, but it's not getting its value from message.property Here is my bean with validation annotation: public class CategoryBean { @NotEmpty(message = "{category.name.notempty}") private String name; ----getter setter----- } message.properties (path:src/main/resources/message.properties) category.name.notempty

Custom Message Key in Hibernate validator not working with message.property

折月煮酒 提交于 2019-12-06 15:28:00
I am working on Spring Boot, I have used Hibernate Validator to validate my beans. I have added a custom key with the @NotEmpty annotation, and add thos key/value pair in message.properties, but it's not getting its value from message.property Here is my bean with validation annotation: public class CategoryBean { @NotEmpty(message = "{category.name.notempty}") private String name; ----getter setter----- } message.properties (path:src/main/resources/message.properties) category.name.notempty=Sorry! Category can't be empty I have also configured message resource @Bean public MessageSource

What are the best debugging tricks with Weld/CDI?

点点圈 提交于 2019-12-02 18:09:32
One of the beauties with Java EE 6 is the new dependency injection framework - CDI with the Weld reference implementation - which has prompted us to start migrating internally to JSR-330 in an implementation agnostic manner, with the explicit target of being able to have a core jar which is frozen, and then being able to add extra jars providing new modules replacing functionality in the core jar. I am now in the process of making the above work with Weld, and to be frank there is simply too much magic going on behind the covers. Either it works or it doesn't, and it doesn't provide very much

Dependency injection with Spring (JSR 330 annotations) in WebSphere 7 is not working

戏子无情 提交于 2019-12-02 03:36:45
问题 I have an enterprise application built with Java 6, Spring Framework 3.1.2 and Mule-ESB 3.3.0, among other libraries not related to this question. Our beans and services are all declared with @Named and @Inject JSR-330 annotations, respectively for automatic component scanning and for dependency injection (no EJBs, only service beans). When deployed into JBoss 4.2.3 (our test environment) everything works fine. However, when deployed into WebSphere 7, the JSR-330 annotations seem not to be