[EJB3] - @EJB vs. InitialCotext.doLookup(...)
by Joachim Heidenreich
Joachim Heidenreich [http://community.jboss.org/people/carcophan] created the discussion
"@EJB vs. InitialCotext.doLookup(...)"
To view the discussion, visit: http://community.jboss.org/message/595940#595940
--------------------------------------------------------------
Hello,
I have a question about context lookups and dependency injection regarding the following scenario:
I'm using JBoss 6.0, JSF 2.1 (Mojarra), EJB3.1
I have and ejb jar and a war archive packaged together in an ear.
My ejb-jar contains a stateless, no interface (local) session bean.
My war has a session scoped managed bean.
Inside my managed bean, I use the @EJB annotation to inject an instance of my no-interface session bean - works like a charm!
However, when I deploy the ejb-jar and the war archives separately (without the ear) I get an error, stating that "Could not resolve @EJB reference... ". However when I remove the @EJB annotation in my managed bean and do a "InitialContext.doLookup("...") instead, I get no errors and everything isfine.
Why doesn't dependency Injection using the @EJB annotation work when deploying the artifacts separately but a manual lookup does?
(I first deploy my ejb-jar and afterwards I deploy the war.)
Does anyone have a clue?
----
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595940#595940]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years
[JBoss Messaging] - Only one subscriber sees a topic message in a clustered topic setup
by Bob Muller
Bob Muller [http://community.jboss.org/people/poesys] created the discussion
"Only one subscriber sees a topic message in a clustered topic setup"
To view the discussion, visit: http://community.jboss.org/message/595433#595433
--------------------------------------------------------------
I have created a straightforward Topic setup on a two-node JBoss 5.1 cluster (using the all server with Messaging defaults). Here's the topic configuration I added in destinations-service.xml on all nodes:
<mbean
code="org.jboss.jms.server.destination.TopicService"
name="jboss.messaging.destination:service=Topic,name=PoesysCacheDelete"
xmbean-dd="xmdesc/Topic-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
Our web app has a simple pojo cache (a Java Map) that holds data objects queried from a database. Each node has a separate singleton cache. I am using messaging to have the cache on each node remove an object on demand. So the behavior I want is:
1. The user updates an object.
2. The database transaction happens.
3. The data access code sends a message to the topic to remove the object from the cache (the payload is the key in the Map).
4. The registered listeners (MessageListener implementations) in the instance of the web app running on each node receive the published topic message and respond by removing the cached object as requested.
This works fine as long as I have only one node; I'm logging all this and I see the message sent and received and the cache deleted.
However, when I have two nodes, everything stops working. Looking at the logs, it appears that when a node receives the message and acts on it, the other node(s) don't ever see that message. Since I want the action to happen on all nodes, this means the cache operation(s) don't happen on all the nodes. In particular, the sticky-session setup means that the originating/publishing node only sees some of the messages and may or may not remove the object from its own cache, which then causes the next page to display old data.
This looks an awful lot like a race condition between the nodes. My understanding was (and seems to be verified by looking through the topics on this discussion forum) that a clustered topic means that ALL listeners get the message. I can verify that isn't true here--the instant a message is received on one node, the other node(s) don't see it.
I did verify that the mbean is clustered by examining it in the jmx-console for the nodes.
This is the Java code that implements MessageListener:
/**
* A thread-based class that listens for messages about the Poesys/DB cache.
*
* @author Robert J. Muller
*/
public class CacheMessageListener implements Runnable, MessageListener {
/**
* Logger for this class
*/
private static final Logger logger =
Logger.getLogger(CacheMessageListener.class);
private static final String LISTENER_MSG =
"com.poesys.db.dao.msg.listener_problem";
private static final String DELETE_MSG =
"com.poesys.db.dao.msg.delete_problem";
private static final String INTERRUPT_MSG =
"com.poesys.db.dao.msg.interrupted";
/** JMS topic name for the Poesys/DB delete topic */
public static final String DELETE_TOPIC = "topic/PoesysCacheDelete";
/** JMS connection factory name */
public static final String CONNECTION_FACTORY = "ClusteredConnectionFactory";
/** JMS ObjectMessage property name for cache name property */
public static final String CACHE_NAME_PROPERTY = "CacheName";
private Connection connection;
private Session sessionConsumer;
private MessageConsumer consumer;
/**
* Runs the message listener.
*/
public void run() {
try {
// Look up the connection factory using JNDI.
Context initial = new InitialContext();
ConnectionFactory cf =
(ConnectionFactory)initial.lookup(CONNECTION_FACTORY);
// Set this object to be a message listener for delete requests.
Destination deleteTopic = (Destination)initial.lookup(DELETE_TOPIC);
connection = cf.createConnection();
sessionConsumer =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
consumer = sessionConsumer.createConsumer(deleteTopic);
consumer.setMessageListener(this);
connection.start();
logger.info("Cache message listener started, listening for cache removal requests");
// Sleep indefinitely until interruption.
while (!Thread.currentThread().isInterrupted()) {
// Sleeps for 10 seconds
Thread.sleep(10 * 1000);
}
} catch (InterruptedException e) {
String message = com.poesys.db.Message.getMessage(INTERRUPT_MSG, null);
logger.info(message);
} catch (Exception e) {
String message = com.poesys.db.Message.getMessage(LISTENER_MSG, null);
logger.error(message, e);
} finally {
if (connection != null) {
try {
connection.close();
} catch (JMSException e) {
String message = com.poesys.db.Message.getMessage(LISTENER_MSG, null);
logger.error(message, e);
}
}
}
}
/*
* (non-Javadoc)
*
* @see javax.jms.MessageListener#onMessage(javax.jms.Message)
*/
@Override
public void onMessage(Message message) {
IPrimaryKey key = null;
String cacheName = null;
if (message == null) {
logger.error("Cache message listener received null message");
} else {
try {
logger.debug("Received cache removal request");
// Get the message and extract the key and the cache name.
ObjectMessage objectMessage = (ObjectMessage)message;
if (objectMessage != null) {
// Message key is the object payload.
Serializable object = objectMessage.getObject();
if (object instanceof com.poesys.ms.pk.IPrimaryKey) {
com.poesys.ms.pk.IPrimaryKey messageKey =
(com.poesys.ms.pk.IPrimaryKey)objectMessage.getObject();
// Translate into database primary key.
key = MessageKeyFactory.getKey(messageKey);
// Cache name is a property.
cacheName = objectMessage.getStringProperty(CACHE_NAME_PROPERTY);
IDtoCache<?> cache = DaoManager.getCache(cacheName);
// Remove the object from the local cache only if it's there; if
// it's not there, move on since there's nothing to do.
if (cache != null) {
logger.debug("Removing key " + key.getValueList() + " from cache "
+ cacheName);
cache.removeLocally(key);
} else {
logger.debug("No cache from which to remove object");
}
} else {
logger.error("Cache message listener received message with a payload that was not a primary key");
}
}
} catch (JMSException e) {
// log full information and ignore
Object[] objects = { cacheName, key.getValueList() };
String errorMsg = com.poesys.db.Message.getMessage(DELETE_MSG, objects);
logger.error(errorMsg, e);
} catch (RuntimeException e) {
// log and ignore
logger.error("Runtime exception in onMessage: ", e);
}
}
}
}
This is the Java code that sends the message:
@Override
public void remove(IPrimaryKey key) {
// Send a message to listeners asking to remove there. This will remove
// the object from all listening caches with the cache name of this cache,
// including THIS one.
Connection connection = null;
try {
Context initial = new InitialContext();
ConnectionFactory cf =
(ConnectionFactory)initial.lookup(CacheMessageListener.CONNECTION_FACTORY);
Destination deleteTopic =
(Destination)initial.lookup(CacheMessageListener.DELETE_TOPIC);
connection = cf.createConnection();
Session session =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(deleteTopic);
connection.start();
ObjectMessage om = session.createObjectMessage(key.getMessageObject());
om.setStringProperty(CacheMessageListener.CACHE_NAME_PROPERTY,
getCacheName());
producer.send(om);
logger.debug("Sent message to remove " + key.getValueList()
+ " from cache " + getCacheName());
} catch (Exception e) {
Object[] objects = { getCacheName() };
String message = com.poesys.db.Message.getMessage(PRODUCER_MSG, objects);
logger.error(message, e);
} finally {
if (connection != null) {
try {
connection.close();
} catch (JMSException e) {
Object[] objects = { getCacheName() };
String message =
com.poesys.db.Message.getMessage(PRODUCER_MSG, objects);
logger.error(message, e);
}
}
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595433#595433]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years
[JBoss Cache] - Hibernate Second Level cache not working properly on Jboss 5.1 cluster
by Ciprian Stoica
Ciprian Stoica [http://community.jboss.org/people/cipris] created the discussion
"Hibernate Second Level cache not working properly on Jboss 5.1 cluster"
To view the discussion, visit: http://community.jboss.org/message/595950#595950
--------------------------------------------------------------
Hi,
I try to set-up JBoss Cache 2 as a Hibernate Second Level Cache on Jboss 5.1.G.A. As a reference I use the document from here: www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf.
I run Jboss in a cluster which consists on two Linux machines (RHEL 4 and Ubuntu 10).
My hibernate.cfg.xml contains these lines:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
" http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<property name="connection.username">root</property>
<property name="connection.password">root</property>
<property name="connection.url">jdbc:mysql://192.168.223.169:3306/hibtest</property>
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.show_sql">true</property>
<property name="hibernate.format_sql">true</property>
<property name="hibernate.cache.region.factory_class">org.hibernate.cache.jbc2.MultiplexedJBossCacheRegionFactory</property>
<property name="hibernate.cache.use_second_level_cache">true</property>
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
<mapping resource="ro/memiq/training/hibernate/Usr.hbm.xml"></mapping>
<mapping resource="ro/memiq/training/hibernate/Address.hbm.xml"></mapping>
</session-factory>
</hibernate-configuration>
The cluster starts properly and according to documentation the cache should work properly too. But unfortunately it doesn't. When I read an entity on one node, the I delete it on the other node, then I re-read it on the first node, the entity is still displayed on the first node. The cache on the nodes doesn't synchronize.
I suppose I make a mistake somewhere but I don't see where. If you need more details about the project configuration I will post the here.
Many Thanks,
Ciprian
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595950#595950]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years
[JBoss Web Services] - Problem with calling WebService - Can't transmit message
by Kobi Mbagwu
Kobi Mbagwu [http://community.jboss.org/people/ombagwu] created the discussion
"Problem with calling WebService - Can't transmit message"
To view the discussion, visit: http://community.jboss.org/message/595938#595938
--------------------------------------------------------------
Hello All,
Please I'll like a solution to the problem I have been having for 2 days now. I have a webservice client I developed as a stand alone application, when I run this application it connects successfully to my webservice. However when I compile and deploy it as a web application in Jboss 5.1.0-GA, it doesn't connect successfully to the webservice, instead I get an exception as shown below. I'll appreciate your solutions.
13:07:53,535 ERROR [CommonClient] Exception caught while (preparing for) performing the invocation:
java.io.IOException: Could not transmit message
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:265)
at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:340)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:290)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:170)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
at $Proxy297.topup(Unknown Source)
at org.apache.jsp.test_jsp._jspService(test_jsp.java:102)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker after 1 attempt(s)
at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:249)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:161)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:243)
... 33 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:525)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.http.HttpClient.New(HttpClient.java:323)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:904)
at org.jboss.remoting.transport.http.HTTPClientInvoker.getOutputStream(HTTPClientInvoker.java:1214)
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:334)
at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:231)
... 38 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595938#595938]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years