New Remoting Integration Project

[alrubinger]

This topic is pulled from a tangential discussion on:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109907

I'd noted before that we may move the following classes:

"ALRubinger" wrote:
PojiProxy
Remoting
AOPRemotingInvocationHandler

...from jboss-remoting-aspects into a new Remoting-esque project, where I'd also cited:

"ALRubinger" wrote:
Only thing we get by moving it out is an organizational benefit.

This is incorrect, given https://jira.jboss.org/jira/browse/JBASPECT-3. The issue is that jboss-remoting-aspects holds these convenience classes which also create a dependency upon the Tx and Security aspects, violating the orthogonal nature of an aspect-based project.

So the question remaining is, where to put the new project?

http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/ - Contains SPIs, so this doesn't seem like a great fit

http://anonsvn.jboss.org/repos/jbossas/projects/remoting - Seems misleading, this is not the Remoting project itself, but rather some convenience mechanisms to using Remoting alongside jboss-aspects.

S,
ALR

[alrubinger]

There's an older discussion on this here:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147407

...where Carlo says that the dependency is OK. I disagree; if I want to use a remoting aspect in my project I don't want to bring in Security or Tx because a Util class is in the wrong place. :)

S,
ALR

[starksm64]

So remove those dependencies and inject them if they are really needed.

[alrubinger]

Spell it out for me? Unclear.

S,
ALR

[brian.stansberry]

Not sure if this was what Scott meant, but the dependencies come via the Remoting.makeRemotable(InstanceAdvised proxy, InvokerLocator locator, Object objectId) method, which AFAICT isn't used anywhere. If someone wanted to get the same functionality they can create the equivalent interceptor list and call makeRemotable(InstanceAdvised proxy, InvokerLocator locator, Object objectId, List interceptors, String subsystem). So drop the convenience method.

If you're concerned about dropping the method in a CR2, copy the class back to the AS project aspects module. Then create a different class in remoting-aspects, e.g. RemotingUtil with the same behavior x-the offending method. The class in the aspects module delegates to RemotingUtil.

There was an equivalent class in aspects called ClusteredRemoting. Had same problem and no one was using it. When I pulled the clustering stuff out of aspects I just left that one there in case an end user wanted it.

[alrubinger]

I like your style, Stansberry.

Added comment to the ticket, so I'll get to this once I get to the bottom of what/who broke the Unit Tests in there.

S,
ALR

[starksm64]

Yes, that is what I meant.