JBossDeveloper

"bill.burke@jboss.com" wrote:

"scott.stark@jboss.org" wrote:
So let's ditch the ASF stuff in favor of jca inflow abstraction, including as the default MDB 2.1 container in 4.x. Is this something that should be a critical task for 4.0.4?

ignorant question, doesn't HA-JMS depend on ASF? Or can we write a JCA adapter around ASF?

"bill.burke@jboss.com" wrote:

Or can we write a JCA adapter around ASF?

The other issue is adding metrics/management
and other jca inbound QOI (quality of implementation)
such as doing a JAAS login before invoking the mdb.

This should be done via interceptors inside the proxy/MessageEndpoint.

This is currently impossible with the EJB3 version since it is just an invocation handler
behind a java.lang.reflect.Proxy.

"kabir.khan@jboss.com" wrote:

"adrian@jboss.org" wrote:

I currently use a prototype ProxyAdvisor although Kabir is supposed to have
done some work on (or replaced?) the AOP instance advisors recently.

Yes, this is available in the new weaving in AOP 2.0. Once you guys have battled out which version of the aop proxy to be used, adding this to a proxy based solution should be straightforward.

 /** Create a composite proxy for the given interfaces, invoker.
 @param id the cache id for the target object if any
 @param targetName the name of the server side service
 @param invoker the detached invoker stub to embed in the proxy
 @param jndiName the JNDI name the proxy will be bound under if not null
 @param proxyBindingName the invoker-proxy-binding name if not null
 @param interceptorClasses the Class objects for the interceptors
 @param loader the ClassLoader to associate the the Proxy
 @param ifaces the Class objects for the interfaces the Proxy implements
 @param ctx any context to add the invocation context proxy
 */
 public Object createProxy(Object id, ObjectName targetName,
 Invoker invoker, String jndiName, String proxyBindingName,
 ArrayList interceptorClasses, ClassLoader loader, Class[] ifaces, HashMap ctx)
 {

Can we start a different thread for the Proxy impl.
Although I think there already is one in the AOP forum. :-)

"bill.burke@jboss.com" wrote:

"adrian@jboss.org" wrote:

Does it support handling all the internal "book-keeping" with injection of overrides
like org.jboss.proxy or my prototype ProxyAdvisor.

NOTE: My ProxyAdvisor prototype does not handle "MetaData"
like the "context" in org.jboss.proxy

Not sure what you mean, but the new AOP 2.0 design basically has every instance is allowed to have its own Aspect Domain, so anything that you can add to a class can be done at the instance level except introductions. (metadata, annotations, bindings). For introductions on a per-instance basis, we'll do this with a proxy. I had prototyped this with the aop/mc integration.

I've closed this bug report:
http://jira.jboss.com/jira/browse/JBAS-3327

Don't report bugs for the JCA/JMS people to fix until
the integration issues raised here have been resolved.

We only fix bugs in code we support.

If think you have a bug in JCA/JMS integration, the correct place
to write a testcase is
org.jboss.test.messagedriven.test.*
in the main testsuite.

"EJB3" dependening on the "connector" module is bogus.

Even "server" which is the integration project for AppServer
doesn't do that.

This integration is becoming even more of a mess.

Integrartion is:
user -> api/spi
NOT
user -> implementation details

And EJB3 shouldn't be defining the integration anyway.

Make an integration point and then let people implement it
independently.

Tying the two together just leads to lots of problems like

1) too tightly coupled projects that must be developed/maintained in-sync
2) the consumed project (in this case JCA) doesn't know how it is being
used because the tests of functionality are in the EJB3 project not the
JCA project
3) use of things that happen to be public but were never intended
to be used externally, they are implementation details that are subject
to change without detail.

If you don't see why this is a problem,
imagine how your code will work when we switch from
the "connector" project to the new "jca" project.