SeamFramework.orgCommunity Documentation
Web Beans sind voll in die Java EE Umgebung integriert. Web Beans besitzen Zugriff auf Java EE Resourcen und JPA Persistenzkontexte. Sie können in Unified EL Ausdrücken in JSF- und JSP-Seiten verwendet werden. Sie können sogar in einige Objekte eingespeist werden, etwa Servlets and Message-Driven Beans, die keine Web Beans sind.
Alle einfachen wie auch Enterprise Web Beans können die Java EE "Dependency"-Einspeisung mittels @Resource, @EJB und @PersistenceContext verwenden. Wir haben bereits einige Beispiele hierfür gesehen, obwohl wir diesen zum damaligen Zeitpunkt nicht viel Beachtung geschenkt haben:
@Transactional @Interceptor
public class TransactionInterceptor {
@Resource Transaction transaction;
@AroundInvoke public Object manageTransaction(InvocationContext ctx) { ... }
}
@SessionScoped
public class Login {
@Current Credentials credentials;
@PersistenceContext EntityManager userDatabase;
...
}
Die Java EE @PostConstruct und @PreDestroy Callbacks werden ebenfalls für alle einfachen wie auch Enterprise Web Beans unterstützt. Die @PostConstruct-Methode wird nach Durchführung aller Einspeisungen aufgerufen.
Es gilt eine Einschränkung hier: @PersistenceContext(type=EXTENDED) wird nicht für einfache Web Beans unterstützt.
In Java EE 6 ist die Verwendung eines Web Beans von einem Servlet ganz einfach. Speisen Sie einfach das Web Bean mittels Web Beans Field oder Initialisierungsmethodeneinspeisung (sog. "Initializer Method Injection") ein.
public class Login extends HttpServlet {
@Current Credentials credentials;
@Current Login login;
@Override
public void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
credentials.setUsername( request.getAttribute("username") ):
credentials.setPassword( request.getAttribute("password") ):
login.login();
if ( login.isLoggedIn() ) {
response.sendRedirect("/home.jsp");
}
else {
response.sendRedirect("/loginError.jsp");
}
}
}
Der Web Beans Client Proxy kümmert sich um Aufrufe der Routing-Methode vom Servlet, um die Instanzen von Credentials und Login für die aktuelle Anfrage und HTTP-Session zu korrigieren.
Einspeisung von Web Beans gilt für alle EJBs, selbst wenn sie nicht der Steuerung des Web Bean Manager s unterliegen (wenn sie etwa durch direkten JNDI-Lookup oder Einspeisung mittels @EJB erworben wurden). Insbesondere Web Beans Einspeisung in Message-Driven Beans, die nicht als Web Beans angesehen werden, da sie nicht eingespeist werden können.
Sie können sogar Web Beans Interzeptor-Bindings für Message-Driven Beans.
@Transactional @MessageDriven
public class ProcessOrder implements MessageListener {
@Current Inventory inventory;
@PersistenceContext EntityManager em;
public void onMessage(Message message) {
...
}
}
Daher ist der Empfang von Nachrichten in einer Web Beans Umgebung sehr einfach. Seien Sie sich aber dessen bewusst, dass bei Lieferung einer Nachricht an ein Message-Driven Bean keine Session oder Konversationskontext verfügbar ist. Es sind nur @RequestScoped und @ApplicationScoped Web Beans verfügbar.
Es ist ebenfalls ganz einfach mittels Web Beans Nachrichten zu versenden.
Das Versenden von Nachrichten unter Verwendung von JMS kann aufgrund der Anzahl verschiedener Objekte mit denen Sie zu tun haben recht komplex sein. Für Warteschlangen haben wir Queue, QueueConnectionFactory, QueueConnection, QueueSession und QueueSender. Für Topics haben wir Topic, TopicConnectionFactory, TopicConnection, TopicSession und TopicPublisher. Jedes dieser Objekte besitzt einen eigenen Lebenszyklus und ein eigenes Threading-Modell, das unsere Aufmerksamkeit erfordert.
Web Beans übernehmen all das für uns. Das Einzige, was wir tun müssen ist unsere Warteschlange oder unser Topic in web-beans.xml zu deklarieren und einen assoziierten Binding-Typ und eine Connection-Factory festzulegen.
<Queue>
<destination
>java:comp/env/jms/OrderQueue</destination>
<connectionFactory
>java:comp/env/jms/QueueConnectionFactory</connectionFactory>
<myapp:OrderProcessor/>
</Queue
>
<Topic>
<destination
>java:comp/env/jms/StockPrices</destination>
<connectionFactory
>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<myapp:StockPrices/>
</Topic
>
Jetzt können wir einfach Queue, QueueConnection, QueueSession oder QueueSender für eine Warteschlange oder aber Topic, TopicConnection, TopicSession oder TopicPublisher für ein Topic einspeisen.
@OrderProcessor QueueSender orderSender;
@OrderProcessor QueueSession orderSession;
public void sendMessage() {
MapMessage msg = orderSession.createMapMessage();
...
orderSender.send(msg);
}
@StockPrices TopicPublisher pricePublisher;
@StockPrices TopicSession priceSession;
public void sendMessage(String price) {
pricePublisher.send( priceSession.createTextMessage(price) );
}
Der Lebenszyklus der eingespeisten JMS-Objekte wird komplett durch den Web Bean Manager gesteuert.
Web Beans definiert kein spezielles Deployment-Archiv. Sie können Web Beans in JARs, EJB-JARs oder WARs verpacken, jedem Deployment Speicherort im Klassenpfad der Anwendung. Allerdings muss jedes Web Beans enthaltene Archiv eine Datei namens web-beans.xml im META-INF oder WEB-INF-Verzeichnis enthalten. Die Datei kann leer sein. Web Beans die in Archiven deployt werden, die keine web-beans.xml-Datei enthalten, sind nicht für die Verwendung in der Anwendung verfügbar.
Für die Java SE Ausführung können Web Beans an einem beliebigen Speicherort deployt werden, in welchem EJBs zur Ausführung durch den einbettbaren EJB Lite Container deployt werden können. Auch hier muss jeder Speicherort eine web-beans.xml-Datei enthalten.