Just discussed with Tom Elrod:
Where this fits in to the schedule depends on how it affects backward compatibility. If it can be introduced in the middle of the 5.0.x series without breaking the compatiblity guarantee, then it is not a high priority and can be pushed out from 5.0.0. Otherwise it needs to be in 5.0.0.Beta.
Three areas to consider in terms of compatibility:
1) Client to server. We are talking about a downloaded proxy, so as long as an existing client has the necessary classes on the classpath, there should be no problem. The key classes after a change would be from Remoting, and the remoting jars should be on the classpath of any 5.0.x-based client. So, probably not an issue here.
2) Configuration. Probably considerably different; need to examine if too different for a point release.
3) Compatibility within the target sets; e.g. some servers in a cluster using old-style targets, some using Remoting InvokerLocators. Managing this on the client and server sides.
See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87198 for a problem created by the use of RMI for this service (or any clustered service.) Basically, if separate networks are used for client and internal cluster traffic, a node cannot start and join the cluster if the client network is down. The RMI stubs that the DRM distributes around the cluster try to contact their origin server upon deserilization; this fails because the client network is down.
Not a huge problem, but it prevents the server starting properly and then becoming automagically usable when the client network is restored.
I talked with Scott earlier today about unifying the different proxy factory approaches being used into one AOP based one (basically abstracting out the one used within ejb3 so that is usable by all the projects). Would sit on top of remoting transport, but allow for interceptor configuration (just as with any of the proxies created now).
Figured would be good to start discussion in forum first and see if can work out some of the high level issues (and since would be the proxy used for jndi/hajndi, figured this topic would be a good one).