In your second attempt (without the cdi dependencies; using HK2) your binding is incorrect. It should be bind(Implementation).to(Contract) // - i.e. bind(DemoServiceImpl.class).to(DemoService.class); You have it the other way around. As far as testing, if you have the test in same package (in the test area of the project) you should...
Your problem comes from the fact that DownloadCsr is not a bean. It has a constructor with parameters and you instantiate it in your class TesteBean. To get the CDI feature you have to let the CDI container instantiate the beans for you and provide all needed information as other...
java,eclipse,java-ee,cdi,linuxmint
Did you installed JBoss Tools? Go to Help -> Eclipse Marketplace find JBoss Tools for your version of Eclipse (To check version of eclipse go to Help -> About Eclipse) Then select plugin you need UPD And also check Runtime Environments (window -> preferences) Eclipse should be restarted after installation...
In Java EE 7, the default scanning for JARs/WARs is annotated, meaning that if you don't have a beans.xml that specifies the scan mode, it will default to annotated based scanning. Your class, GreeterImpl has no bean defining annotations on it - no scopes particularly. You can override this by...
1. Target Unreachable, identifier 'bean' resolved to null This boils down to that the managed bean instance itself could not be found by exactly that identifier (managed bean name) in EL #{bean}. Who's managing the bean? First step would be checking which bean management framework is responsible for managing the...
You can use Qualifiers, so your code would look like this: @ClazzA class A { } @ClazzB class B extends A{ } @ClassC class C extends A{ } and when you try to inject, you will do something like this: @Inject @ClassA A a; Check the Weld Doc...
java,java-ee,dependency-injection,ejb,cdi
You could use the programmatic lookup mechanism to restrict the actual type of the needed bean: @Inject Instance<UsernamePasswordCredentials> credInst; public UserNamePasswordCredentials getCredentials() { return credInst.select(UsernamePasswordCredentials.class).get(); } Beyond that, I'm not a Picket Link expert, but I think you are doing something wrong with the framework. Picket Link CDI integration was...
java,java-ee,architecture,ejb,cdi
You are not fully clear with your questions. Your question let me assume a lot. So you should break your questions down and provide more details to your issue. First of all you should mention which Java EE version you are using. Anyway here my details with some assumptions to...
In the constructor class variables are not yet injected. The bean will be injected after initialising, so it is null in the constructor. You have 2 possibilities. Inject the bean in the Constructor. Use the bean in an init method annotated with @PostConstruct I'd recommend the second approach. Here you...
First remark, even if it might work (I never tested), I wouldn't recommend defining qualifier as inner static classes. In your case there are even non static class so I don't see how you could use them. To make your life simpler make your both qualifier top level class in...
java-ee,cdi,java-ee-7,named-scope,java-ee-web-profile
Meanwhile, I found out what I did wrong. I wasn't aware that I have to register my CDI Extension by creating the file src/main/resources/META-INF/services/javax.enterprise.inject.spi.Extension with this content: myscope.MyScopeExtension I also found a sample implementation of a CDI custom scope on GitHub: https://github.com/rmpestano/cdi-custom-scope I still didn't quite manage to finish my...
Mark your Helper class as @ApplicationScoped. With this, you will have a single instance per application context. Still, if it's just an utility class, it shouldn't be a managed bean at all. I would instead mark it as final, define a private constructor and mark all the methods as static....
java-ee,cdi,wildfly-8,meta-inf
It depends where you are using annotations. If you have EJB beans in your web module and are using injections in these beans, then you will need to have beans.xml in the META-INF as it would be in case of pure ejb module. If you are using CDI injections in...
fixed it: Must be public class FeedbackController implements Serializable { thanks to BalusC for helping me out!...
The problem is java.io.FileNotFoundException: jndi:/localhost/WEB-INF/beans.xml I just bumped into something similar today. Either the file can't be found, or you are trying to include it from your web.xml with an ENTITY declaration. If you are trying to load beans.xml with an ENTITY declaration, then the problem is caused by a...
Lets call A the class that have a certain lifecycle. Create an EJBTimer singleton instance (annotated with @Singleton and @Startup) holding a Set of your A instance and inject it in all your A instance. Each A instance will be in charge to register itself in the timer Set after...
jsf,cdi,managed-bean,systemeventlistener
It seems that you're not using JSF 2.2 yet. Since that version, a lot of JSF artifacts have been made eligible for CDI injection, including SystemEventListener instances. See also What's new in JSF 2.2? - Issue 763. If you're running JSF 2.0/2.1 on a Servlet 3.0 capable container, then it...
What's the definition of your qualifier annotations @Added and @Removed? You're probably missing the PARAMETER entry in the @Target list: @Target({ TYPE, METHOD, PARAMETER, FIELD }) ...
jsf,cdi,destroy,weld,session-scope
The answer of @olexd basically explains what I was getting wrong in my mind, thank you very much! But invalidating the session after a determined period is not an option, so I had to use the comment of @geert3 as well, thank you for that! I am answering my own...
jsf,cdi,managed-bean,http-request-parameters,managed-property
The JSF-specific @ManagedProperty annotation works only in JSF managed beans, not in CDI managed beans. In other words, it works only in classes annotated with JSF-specific @ManagedBean annotation, not in classes annotated with CDI-specific @Named annotation. CDI does not offer an annotation out the box to inject specifically a HTTP...
I just forgot to add <Context> <Resource name="BeanManager" auth="Container" type="javax.enterprise.inject.spi.BeanManager" factory="org.jboss.weld.resources.ManagerObjectFactory" /> </Context> to the context.xml....
During the construction of the DataController, it's normal the dataProvider is null. Injection happens after that. You should add a @PostConstruct method to check for nullity of the field: @PostConstruct void init() { // dataProvider should not be null here. } Aditionally, error reporting on Weld is pretty well done....
WOW! with the help of a good friend, I got it! To make this work, you need to configure a special Weld cross-context filter. You configure the filter by adding the following lines to the web.xml file. <filter> <filter-name>WeldCrossContextFilter</filter-name> <filter-class>org.jboss.weld.servlet.WeldCrossContextFilter</filter-class> </filter> <filter-mapping> <filter-name>WeldCrossContextFilter</filter-name> <url-pattern>/*</url-pattern>...
dependency-injection,glassfish,cdi,managed-bean,glassfish-4.1
If you do not specify a META-INF/beans.xml file, which seems to be your case, you got an implicit bean archive (see CDI-1.1 §12.1). In an implicit bean archive, only beans with a bean defining annotation will be discovered by the CDI engine. Any scope is a bean defining annotation (see...
Your question doesn't state important information such as versions in use or how you're deploying, so I'm going to take a wild stab. You're not including a beans.xml file in your deployment. I'm not sure though if you're deploying a WAR or a JAR file. Assuming you have a properly...
I'd avoid this circular dependency, there is a few reasons to do that. Comment on this article A messy constructor is a sign. It warns me that my class is becoming a monolith which is a jack of all trades and a master of none. In other words, a messy...
This issue is caused by a bug in the JSF implementation to do with ViewScoped beans, which is described here The described bug is in JSF 2.29 and 2.28. The fix is in 2.30, which is not yet released. I tried going back versions in the 2.2 heirarchy. 2.27 and...
Let's imaging that what you'd like to do is possible. You have an @ApplicationScoped bean defined: @Produces @ApplicationScoped String produceMyString(InjectionPoint ip) {} And you have two injection points for that bean: @Inject String myString1; @Inject String myString2; As the bean is ApplicationScoped, the producer method will get called only once....
As the @CookieParam package name hints, this is specific to JAX-RS, Java EE's other framefork for RESTful web services. This would only work in a JAX-RS managed resource as annotated by @Path. This won't work in a JSF or CDI managed bean as annotated by @ManagedBean or @Named. If you're...
java-ee,websphere,cdi,ejb-3.1,websphere-8
Eventually I found the root cause. The culprit was the application.xml As I'm using Maven for generating the EAR package with the maven-ear-plugin, it turns out that, if we don't clearly specify the Java EE version as 6 , the default application.xml is targeted for old J2EE 1.3 systems. WildFly...
The Interceptor is in the same transaction context. In the EJB world there are 2 kinds of exceptions: System exceptions (usually Runtime exceptions, but not always) Application exceptions (those are usually user defined [checked] exceptions and are present in the method signature - e.g. void a() thows B.) The transaction...
You can't use @ManagedProperty in a CDI managed bean as annotated with @Named. You can only use it in a JSF managed bean as annotated with @ManagedBean. CDI doesn't have any annotations to inject the evaluation result of an EL expression like as @ManagedProperty. The CDI approach is using a...
java,java-ee,cdi,wildfly-8,java-ee-7
One of your error messages is described in the CDI spec: An interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as @Target(TYPE). If an interceptor for lifecycle callbacks declares an interceptor binding type that is defined @Target({TYPE, METHOD}), the container automatically detects the problem and...
jsf,jsf-2,jax-rs,cdi,omnifaces
@ViewScoped is tied to a JSF view, however durig a JAX-RS request, there's no means of a JSF view anywhere. There's no JSF view being restored during a JAX-RS request as the JAX-RS request is not initiated by submit of a JSF <h:form> which holds information about the JSF view...
unless otherwise stated on the exception thrown, if an ejb method invocation throws an exception, it shall be rolled-back. Additionally, provided all calls to the DB were in the same transaction, they shall be deemed committed at the end of the transaction cycle. In retrospect, all interceptors are invoked within...
The "entity" that handles the injection is any injection framework, such as the reference implementation Weld for CDI or any particular EJB framework included in an application server. The calling is done by the client code, which will reference the framework's proxies and enable the framework to perform actions....
properties,dependency-injection,cdi
While there has been active discussion about integrating configuration in CDI, the current status is that there won't be a standard Java configuration JSR anytime soon. In the meantime, configuration integration is provided by third-parties like DeltaSpike, see http://deltaspike.apache.org/documentation/configuration.html so that it is possible to write: @Inject @ConfigProperty(name = "endpoint.poll.interval")...
jsf-2,cdi,postconstruct,phaselistener
According to section 5.4.1 of the JSF 2.2 spec, PhaseListener is not a managed bean but is injectable. According to section 5.4.2, managed beans must support lifecycle annotations @PostConstruct and @PreDestroy. Since a PhaseListener is not a managed bean in the sense of JSF, it does not follow from the...
exception,logging,cdi,aop,java-ee-7
You can't intercept exception since it's created using **new*, and it will not be managed by CDI. And in practice you should not intercept in that way. The solution you are looking for is to intercept calls in you service, catch your exception there and log it.
First of all, neither Spring, nor Guice (and not PicoContainer either, AFAIK) are CDI implementations. JBoss Weld is a CDI implementation. Second. The specification is not just a paper. It's also a set of interfaces and classes that every implementation must correctly implement or extend or which even contain core...
I don't see why not, as @Depend (default scope) is a pseudo scope therefor the bean manager is no longer interested in the bean. Its life cycle from there on depends purely on the outer bean or other classes that hold direct references to it - Its a plain old...
Problem resolved, when start the Jboss AS 6 with paramter run -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
spring,java-ee,jpa,spring-boot,cdi
You should use the dependency for spring-boot-starter-data-jpa <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> And to use a persistence xml you should define a bean as it says in the documentation. Spring doesn’t require the use of XML to configure the JPA provider, and Spring Boot assumes you want to take advantage of...
Your bean is an EJB before being a CDI bean. Therefore it follows the lifecycle of stateless EJB. The first time you request it, the container create it and call the @PostConstruct callback. When it's not needed anymore, it's not destroyed by returned to the EJB stateless pool, ready to...
There is a big difference. A stateless EJB doesn't maintain state between invocations. It typically doesn't have state at all, except for dependencies on other beans. It offers a service to other components. The clients of a stateless bean can invoke it to serve an HTTP request, but they could...
It's because @RolesAllowed and @DenyAll are active on EJB not on CDI Managed Bean. Try to turn your controller to a CDI session bean. @Named @SessionScoped @Stateful public class SomeController { ... } You should be able to add security annotation on it because you'll have a component having EJB...
Get hold of it in a session scoped managed bean with a @[email protected] on the getter. @SessionScoped public class MyObjectProducer implements Serializable { private MyObject myObject; @Produces @Named("attrname") public MyObject getMyObject() { return myObject; } public void setMyObject(MyObject myObject) { this.myObject = myObject; } } When you set it somehow...
With the hint of BalusC I tracked down the error. Somehow a PrimeFaces Datatable way up on the page triggered its selection with null in the same request, overriding the entity. I don't know why it would be doing that without an actual selection, but with adding explicit processing of...
Solved. On beans.xml with bean-discovery-mode="annotated" doesn't work. Then change to bean-discovery-mode="all" and works fine....
This issue is limited to Glassfish. We switched to wildfly and it works fine as coded.
It turns out this was a bug in the application server; it has now been patched.
Looks like this @Property stuff indirectly accesses the JSF FacesContext to determine the current locale. However, there is no current FacesContext when your crawler is invoked by a scheduler. For every JSF request, the CDI request scope is active, but the converse is not true. For scheduler or timeout methods,...
java,model-view-controller,cdi,jsf-2.2
Foo implements Serializable is necessary but not sufficient for Foo to be serializable. All members of Foo also have to be serializable. In your case, ProfileController is serializable, but its UserService member is not....
Java EE provides injection mechanisms that enable our objects to obtain the references to resources and other dependencies without having to instantiate them directly (explicitly with ‘new’ keyword). We simply declare the needed resources & other dependencies in our classes by drawing fields or methods with annotations that denotes the...
Your error is here UserDao userDao = new UserDao(); If you instantiate the class by yourself with a new, it won't be managed by CDI and thus @Inject will be ignored and your field will be empty. So the correct code would be: @Path("/userreg") public class UserRegistration { User user;...
This is not CDI/Qualifier specific, its a Java annotation issue. You can get the annotation's annotations and then read the values. Here is a small example: @MainServer public String annotatedField = "nn"; Field field = getClass().getField("annotatedField"); MainServer server = field.getAnnotation(MainServer.class); ServerConfiguration configuration = server.annotationType().getAnnotation(ServerConfiguration.class); String url = configuration.url(); // localhost:8080...
java,java-ee,dependency-injection,cdi,jboss-weld
The tutorial is a bit ambiguous (pun intended) about which classes should be deployed simulataneously in each step, so I wouldn't worry about that too much. The answer to the other question you linked does match your case. BankOfAmerica is a bean of type Bank (in CDI 1.0 or in...
I assume the question refers to OSGi, as it wouldn't make sense to use Pax CDI otherwise. Pax CDI creates a separate CDI container and thus a separate bean manager per bean bundle. For this reason, it is not quite obvious what the current bean manager should be. As of...
It's not Gson that is the problem. What is providing the SistemaControl in your SistemaMB class? From the stack trace it looks like nothing is. For example you could add a Produces method to this class: public class CriadorModule { @Produces public SistemaControl criarSistemaControl() { return new SistemaControl(); } @Produces...
I got some help from Jesse McConnell at WebTide. I needed to add the following file to my classpath: https://github.com/eclipse/jetty.project/blob/master/jetty-cdi/src/main/config/modules/cdi.mod I also needed to add the jetty-cdi jar to my pom....
java,java-ee,cdi,wildfly,wildfly-8
As we've already established, newing the RequestProcessor won't populate the @Inject-annotated field since new completely cuts out the DI system. So you need a way to bring it in. Your goal looks particularly non-trivial because RequestProcessor wants a DI-provided dependency (phoneService) and one that you provide programmatically (socket). As a...
If you don't change your system design, all you can do is to export thirdpackage from B and to import it into A. To achieve better encapsulation, you could factor out a service interface IClass2 implemented by Class2, make this class an @OsgiServiceProvider and use @Inject @OsgiService private IClass2 class2;...
It is not possible to access the bean metadata from the bean contextual instances. However, this is possible when working at the level of the beans themselves, using the BeanManager instance and without writting a CDI extension, e.g.: @Inject BeanManager manager; Set<Bean<?>> beans = manager.getBeans(Greeting.class, Named.class); for (Bean<?> bean :...
@PersistenceContext does not work out-of-the-box in a servlet container like tomcat. It works in a Java EE container. So your EntityManager field stays to null because @PersistencContext has no effect in Tomcat, even using Weld-servlet. You may add a ServletListener to bootstrap a JPA implementation, probalby hibernate in your case....
jboss7.x,cdi,entitymanager,jboss-weld
Error found: the EJB module was present twice in the generated EAR, once on the root path of the EAR file and a second time in the WEB-INF/lib folder of the WAR file. I changed the dependency declaration in the WAR project's POM file from: <dependency> <groupId>br.com.sigga</groupId> <artifactId>siot-mobility-ejb</artifactId> </dependency> to:...
How about setting the right log level in your logger. If your using pax exam add the required logback or pax - logging bundles to your environment. If used in plain OSGi make sure you have a log framework installed. I would suggest pax - logging it's proven to work....
Dimitri raised a bug on the jetty project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=462179 The bug contains a full description of the cause of the problem. In short, the way Weld makes the BeanManager available to JSF does not work with unassembled webapps (which is the case with mvn jetty:run), only war files (ie mvn...
java,java-ee,glassfish,ejb,cdi
SessionContext is a resource that is linked to EJB and a Decorator is not an EJB but a CDI bean so it's normal that you get a null SessionContext. You could try getting your SessionContext via Jndi like it is describe here: http://javahowto.blogspot.fr/2006/06/4-ways-to-get-ejbcontext-in-ejb-3.html
maven,jsf,glassfish,cdi,java-ee-7
The lackof an h:head makes the ajax tag give warning. It needs script to be added to the head which only workswith h:head, nota plain head. When this starts working, most likely one of the inputs is not send to the server when the button is pressed, resulting in execptions...
But maybe there is another CDI way with producers or something Indeed, you could use a producer. Kickoff example: @SessionScoped public class SessionBean { @Produces @Named("foo") @SessionScoped public SessionBean getAsFoo() { return new SessionBean(); } @Produces @Named("bar") @SessionScoped public SessionBean getAsBar() { return new SessionBean(); } // ... }...
If it's stateless, making it a singleton or creating a new instance every time you want an instance won't make any significant difference. Using any of those 3 approaches makes it even harder to unit test your code. If DI is completely out of the question, you could use the...
@Named annotaion expects some name and in name is not set - it generate default name, but, name generates in accoartinatly to camel case name of bean. You need to try specify name or either use camel case for bean name.
java-ee,dependency-injection,cdi,jboss-weld
Congratulation ! You've just discovered a bug in Weld : https://issues.jboss.org/browse/WELD-1855 While waiting for the fix, you can use this workaround. Change your EJB to : @Stateless @LocalBean public class MyService<T extends MasterDbo<? extends DetailDbo>, D extends DetailDbo>{ //implemetation } It should work....
jsf,dependency-injection,cdi,jsf-2.2,managed-bean
Injected resources are available only after the constructor has run, i.e. during @PostConstruct and beyond. From the spec docs for JSR-250: The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization As you should be able to infer...
According to section Invocation Order of Interceptors Declared on the Target Class of the JSR 318 - Interceptors 1.2 (that applies to CDI 1.1 as well) specification: Interceptor methods declared on the target class or its superclasses are invoked in the following order: If a target class has superclasses, any...
jsf,session,cdi,wildfly,jboss-weld
It seems we did encounter a Wildfly 8.2 bug, located in Weld. See this jira for more information : https://issues.jboss.org/browse/WFLY-4753 The fix has been to patch Wildfly with this patch : http://sourceforge.net/projects/jboss/files/Weld/2.2.12.Final Thank you all...
The route I chose to take is this one: I created a qualifier @Qualifier @Retention(RUNTIME) @Target({ METHOD, FIELD, PARAMETER }) public @interface DataSource { @Nonbinding DataSourceName value() default DataSourceName.D1; } Note the @Nonbinding annotation which tells container I don't have to specify this parameter when annotating producer method (especially this...
java,maven,jpa,integration-testing,cdi
After some research i found that DeltaSpike already has module called 'Test-Control', which enable use CDI in tests. So i decided to extend current EMF producer to read name of persistence unit from property file which contains configuration. Different property files in src/main/resources and src/test/resources lets me use different persistence...
The exception message you quoted is caused by a name conflict, which is not directly related to CDI at all: each EJB can be addressed by a number of different JNDI names, and some of them (e.g. java:module/MyFacade) only include the simple class name, not the package name. So you...
junit,ejb,cdi,wildfly-8,jboss-arquillian
Remove the dependencyManagement and dependency definition for org.wildfly:wildfly-arquillian-container-embedded. You have setup profiles using the org.wildfly.arquillian:xxxx adaptors as well. They are technically very similar but are intended for two different versions of the WildFly server. Being based on the same code base they both attempt to register the same observers.
java,web-services,java-ee,jboss,cdi
As Jan mentioned, try adding @LocalBean to the ServiceImpleV2 to add a no-interface view. Then you should be able to injet your webservice with @EJB or @Inject. @Stateless @LocalBean @WebServiceProvider(serviceName = "WebserviceV2", wsdlLocation = "META-INF/wsdl/MyV2.wsdl", targetNamespace = "http://smitch.ch/service/v2", portName = "ServicePortV2") @TransactionAttribute(TransactionAttributeType.REQUIRED) public class ServiceImplV2 implements ServicePortV2 { @Inject private...
java,java-ee,jboss,cdi,wildfly
If you want to explicitly read a file from the configuration directory (e.g. $WILDFLY_HOME/standalone/configuration or domain/configuration) there's a system property with the path in it. Simply do System.getProperty("jboss.server.config.dir"); and append your file name to that to get the file. You wouldn't read it as a resource though, so... String fileName...
Your Customer class has to be discovered by CDI as a bean. For that you have two options: Put a bean defining annotation on it. As @Model is a stereotype it's why it does the trick. A qualifier like @Named is not a bean defining annotation, reason why it doesn't...
it looks like that CDI's @Named won't work with velocity templates, but you can implement an Interceptor to do this job for you. An example would be: @Intercepts public class IncluderInterceptor { @Inject private MyComponent mycmp; @AfterCall public void after() { result.include("mycmp", mycmp); // any other bean you want to...
I think your pb comes from here: And I access the EJB from the webapp, directly (injecting using @EJB) into the JSF beans. When use CDI with EJB (by putting a @Sessionscoped on it for instance) you got an CDI bean that also has an EJB nature but not the...
So, I've done my question. In my case I've found this ansver: CheckActionInterceptor @Interceptor @CheckAction public class CheckActionInterceptor implements Serializable { private static final long serialVersionUID = 1L; @AroundInvoke public Object checkPermissions(InvocationContext context) throws Exception { final CheckAction annotation = context.getMethod().getAnnotation(CheckAction.class); if (!isActionAllowed(annotation.object(), annotation.action())) { facesContext.addMessage("Error", new FacesMessage("Permission error", text));...
First, If you are attempting to use CDI, you need to activate it by putting a WEB-INF/beans.xml file in your application (note that this file can be empty), more informations about that file could be found in the Weld - JSR-299 Reference Implementation. As you are using Tomcat, please be...
As mentioned @Boris Pavlović, you can bootstrap Weld and get beans programmatically. However, it is possible to get injection working too. You need to define startup method in your desktop application which will "replace" your public static void main(String ... args). Consider: public class Main { @Inject private Bean bean;...