Moving core o.j.invocation classes to common

[brian.stansberry]

With the effort underway to consolidate the client-side interceptor models, a problem that comes up is where to put some of the core org.jboss.invocation classes, e.g. org.jboss.invocation.Invocation.

http://jira.jboss.com/jira/browse/JBREM-385 says the old invokers will move to remoting, so Remoting will need access to these classes. So leaving them in the AS server module is no good; don't want remoting depending on AS/server. Depending on how we refactor, some code in an independent cluster binary might have the same problem.

Moving them to Remoting could work, but smells funny due to the widespread usage of these classes in the AS. For example, org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor would be importing a class from Remoting, which seems a bit odd.

A logical place for these is in common-core. What do people (Scott/Adrian) think about moving them there?

I worked out what I think would need to be moved, all in o.j.invocation:

Invocation
InvocationContext
InvocationKey
InvocationType
Invoker
JBossLazyUnmarshallingException
MarshalledInvocation
MarshalledValue
MarshalledValueInputStream
MarshalledValueOutputStream
PayloadKey
SecurityActions


Regardless of what is decided about the rest of the classes, the JBoss Cache people would like to see MarshalledValueIn(Out)putStream moved. Those are true utility classes, and JBC uses them. Moving them to common-core would make it possible to eliminate jboss-minimal.jar from the standalone JBC distribution.

[starksm64]

These classes really intersect with the aop classes, and we have to get to a reusable interceptor model based on the aop stuff to allow for aspects to be resued. Aop has duplicate MarshalledValue* style classes as well. A split of the aop as needed into something in the aop-mc-int project of the microcontainer:
https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/

[brian.stansberry]

OK, good. Putting a bunch more classes into common-core didn't have a good feel to it, kind of the first step on the road to making common-core a dumping ground. If there's another natural home for this style of class, that's better.

Except...I do think MarshalledValueIn(Out)putStream belong in common. Server or aop version, whichever. Unless I missed something those are just utility classes. Having to pull in an aop-mc-int binary just to use those 2 kinda sucks.

Unless in the end anyone who uses them (i.e. JBC) is going to end up depending on the microcontainer binaries anyway.

[starksm64]

org.jboss.aop.util.{MarshalledValue,MarshalledValueInputStream,MarshalledValueOutputStream} are just copies of the server classes that only have dependencies on j2se classes. They could easily be moved to the common project.

[manik]

Sounds precisely like what we need then.

[tom.elrod]

So if I understand correctly, the following go into microcontainer:

Invocation
InvocationContext
InvocationKey
InvocationType
Invoker
JBossLazyUnmarshallingException
PayloadKey
SecurityActions

and the following go into common:

MarshalledInvocation
MarshalledValue
MarshalledValueInputStream
MarshalledValueOutputStream

correct?

[starksm64]

No, the mc should not be dealing with these legacy classes:
Invocation
InvocationContext
InvocationKey
InvocationType
Invoker
JBossLazyUnmarshallingException
PayloadKey
SecurityActions

These would need to be a legacy unified invoker artifact in a remoting subproject.

The new aop based invoker model is what needs to exist in the mc project as the basis for a unified proxy/aspect model.

[brian.stansberry]

For the stream port, see http://jira.jboss.com/jira/browse/JBCOMMON-8.

IIRC, the committer list for common was limited. Is that still the case? I assigned the JIRA to myself but will need rights.

[starksm64]

I added [e-mail] to the common dev list

[brian.stansberry]

Thanks for adding me.

These would need to be a legacy unified invoker artifact in a remoting subproject.

Where were you thinking this legacy artifact would be used? In 5.0.x, the new model is going to be used on the server side, so obviously not there.

Tom mentioned you'd expressed interest in backporting the new stuff to 4.0. In 4.0 I imagine the new model could be an alternative for the client side. But don't see how it could used be on the server side w/o breaking any existing custom interceptors people have written. So, if in 4.0 org.jboss.invocation is the server-side model, don't know why we'd move it to remoting.

Only thing I could think of is in 5.0.x having some special proxy factories that could create a proxy that used the old model, and then a special invoker that could translate the call using the old model into the new model for use inside the server. A transition aid for people with custom client interceptors/load balance policies. But, well, yuck :(

[starksm64]

Only as a backward compatibility solution. We have users running 3.2.8.SP1 client jars in jdk1.3 envs talking to 4.0.x servers because of legacy setup issues and we will have the same thing with 5.0.x.