Of course, J2EE TCK may not explicitly reference Aspects or AOP instrumentation. I even wonder if J2EE will ever talk about AOP as it may sound a little too invasive/disruptive to let bean developers to play with.
But does JBoss plan to implement the strict constraints of J2EE constructs especially the ones that related to thread manipulation mandated by the TCK and so prevent the deployment of J2EE application that may blatantly violate those constraints ? Something that both weblogic and websphere try to enfore today.
Or is it the case that the TCK does not require application servers to be so "precise" in behavior allowing JBoss to be more tolerant as it is right now ? Sorry, I have'nt really had time or patience to read through and digest all of the Specs.
This tolerant behavior is a double-edged sword, it definitely helps developers to maybe successfully accomplish certain features via a path that J2EE may not completely agree with. But it hampers productivity of developers who most commonly use JBoss for development but may have unknowingly violated some J2EE constraints only to realize much later in the game during the porting stage. I guess the answer could lie in those J2EE verfier tools and how diligently it is used and monitored. Also most of the time the disparate class-loader architectures end up being the culprits.
Bill - I appreciate your understanding of my problem and will await your resolution however soon you or your team would be able to provide a resolution.
I don't understand the problem. You call a local itnerface of a Session bean from within a try/catch of an MDB? That local interface is throwing an exception? The message is getting redelivered?
Yes, the OnMessage handler goes through and terminates, but it's like the message is stuck in the jms queue and the handler continues to receive the message from the container.
I can only seem to get rid of the message by undeploying the bean, opening hsql and deleting the message from jms_messages, then restarting jboss.
public void onMessage(Message msg)
// getting here means we end up with re-deliveries
// send reply back to queue
Think I may have found the problem.
The Exception may have been a Throwable which wasn't catched by the try/catch in the onMessage callback. So the container was submitting the message until it was handled correctly, which was never. Some more testing is required to be sure.
Does anyone know if there are more annotations for MDB's than those listed in the EJB£ MDB example?