anonymous wrote : In the JBoss 4.0 messaging implementation, the client stack
gets created in the FactoryInterceptor on the client side.
| I was just wondering why it's been chosen to create the client interceptor
stack on the server side and passing it back to the client, rather than use a
Okay, I'll start looking at it soon. I've written a super-basic JCAContainer
which uses the Apache Commons Pool. I'll be looking at your stuff to see how
the AO interceptors work. Hopefully I can be useful in the near future.
Thanks,
View the original post :
I just have checked in code that finally allows you to write JMS client code
against the new JBoss Messaging implementation. That doesn't mean the
implementation won't pass JMS compliance tests (yet), but that you can build
the project, start the server and begin experimenting with it.
In the previous post, read: ... That doesn't mean the implementation will pass
JMS compliance tests (yes) ...
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3871434#3871434
Reply to the post :
Okay, we cross-posted on the other thread. I'll be looking for it in the near
future. I'll probably look at the interceptors first.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3870426#3870426
Reply to the post :
Yes
A good place to start is EJB3. I am using the same stuff they're using. Just
create the simplest stateless session bean and track an invocation with a
debugger. That's pretty much it.
I am pushing really hard to put the protoype out, so we'll have a common ground
to base our discussions
That implementation was incomplete. It was also based on an older version of
Bill's interceptors/proxy.
1) JMSException and log interceptors can be perVM in current aspect speak they
hold not state.
CloseInterceptor needs to be perInstance since it holds the flag as to whether
the object is
