Search Results

Search found 107 results on 5 pages for 'cdi'.

Page 1/5 | 1 2 3 4 5  | Next Page >

  • Contexts and Dependency Injection(CDI)??

    - by Masa Sasaki
    WebLogic Server?????????????WebLogic Server????????6?20?????????37?WebLogic Server???@????????Contexts and Dependency Injection(CDI)?(?????????? Fusion Middleware?????? ?? ?)?????????????????Java EE 6????????CDI???????DI(Dependency Injection)?Java EE 5????????????????????CDI??DI????????????????????????????????????????????????????????CDI????????????????????(?????? Fusion Middleware?????? ??? ??) CDI?? ???????CDI???Java EE 6???????JSR299: Contexts Dependency Injection????? ?????Dependency Injection (??????)?Aspect-Oriented Programming (AOP)?Interception ??????????????????????????? CDI?????????????????????????????????????????????? ?????????????????????????????????????????? ?????????????????????????????????????????????? ???????????????????????????CDI?????????????? CDI?????????????2? ??1???CDI??????????Oracle WebLogic Server 12c????Java EE 6????????? ?????????????????2???beans.xml???????Web??????????WEB-INF/beans.xml? EJB??META-INF/beans.xml????????????CDI????????????????beans.xml???? ?????????????????????? Java EE 5?DI(Dependency Injection) Java EE 5??DI????????????????????????????????????? ?????????????????????????????????????????(@EJB? @Resource?@WebServiceRef)??? Java EE 6?CDI Java EE 6?CDI?????????????????@Inject???????????????? ???????????????????????????????????????????????????? @Qualifier????????????????? ?????????????????????????????????????????@Qualifier? ????????????·??????????????????????@JPN??????????? @Produce???????? ???????????????????? ????????·?????????????? CDI?????????????????????????????????·??????? ????????????????????????????????????????????? ???????????????? EL(Expression Language) ???????? EL????????????JSF?ManagedBean?????????????·?????????????? ??? Java EE 6?????????CDI???????????Java EE 5?DI????AOP??? ???????????????????DI, AOP???????????????? ?????????????CDI?????????????????????????????? ?????CDI?????????????????????????????????? ?????? WebLogic Server??? WebLogic Server?????????WebLogic Server?????! WebLogic Server??????(???????????) WebLogic Server???????? WebLogic Server??????

    Read the article

  • CDI 1.1 Public Review and Feedback

    - by reza_rahman
    CDI 1.1 is humming along nicely and recently released it's public review draft. Although it's just a point release, CDI 1.1 actually has a lot in it. Some the changes include: The CDI class, which provides programmatic access to CDI facilities from outside a managed bean Ability to veto beans declaratively using @Vetoed Conversations in Servlet requests Application lifecycle events in Java EE Injection of Bean metadata into bean instances Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType Ability to override attributes of a Bean via BeanAttributes Ability to process modules via ProcessModule Ability to wrap the InjectionPoint Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes in a bean archive Global ordering and enablement of interceptors and decorators Global selection of alternatives @New deprecated Clarify interceptors and decorators must be implemented using proxying Allow multiple annotated types per Java class Allow Extensions to specify the annotations that they are interested in The CDI 1.1 expert group has a number of open issues that they would like immediate feedback on. These include critical issues like bean visibility, startup events and restricting CDI scans. Read the details here and let your voice be heard!

    Read the article

  • Tell the CDI 2 Expert Group What You Think!

    - by reza_rahman
    Since it's introduction in Java EE 6, CDI has become a key API for the platform. CDI 1.1 was a relatively minor release included in Java EE 7 as was CDI 1.2 (to be included in GlassFish 4.0.1). We have much higher expectations from CDI 2 (projected to be included in Java EE 8) under the new leadership of Antoine Sabot-Durand. Much like we conducted the Java EE 8 survey to solidify future direction for the platform, CDI 2 is now undergoing the same effort. Towards this goal the CDI 2 leadership is now soliciting feedback on some very specific items via an open survey. Topics include the likes of Java SE bootstrap, asynchronous processing, modularity, EJB-style @Startup and @Asynchronous in CDI, configuration and CDI Lite. You can of course also provide free-form input on anything that's not on the survey. Take the survey now on the CDI specification site and help shape the future of CDI 2 and Java EE 8!

    Read the article

  • Pete Muir Interview on CDI 1.1

    - by reza_rahman
    The 109th episode of the Java Spotlight podcast features an interview with CDI 1.1 spec lead Pete Muir of JBoss/Red Hat. Pete talks with Roger Brinkley about the backdrop to CDI, his work at JBoss, the features in CDI 1.1 and what to expect in the future. What's going on behind the scenes and the possible contents for CDI 1.1+ are particularly insightful. You can listen to the full interview here.

    Read the article

  • Where should I declare my CDI resources?

    - by Laird Nelson
    JSR-299 (CDI) introduces the (unfortunately named) concept of a resource: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/resources.html#d0e4373 You can think of a resource in this nomenclature as a bridge between the Java EE 6 brand of dependency injection (@EJB, @Resource, @PersistenceContext and the like) and CDI's brand of dependency injection. The general gist seems to be that somewhere (and this will be the root of my question) you declare what amounts to a bridge class: it contains fields annotated both with Java EE's @EJB or @PersistenceContext or @Resource annotations and with CDI's @Produces annotations. The net effect is that Java EE 6 injects a persistence context, say, where it's called for, and CDI recognizes that injected PersistenceContext as a source for future injections down the line (handled by @Inject). My question is: what is the community's consensus--or is there one--on: what this bridge class should be named where this bridge class should live whether it's best to localize all this stuff into one class or make several of them ...? Left to my own devices, I was thinking of declaring a single class called CDIResources and using that as the One True Place to link Java EE's DI with CDI's DI. Many examples do something similar, but I'm not clear on whether they're "just" examples or whether that's a good way to do it. Thanks.

    Read the article

  • Is it possible to destroy a CDI scope?

    - by Matt Ball
    I'm working on a Java EE application, primarily JAX-RS with a JSF admin console, that uses CDI/Weld for dependency injection with @ApplicationScoped objects. Minor debugging issues aside, CDI has worked beautifully for this project. Now I need some very coarse-grained control over CDI-injected object lifecycles. I need the ability to: Remove an injected object from the application context, or Destroy/delete/clear/reset/remove the entire application context, or Define my own @ScopeType and implementing Context in which I could provide methods to perform one of the two above tasks. I'm fully aware that this is across, if not against, the grain of CDI and dependency injection in general. I just want to know Is this remotely possible? If yes, what is the easiest/simplest/quickest/foolproofiest way to get the job done?

    Read the article

  • JSR-299 CDI / Weld vs. Google Guice

    - by deamon
    Weld, the JSR-299 Contexts and Dependency Injection reference implementation, considers itself as a kind of successor of Spring and Guice. CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has its own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more web and enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from the frameworks mentioned and lots of collaboration and hard work by the JSR-299 Expert Group (EG). http://docs.jboss.org/weld/reference/latest/en-US/html/1.html What makes Weld more capable for enterprise application compared to Guice? Are there any advantages or disadvantages compared to Guice? What do you think about Guice AOP compared to Weld interceptors? What about performance?

    Read the article

  • CDI SessionScoped Bean instance remains unchanged when login with different user

    - by Jason Yang
    I've been looking for the workaround of this problem for rather plenty of time and no result, so I ask question here. Simply speaking, I'm using a CDI SessionScoped Bean User in my project to manage user information and display them on jsf pages. Also container-managed j_security_check is used to resolve authentication issue. Everything is fine if first logout with session.invalidate() and then login in the same browser tab with a different user. But when I tried to directly login (through login.jsf) with a new user without logout beforehand, I found the user information remaining unchanged. I debugged and found the User bean, as well as the HttpSession instance, always remaining the same if login with different users in the same browser, as long as session.invalidate() not invoked. But oddly, the session id did modified, and I've both checked in Java code and Firebug. org.apache.catalina.session.StandardSessionFacade@5d7b4092 StandardSession[c69a71d19f369d08b5dddbea2ef0] attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue=org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8 attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {} attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29 attrName = javax.faces.request.charset : attrValue = UTF-8 org.apache.catalina.session.StandardSessionFacade@5d7b4092 StandardSession[c6ab4b0c51ee0a649ef696faef75] attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue = org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8 attrName = com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap : attrValue = {-4968076393130137442={-7694826198761889564=[Ljava.lang.Object;@43ff5d6c}} attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {} attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29 attrName = javax.faces.request.charset : attrValue = UTF-8 Above block contains two successive logins and their Session info. We can see that the instance(1st row) the same while session id(2nd row) different. Seems that session object is reused to contain different session id and CDI framework manages session bean life cycle in accordance with the session object only(?). I'm wondering whether there could be only one server-side session object within the same browser unless invalidated? Since I'm adopting j_security_check I fancy intercepting it and invalidating old session is not so easy. So is it possible to accomplish the goal without altering the CDI+JSF+j_security_check design that one can relogin with different account in the same or different tab within the same browser? Really look forward for your response. More info: Glassfish v3.1 is my appserver.

    Read the article

  • CDI SessionScoped Bean results in two instances in same session

    - by Ryan
    I've got two instances of a SessionScoped CDI bean for the same session. I was under the impression that there would be one instance generated for me by CDI, but it generated two. Am I misunderstanding how CDI works, or did I find a bug? Here is the bean code: package org.mycompany.myproject.session; import java.io.Serializable; import javax.enterprise.context.SessionScoped; import javax.faces.context.FacesContext; import javax.inject.Named; import javax.servlet.http.HttpSession; @Named @SessionScoped public class MyBean implements Serializable { private String myField = null; public MyBean() { System.out.println("MyBean constructor called"); FacesContext fc = FacesContext.getCurrentInstance(); HttpSession session = (HttpSession)fc.getExternalContext().getSession(false); String sessionId = session.getId(); System.out.println("Session ID: " + sessionId); } public String getMyField() { return myField; } public void setMyField(String myField) { this.myField = myField; } } Here is the Facelet code: <?xml version='1.0' encoding='UTF-8' ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <f:view contentType="text/html" encoding="UTF-8"> <h:head> <title>Test</title> </h:head> <h:body> <h:form id="form"> <h:inputText value="#{myBean.myField}"/> <h:commandButton value="Submit"/> </h:form> </h:body> </f:view> </html> Here is the output from deployment and navigating to page: INFO: Loading application org.mycompany_myproject_war_1.0-SNAPSHOT at /myproject INFO: org.mycompany_myproject_war_1.0-SNAPSHOT was successfully deployed in 8,237 milliseconds. INFO: MyBean constructor called INFO: Session ID: 175355b0e10fe1d0778238bf4634 INFO: MyBean constructor called INFO: Session ID: 175355b0e10fe1d0778238bf4634 Using GlassFish 3.0.1

    Read the article

  • JSR-299 (CDI) configuration at runtime

    - by nsn
    I need to configure different @Alternatives, @Decorators and @Injectors for different runtime environments (think testing, staging and production servers). Right now I use maven to create three wars, and the only difference between those wars are in the beans.xml files. Is there a better way to do this? I do have @Alternative @Stereotypes for the different environments, but even then I need to alter beans.xml, and they don't work for @Decorators (or do they?) Is it somehow possible to instruct CDI to ignore the values in beans.xml and use a custom configuration source? Because then I could for example read a system property or other environment variable. The application exclusively runs in containers that use Weld, so a weld-specific solution would be ok. I already tried to google this but can't seem to find good search terms, and I asked the Weld-Users-Forums, but to no avail. Someone over there suggested to write my own custom extension, but I can't find any API to actually change the container configuration at runtime. I think it would be possible to have some sort of @ApplicationScoped configuration bean and inject that into all @Decorators which could then decide themselves whether they should be active or not and then in order to configure @Alternatives write @Produces methods for every interface with multiple implementations and inject the config bean there too. But this seems to me like a lot of unnecessary work to essentially duplicate functionality already present in CDI?

    Read the article

  • Integrate Weld CDI into a JSF 1.2 EJB Application on jboss 6 AS

    - by ich-bin-drin
    Hi, since two evenings i am trying to integrate weld CDI into an EJB 3.1 Application with JSF 1.2. I simply tried to call a with @Named annotated controller in an JSF page. The problem is, that no exception is thrown, when i deploy the project and also no exception is thrown when i call the page. The simple example contains only: The Controller: import javax.inject.Named; @Named public class HelloWorldController { public HelloWorldController(){ System.out.println("Hello World!"); } public String getMessage() { return "Hello Weld World"; } } And it's call: <h1><h:outputText value="#{helloWorldController.message}" /></h1> THX

    Read the article

  • How to cascade dependency resolution w/ CDI (WELD)

    - by mP
    I would like to have a central weld container that holds all my services and so on. This container would however be wrapped by a second container which contains local settings. THe goal is if a depdendency cannot be found in the outter container then i would like to then search the inner container. How can i achieve this ? I would prefer to do things in a standlike manner, without reverting to use of non standard WELD extensions.

    Read the article

  • CDI timeout results in an NPE

    - by Brian Leathem
    Is there a way (in JSF 2) to catch a Conversation timeout and redirect a user to a new page? I'm getting nasty NullPointerExceptions when the conversation times out. I could redirect the user on all NPE's, but that seems like too big a net.

    Read the article

  • Referencing CDI producer method result in h:selectOneMenu

    - by user953217
    I have a named session scoped bean CustomerRegistration which has a named producer method getNewCustomer which returns a Customer object. There is also CustomerListProducer class which produces all customers as list from the database. On the selectCustomer.xhtml page the user is then able to select one of the customers and submit the selection to the application which then simply prints out the last name of the selected customer. Now this only works when I reference the selected customer on the facelets page via #{customerRegistration.newCustomer}. When I simply use #{newCustomer} then the output for the last name is null whenever I submit the form. What's going on here? Is this the expected behavior as according to chapter 7.1 Restriction upon bean instantion of JSR-299 spec? It says: ... However, if the application directly instantiates a bean class, instead of letting the container perform instantiation, the resulting instance is not managed by the container and is not a contextual instance as defined by Section 6.5.2, “Contextual instance of a bean”. Furthermore, the capabilities listed in Section 2.1, “Functionality provided by the container to the bean” will not be available to that particular instance. In a deployed application, it is the container that is responsible for instantiating beans and initializing their dependencies. ... Here's the code: Customer.java: @javax.persistence.Entity @Veto public class Customer implements Serializable, Entity { private static final long serialVersionUID = 122193054725297662L; @Column(name = "first_name") private String firstName; @Column(name = "last_name") private String lastName; @Id @GeneratedValue() private Long id; public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } @Override public String toString() { return firstName + ", " + lastName; } @Override public Long getId() { return this.id; } } CustomerListProducer.java: @SessionScoped public class CustomerListProducer implements Serializable { @Inject private EntityManager em; private List<Customer> customers; @Inject @Category("helloworld_as7") Logger log; // @Named provides access the return value via the EL variable name // "members" in the UI (e.g., // Facelets or JSP view) @Produces @Named public List<Customer> getCustomers() { return customers; } public void onCustomerListChanged( @Observes(notifyObserver = Reception.IF_EXISTS) final Customer customer) { // retrieveAllCustomersOrderedByName(); log.info(customer.toString()); } @PostConstruct public void retrieveAllCustomersOrderedByName() { CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<Customer> criteria = cb.createQuery(Customer.class); Root<Customer> customer = criteria.from(Customer.class); // Swap criteria statements if you would like to try out type-safe // criteria queries, a new // feature in JPA 2.0 // criteria.select(member).orderBy(cb.asc(member.get(Member_.name))); criteria.select(customer).orderBy(cb.asc(customer.get("lastName"))); customers = em.createQuery(criteria).getResultList(); } } CustomerRegistration.java: @Named @SessionScoped public class CustomerRegistration implements Serializable { @Inject @Category("helloworld_as7") private Logger log; private Customer newCustomer; @Produces @Named public Customer getNewCustomer() { return newCustomer; } public void selected() { log.info("Customer " + newCustomer.getLastName() + " ausgewählt."); } @PostConstruct public void initNewCustomer() { newCustomer = new Customer(); } public void setNewCustomer(Customer newCustomer) { this.newCustomer = newCustomer; } } not working selectCustomer.xhtml: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets"> <h:head> <title>Auswahl</title> </h:head> <h:body> <h:form> <h:selectOneMenu value="#{newCustomer}" converter="customerConverter"> <f:selectItems value="#{customers}" var="current" itemLabel="#{current.firstName}, #{current.lastName}" /> </h:selectOneMenu> <h:panelGroup id="auswahl"> <h:outputText value="#{newCustomer.lastName}" /> </h:panelGroup> <h:commandButton value="Klick" action="#{customerRegistration.selected}" /> </h:form> </h:body> </html> working selectCustomer.xhtml: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets"> <h:head> <title>Auswahl</title> </h:head> <h:body> <h:form> <h:selectOneMenu value="#{customerRegistration.newCustomer}" converter="customerConverter"> <f:selectItems value="#{customers}" var="current" itemLabel="#{current.firstName}, #{current.lastName}" /> </h:selectOneMenu> <h:panelGroup id="auswahl"> <h:outputText value="#{newCustomer.lastName}" /> </h:panelGroup> <h:commandButton value="Klick" action="#{customerRegistration.selected}" /> </h:form> </h:body> </html> CustomerConverter.java: @SessionScoped @FacesConverter("customerConverter") public class CustomerConverter implements Converter, Serializable { private static final long serialVersionUID = -6093400626095413322L; @Inject EntityManager entityManager; @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { Long id = Long.valueOf(value); return entityManager.find(Customer.class, id); } @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return ((Customer) value).getId().toString(); } }

    Read the article

  • CDI @Conversation not propagated with handleNavigation()

    - by Thomas Kernstock
    I have a problem with the propagation of a long runnig conversation when I redirect the view by the handleNavigation() method. Here is my test code: I have a conversationscoped bean and two views: conversationStart.xhtml is called in Browser with URL http://localhost/tests/conversationStart.jsf?paramTestId=ParameterInUrl <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <f:metadata> <f:viewParam name="paramTestId" value="#{conversationTest.fieldTestId}" /> <f:event type="preRenderView" listener="#{conversationTest.preRenderView}" /> </f:metadata> <h:head> <title>Conversation Test</title> </h:head> <h:body> <h:form> <h2>Startpage Test Conversation with Redirect</h2> <h:messages /> <h:outputText value="Testparameter: #{conversationTest.fieldTestId}"/><br /> <h:outputText value="Logged In: #{conversationTest.loggedIn}"/><br /> <h:outputText value="Conversation ID: #{conversationTest.convID}"/><br /> <h:outputText value="Conversation Transient: #{conversationTest.convTransient}"/><br /> <h:commandButton action="#{conversationTest.startLogin}" value="Login ->" rendered="#{conversationTest.loggedIn==false}" /><br /> <h:commandLink action="/tests/conversationLogin.xhtml?faces-redirect=true" value="Login ->" rendered="#{conversationTest.loggedIn==false}" /><br /> </h:form> <h:link outcome="/tests/conversationLogin.xhtml" value="Login Link" rendered="#{conversationTest.loggedIn==false}"> <f:param name="cid" value="#{conversationTest.convID}"></f:param> </h:link> </h:body> </html> The Parameter is written to the beanfield and displayed in the view correctly. There are 3 different possibilites to navigate to the next View. All 3 work fine. The beanfield shows up the next view (conversationLogin.xhtml) too: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <h:head> <title>Conversation Test</title> </h:head> <h:body> <h:form> <h2>Loginpage Test Conversation with Redirect</h2> <h:messages /> <h:outputText value="Testparameter: #{conversationTest.fieldTestId}"/><br /> <h:outputText value="Logged In: #{conversationTest.loggedIn}"/><br /> <h:outputText value="Conversation ID: #{conversationTest.convID}"/><br /> <h:outputText value="Conversation Transient: #{conversationTest.convTransient}"/><br /> <h:commandButton action="#{conversationTest.login}" value="Login And Return" /><br /> </h:form> </h:body> </html> When I return to the Startpage by clicking the button the conversation bean still contains all values. So everything is fine. Here is the bean: package test; import java.io.Serializable; import javax.annotation.PostConstruct; import javax.enterprise.context.Conversation; import javax.enterprise.context.ConversationScoped; import javax.faces.event.ComponentSystemEvent; import javax.inject.Inject; import javax.inject.Named; @Named @ConversationScoped public class ConversationTest implements Serializable{ private static final long serialVersionUID = 1L; final String CONVERSATION_NAME="longRun"; @Inject Conversation conversation; private boolean loggedIn; private String fieldTestId; @PostConstruct public void init(){ if(conversation.isTransient()){ conversation.begin(CONVERSATION_NAME); System.out.println("New Conversation started"); } loggedIn=false; } public String getConvID(){ return conversation.getId(); } public boolean isConvTransient(){ return conversation.isTransient(); } public boolean getLoggedIn(){ return loggedIn; } public String startLogin(){ return "/tests/conversationLogin.xhtml?faces-redirect=true"; } public String login(){ loggedIn=true; return "/tests/conversationStart.xhtml?faces-redirect=true"; } public void preRenderView(ComponentSystemEvent ev) { // if(!loggedIn){ // System.out.println("Will redirect to Login"); // FacesContext ctx = FacesContext.getCurrentInstance(); // ctx.getApplication().getNavigationHandler().handleNavigation(ctx, null, "/tests/conversationLogin.xhtml?faces-redirect=true"); // ctx.renderResponse(); // } } public void setFieldTestId(String fieldTestId) { System.out.println("fieldTestID was set to: "+fieldTestId); this.fieldTestId = fieldTestId; } public String getFieldTestId() { return fieldTestId; } } Now comes the problem !! As soon as I try to redirect the page in the preRenderView method of the bean (just uncomment the code in the method), using handleNavigation() the bean is created again in the next view instead of using the allready created instance. Although the cid parameter is propagated to the next view ! Has anybody an idea what's wrong ? best regards Thomas

    Read the article

  • CDI, Hibernate JSF on jetty

    - by Arash
    I am trying to make Weld, hibernate, jsf combination work on Jetty. The best approach I found on internet was http://www.laliluna.de/articles/2011/01/12/jboss-weld-jpa-hibernate.html . It was a pain to clean up the dependencies, but I managed to go through that. Now it works for me except the initialization part of the EntityManagerStoreImpl. It seems the weld listener for jetty does not produce a ContainerInitialized event, so the init method which observes this event is never called. Could you tell me please what is the best way to bootstrap this class in the jetty environment? thanks!

    Read the article

  • Java Spotlight Episode 109: Pete Muir on CDI 1.1 @plmuir

    - by Roger Brinkley
    Interview with Pete Muir of Red Hat on CDI 1.1. Right-click or Control-click to download this MP3 file. You can also subscribe to the Java Spotlight Podcast Feed to get the latest podcast automatically. If you use iTunes you can open iTunes and subscribe with this link:  Java Spotlight Podcast in iTunes. Show Notes News Getting started with Java Embedded Videos CDI 1.1 Public Review and Feedback Events Nov 20, JCP Public Meeting (see details below) Nov 20-22, DOAG 2012, Nuremberg, Germany Dec 3-5, jDays, Göteborg, Sweden Dec 4-6, JavaOne Latin America, Sao Paolo, Brazil Dec 14-15, IndicThreads, Pune, India Feature InterviewPete Muir is leading the CDI 1.1 specification, and work on JBoss Developer Framework, a set of tutorials and examples for all JBoss users. Previously, Pete has worked on Infinispan and I led the Seam and Weld projects, and is a founder of the Arquillian project. Pete has worked on a number of specifications including JSF 2.0, AtInject and Java EE 7. Pete is a regular speaker at JUGs and conferences such as JavaOne, Devoxx, JAX, JavaBlend, JSFDays, JBoss World, Red Hat Developer Day and JUDCon.Pete is currently employed by Red Hat Inc. working on JBoss open source projects. Before working for Red Hat, Pete used and contributed to Seam whilst working at a UK based staffing agency as IT Development Manager.

    Read the article

  • ?????Java EE??????????(?3?:EJB&CDI??)??!

    - by Masa Sasaki
    WebLogic Server?????????????WebLogic Server???????? 2014?8?27?? ??49?WebLogic Server???@??????????? ????????????????Java EE???????????????(?4?)? ??3? EJB&CDI?????? EJB(Enterprise JavaBeans)???????????????????????????????????? EJB???????????????????????????? ??????????????????Bean??????????????????? ?????????????????? ??1? Java EE&WebLogic Server???(5?27?)? ??2? JSF???(6?24?)?????2????????????? ????????????????????Java?????????Java EE????!???? ????????????????????? (?????? Fusion Middleware?????? ??? ??) ??49?WebLogic Server???@???????????? 2014?8?27?? ??49?WebLogic Server???@??????????? ?????????????????????????????????? ??????Java EE??????????????: ?3?EJB&CDI??? EJB (Enterprise JavaBeans)?????????????????????????? ??????????EJB???????????????????????????? ??????????????????Bean??????????????????? ?????? ??????????? ?? ?? ???Java?????????Java EE????!? ??????????Struts???????????·?????????????? Java?????????Java EE????????????????????????? ???????????????????????????????????Java EE ????????????????? ?????? ?????????????????? ??? ?? ????????Q&A? ?WebLogic Server?????????????????????? (???)WebLogic Server?????? ????????8?27?(?) ???????????????7?00?????? ??????????????? (???WebLogic Server?????) ?????? WebLogic Server??? WebLogic Server?????????WebLogic Server???? ?! WebLogic Server??????(???????????) WebLogic Server???????? WebLogic Server??????

    Read the article

  • Java EE 7 Survey Results!

    - by reza_rahman
    On November 8th, the Java EE EG posted a survey to gather broad community feedback on a number of critical open issues. For reference, you can find the original survey here. We kept the survey open for about three weeks until November 30th. To our delight, over 1100 developers took time out of their busy lives to let their voices be heard! The results of the survey were sent to the EG on December 12th. The subsequent EG discussion is available here. The exact summary sent to the EG is available here. We would like to take this opportunity to thank each and every one the individuals who took the survey. It is very appreciated, encouraging and worth it's weight in gold. In particular, I tried to capture just some of the high-quality, intelligent, thoughtful and professional comments in the summary to the EG. I highly encourage you to continue to stay involved, perhaps through the Adopt-a-JSR program. We would also like to sincerely thank java.net, JavaLobby, TSS and InfoQ for helping spread the word about the survey. Below is a brief summary of the results... APIs to Add to Java EE 7 Full/Web Profile The first question asked which of the four new candidate APIs (WebSocket, JSON-P, JBatch and JCache) should be added to the Java EE 7 Full and Web profile respectively. As the following graph shows, there was significant support for adding all the new APIs to the full profile: Support is relatively the weakest for Batch 1.0, but still good. A lot of folks saw WebSocket 1.0 as a critical technology with comments such as this one: "A modern web application needs Web Sockets as first class citizens" While it is clearly seen as being important, a number of commenters expressed dissatisfaction with the lack of a higher-level JSON data binding API as illustrated by this comment: "How come we don't have a Data Binding API for JSON" JCache was also seen as being very important as expressed with comments like: "JCache should really be that foundational technology on which other specs have no fear to depend on" The results for the Web Profile is not surprising. While there is strong support for adding WebSocket 1.0 and JSON-P 1.0 to the Web Profile, support for adding JCache 1.0 and Batch 1.0 is relatively weak. There was actually significant opposition to adding Batch 1. 0 (with 51.8% casting a 'No' vote). Enabling CDI by Default The second question asked was whether CDI should be enabled in Java EE environments by default. A significant majority of 73.3% developers supported enabling CDI, only 13.8% opposed. Comments such as these two reflect a strong general support for CDI as well as a desire for better Java EE alignment with CDI: "CDI makes Java EE quite valuable!" "Would prefer to unify EJB, CDI and JSF lifecycles" There is, however, a palpable concern around the performance impact of enabling CDI by default as exemplified by this comment: "Java EE projects in most cases use CDI, hence it is sensible to enable CDI by default when creating a Java EE application. However, there are several issues if CDI is enabled by default: scanning can be slow - not all libs use CDI (hence, scanning is not needed)" Another significant concern appears to be around backwards compatibility and conflict with other JSR 330 implementations like Spring: "I am leaning towards yes, however can easily imagine situations where errors would be caused by automatically activating CDI, especially in cases of backward compatibility where another DI engine (such as Spring and the like) happens to use the same mechanics to inject dependencies and in that case there would be an overlap in injections and probably an uncertain outcome" Some commenters such as this one attempt to suggest solutions to these potential issues: "If you have Spring in use and use javax.inject.Inject then you might get some unexpected behavior that could be equally confusing. I guess there will be a way to switch CDI off. I'm tempted to say yes but am cautious for this reason" Consistent Usage of @Inject The third question was around using CDI/JSR 330 @Inject consistently vs. allowing JSRs to create their own injection annotations. A slight majority of 53.3% developers supported using @Inject consistently across JSRs. 28.8% said using custom injection annotations is OK, while 18.0% were not sure. The vast majority of commenters were strongly supportive of CDI and general Java EE alignment with CDI as illistrated by these comments: "Dependency Injection should be standard from now on in EE. It should use CDI as that is the DI mechanism in EE and is quite powerful. Having a new JSR specific DI mechanism to deal with just means more reflection, more proxies. JSRs should also be constructed to allow some of their objects Injectable. @Inject @TransactionalCache or @Inject @JMXBean etc...they should define the annotations and stereotypes to make their code less procedural. Dog food it. If there is a shortcoming in CDI for a JSR fix it and we will all be grateful" "We're trying to make this a comprehensive platform, right? Injection should be a fundamental part of the platform; everything else should build on the same common infrastructure. Each-having-their-own is just a recipe for chaos and having to learn the same thing 10 different ways" Expanding the Use of @Stereotype The fourth question was about expanding CDI @Stereotype to cover annotations across Java EE beyond just CDI. A significant majority of 62.3% developers supported expanding the use of @Stereotype, only 13.3% opposed. A majority of commenters supported the idea as well as the theme of general CDI/Java EE alignment as expressed in these examples: "Just like defining new types for (compositions of) existing classes, stereotypes can help make software development easier" "This is especially important if many EJB services are decoupled from the EJB component model and can be applied via individual annotations to Java EE components. @Stateless is a nicely compact annotation. Code will not improve if that will have to be applied in the future as @Transactional, @Pooled, @Secured, @Singlethreaded, @...." Some, however, expressed concerns around increased complexity such as this commenter: "Could be very convenient, but I'm afraid if it wouldn't make some important class annotations less visible" Expanding Interceptor Use The final set of questions was about expanding interceptors further across Java EE... A very solid 96.3% of developers wanted to expand interceptor use to all Java EE components. 35.7% even wanted to expand interceptors to other Java EE managed classes. Most developers (54.9%) were not sure if there is any place that injection is supported that should not support interceptors. 32.8% thought any place that supports injection should also support interceptors. Only 12.2% were certain that there are places where injection should be supported but not interceptors. The comments reflected the diversity of opinions, generally supportive of interceptors: "I think interceptors are as fundamental as injection and should be available anywhere in the platform" "The whole usage of interceptors still needs to take hold in Java programming, but it is a powerful technology that needs some time in the Sun. Basically it should become part of Java SE, maybe the next step after lambas?" A distinct chain of thought separated interceptors from filters and listeners: "I think that the Servlet API already provides a rich set of possibilities to hook yourself into different Servlet container events. I don't find a need to 'pollute' the Servlet model with the Interceptors API"

    Read the article

  • How does CDI injection work in MDBs and @Scheduled beans?

    - by Nils-Petter Nilsen
    I'm working on a large Java EE 6 application that is deployed on JBoss 6 Final. My current tasks involve using @Inject consistently instead of @EJB, but I'm running into some problems on some types of beans, specifically @MessageDriven beans and beans with @Scheduled methods. What happens is that if I'm unlucky with the timing (for @Schedule) or if there are messages in the MDBs' queues at startup, instantiation of the beans will fail because the injected resources (which are EJBs themselves) are not bound yet. Because I use @Inject, I'm guessing that the EJB container considers my beans to be ready, since the container itself does not care about @Inject; it probably simply assumes that since there are no @EJB injections, the beans are ready for use. The injected CDI proxies will then fail because the resources to inject aren't actually bound yet. Tiny example: @Stateless @LocalBean public class MySupportingBean { public void doSomething() { ... } } @Singleton public class MyScheduledBean { @Inject private MySupportingBean supportingBean; @Schedule(second = "*/1", hour = "*", minute = "*", persistent = false) public void onTimeout() { supportingBean.doSomething(); } } The above example will probably not fail often because there are only two beans, but the project I'm working on binds lots of EJBs, which will amplify the problem. But it might fail because there is no guarantee that MySupportingBean is bound first, and if onTimeout is invoked before MySupportingBean is bound, then instantiation of MyScheduledBean will fail. If I used @EJB instead, MyScheduledBean wouldn't be bound until the dependency to MySupportingBean was satisfied. Note that the example will not fail in onTimeout itself, but when CDI attempts to inject MySupportingBean. I've read a lot of posts on different forums where many people argue that @Inject is always better. Generally, I agree, but how do they handle @Schedule or @MessageDriven combined with @Inject? In my experience, it comes down to dumb luck whether the beans will work or not in those cases, and the beans will fail arbitrarily, depending on which order the EJBs are deployed in, and when @Schedule or onMessage are invoked.

    Read the article

  • Isthere an equivalent in CDI(WELD) to Guice modules and Inject ?

    - by mP
    I like the way Guice makes it fairly straight forward to manually create your own modules each with their own bindings done in code. CDI on the other hand seems to rely more on magic rather than programmatic access to sest bindings. Am i wrong or how can one achieve the same effect with WELD. Any code sample would be appreciated...

    Read the article

  • Is there a complete working example of a unit tested JPA2/CDI/JSF2 WebApp without EJBs ?

    - by Maxime ARNSTAMM
    Hello everyone, I want to build a web app in JPA2/CDI (without EJBs) and i get how to code the different beans (i worked for some time on seam/jpa apps), but i'm stuck because i can't find a complete working set of configuration files (ie : persistence.xmln web.xml and stuff), and there is always a little glitch or something i miss. My goal is to develop a simple CRUD (1 or 2 pages) but unit tested, for future use, as a code base. So if you already did this kind of mini project, or if you know where i can find a working example, that would be great if you could help me. Thanks

    Read the article

  • The 2010 JavaOne Java EE 6 Panel: Where We Are and Where We're Going

    - by janice.heiss(at)oracle.com
    An informative article, based on a 2010 JavaOne (San Francisco, California) panel session, surveys a variety of expert perspectives on Java EE 6.The panel, moderated by Oracle's Alexis Moussine-Pouchkine, consisted of:* Adam Bien, Consultant Author/ Speaker, adam-bien.com* Emmanuel Bernard, Principal Software Engineer, JBoss by Red Hat,* David Blevins, Senior Software Engineer, and co-founder of the OpenEJB project and a     founder of Apache Geronimo* Roberto Chinnici, Technical Staff Consulting Member, Oracle* Jim Knutson, Java EE Architect, IBM* Reza Rahman, Lead Engineer, Caucho Technology, Inc.,* Krasimir Semerdzhiev, Development Architect, SAP Labs BulgariaThe panel addressed such topics as Platform and API Adoption, Contexts and Dependency Injection (CDI), Java EE vs. Spring, the impact of Java EE 6 on tooling and testing, Java EE.next, along with a variety of audience questions. Read the entire article for the whole picture.

    Read the article

  • Technical Article: Oracle Magazine Java Developer of the Year Adam Bien on Java EE 6 Simplicity by Design

    - by janice.heiss(at)oracle.com
    Java Champion and Oracle Magazine Java Developer of the Year, Adam Bien, offers his unique perspective on how to leverage new Java EE 6 features to build simple and maintainable applications in a new article in Oracle Magazine. Bien examines different Java EE 6 architectures and design approaches in an effort to help developers build efficient, simple, and maintainable applications.From the article: "Java EE 6 consists of a set of independent APIs released together under the Java EE name. Although these APIs are independent, they fit together surprisingly well. For a given application, you could use only JavaServer Faces (JSF) 2.0, you could use Enterprise JavaBeans (EJB) 3.1 for transactional services, or you could use Contexts and Dependency Injection (CDI) with Java Persistence API (JPA) 2.0 and the Bean Validation model to implement transactions.""With a pragmatic mix of available Java EE 6 APIs, you can entirely eliminate the need to implement infrastructure services such as transactions, threading, throttling, or monitoring in your application. The real challenge is in selecting the right subset of APIs that minimizes overhead and complexity while making sure you don't have to reinvent the wheel with custom code. As a general rule, you should strive to use existing Java SE and Java EE services before expanding your search to find alternatives." Read the entire article here.

    Read the article

1 2 3 4 5  | Next Page >