[JBoss JIRA] Created: (EJBTHREE-768) MDB deployment error
by Ramil Israfilov (JIRA)
MDB deployment error
--------------------
Key: EJBTHREE-768
URL: http://jira.jboss.com/jira/browse/EJBTHREE-768
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Environment: JDK1.5.0_06, UNIX and windows platforms
Reporter: Ramil Israfilov
Fix For: EJB 3.0 RC10 - FD
I have an MDB which is defined like that
import javax.jms.MessageListener;
@MessageDriven(name = "EJBExecutorMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/ExecutorQueue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"),
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "4"),
@ActivationConfigProperty(propertyName = "SubscriptionDurability", propertyValue = "Durable") })
public class EJBExecutorMDB implements MessageListener {
....
It works perfect during in JBOSS, but then I run it in JUNIT it fails with exception: "unable to determine messagingType interface for MDB"
Only one difference that in JUNIT test I instrument built classes using cobertura - in that case my class implements two interfaces: MessageListener and cobertura interface.
After looking in source code I found in org.jboss.ejb3.mdb.MDB:
if (messagingType.getName().equals(Object.class.getName()))
{
ArrayList<Class> list = ProxyFactoryHelper.getBusinessInterfaces(clazz);
if (list.size() > 1 || list.size() == 0) throw new RuntimeException("unable to determine messagingType interface for MDB");
messagingType = list.get(0);
}
Why such a dummy check is done ??? Why class must implement one and only one interface ??
could you check superclasses and allow multiple interfaces implementations on the class.
Also on the link to forum people has similar problem: they don't implement interface, but extend superclass. And they got the same exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JGRP-354) If response unmarshalling fails, RequestCorrelator passes garbage as the response
by Brian Stansberry (JIRA)
If response unmarshalling fails, RequestCorrelator passes garbage as the response
---------------------------------------------------------------------------------
Key: JGRP-354
URL: http://jira.jboss.com/jira/browse/JGRP-354
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.5
>From RequestCorrelator.receiveMessage:
RspCollector coll=findEntry(hdr.id);
if(coll != null) {
Address sender=msg.getSrc();
Object retval=null;
byte[] buf=msg.getBuffer();
try {
retval=marshaller != null? marshaller.objectFromByteBuffer(buf) : Util.objectFromByteBuffer(buf);
}
catch(Exception e) {
log.error("failed unmarshalling buffer into return value", e);
try {
retval=marshaller != null? marshaller.objectToByteBuffer(e) : Util.objectToByteBuffer(e);
}
catch(Exception e1) {
log.error("failed marshalling exception " + e1 + " into buffer", e1);
}
}
coll.receiveResponse(retval, sender);
}
The outer catch block should just be
catch (Exception e) {
log.error("failed unmarshalling buffer into return value", e);
retval = e;
}
Looks like the bit about marshalling the exception came from handleRequest(), where it's needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JGRP-274) Don't bind to a NIC if bind address is not set
by Bela Ban (JIRA)
Don't bind to a NIC if bind address is not set
----------------------------------------------
Key: JGRP-274
URL: http://jira.jboss.com/jira/browse/JGRP-274
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
If -Dbind.address or bind_addr are not set, JGroups picks the NIC to bind sockets to itself. However, especially for ServerSockets, this may not be desirable because we may want to have ServerSockets be able to receive packets through all interfaces, e.g.
- NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1 (loopback)
- When the bind address is set to 192.168.5.2, a given ServerSocket on port 7500 will *only accept packets from this NIC*
- If someone connects to 192.168.0.2:7500 or 127.0.0.1:7500, the client will not be able to establish a connection because nobody is listening on those ports on the given NICs
- If bind address was not set, this would be possible
- Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc
- We need to think about semantics for MulticastSockets where a wildcard address (not setting the bind address) means that the operating system picks the NIC, and *not* that the MulticastSocket will listen on all interfaces for incoming packets
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months