Discussion of JBAS-2436| JBoss.org Content Archive (Read Only)

15. Re: Discussion of JBAS-2436

starksm64 Feb 21, 2006 5:18 PM (in response to clebert.suconic)

The issue is where does the IMarshalledValue belong. The disconnect I have is that there is a tagging interface in the common module that is used by nothing in the module. This tagging interface has been pushed to the MarshalledValue so the MarshalledInvocation can have an alternate serialized object form. The org.jboss.invocation.* package is the only place IMarshalledValue is used.

The org.jboss.invocation.* package is now dependent on remoting/serialization. The questions I have are:

1. Why couldn't the MarshalledValue be used as the base class for the new jboss remoting/serialization objects?
2. If there is a need for an IMarshalledValue, why couldn't the server org.jboss.invocation package be refactored to better align with the remoting stuff. This is the precursor to the remoting project.
3. If there is a need for an IMarshalledValue, why couldn't it be introduced on a trivial subclass of MarshalledValue (MarshalledValueExt) and all contexts wanting to use pluggable serialization updated to use MarshalledValueExt.

Its a question of the lesser evil at this point. Introducing a dependency on some remoting/serialization subset in tomcat vs hacking up up the existing jars dependencies are the evils. I would expect we want to introduce the serialization stuff to tomcat for session serialization and IMarshalledValue should live in the serialization layer.

16. Re: Discussion of JBAS-2436

clebert.suconic Feb 21, 2006 5:39 PM (in response to clebert.suconic)

1. Why couldn't the MarshalledValue be used as the base class for the new jboss remoting/serialization objects?

Because there are different implementations of MarshalledValue now.

MarshalledValue uses ObjectOutputStream over ByteArrayOutputStream.

The MarshalledValue that uses serialization (org.jboss.remoting.serialization.impl.jboss.LocalMarshalledValue) uses JBossSerialization, and it doesn't use a ByteArray at al. (DataContainer is converted to bytes only if writeExternal is called)

It uses DataContainer, which does what I call "Smart Cloning", reusing final fields on Local calls guaranteeing class loading isolation. (It's much faster to reuse an integer/long than convert it to bytes back and forth).

1. This was actually refactored to JBossRemoting. I'm keeping MarshalledValue into org.jboss.invocation.* ?

This was refactored. JBossRemoting has one MarshalledValue for each SerializationManager. org.jboss.invocation.MarshalledValue was kept for legacy and serial compatibility.

3. If there is a need for an IMarshalledValue, why couldn't it be introduced on a trivial subclass of MarshalledValue (MarshalledValueExt) and all contexts wanting to use pluggable serialization updated to use MarshalledValueExt.

I wanted to make sure an old client would be able to communicate with a new client.

I mean, an old version of MarshalledInvocation needs to communicate with a new version of MarshalledInvocation if we are using default options.

17. Re: Discussion of JBAS-2436

starksm64 Feb 21, 2006 6:00 PM (in response to clebert.suconic)

This was refactored. JBossRemoting has one MarshalledValue for each SerializationManager. org.jboss.invocation.MarshalledValue was kept for legacy and serial compatibility.

This does not explain why RemotingMarshalledValue, etc. are not subclasses of MarshalledValue.

The code diffs between the current and previous MarshalledInvocation vs what would be required for using both the legacy MarshalledValue, and a new IMarshalledValue hardly seem worth having the IMarshalledValue class in the common module.

18. Re: Discussion of JBAS-2436

clebert.suconic Feb 21, 2006 6:12 PM (in response to clebert.suconic)

I forgot to say that another boundary I had was JBossRemoting coudln't depend on jboss-server.jar, as JBossRemoting can be used outside of JBoss context. JBossRemoting needed to be an external project without circular dependencies on Jboss/server.

I talked to Tom about adding that dependency when we were developing the initial Version of RemotingMarshalledValue, and this was the best design we have found on that time.

At the time I was working with Tom on this, we had several boundaries we jad to respect, and we tried to find the, as you said the lesser evil, not causing any harm.

But if I could add that dependency on remoting, I agree with you... I could use org.jboss.invocation.MarshalledValue as the Tag Interface.

19. Re: Discussion of JBAS-2436

starksm64 Feb 21, 2006 6:38 PM (in response to clebert.suconic)

The mistake was pushing the IMarshalledValue into the jboss-common.jar. Now we have a core interface in serialization/remoting coming from off this wall jar, in a seperate package, and generally loaded by a root class loader. All of this puts unnecessary constraints on the IMarshalledValue type usage. All of this seems to have been done to avoid have to have some duplicate code in the legacy org.jboss.invocation.* package. This is a poor tradeoff in my view.

The question now is whether this can be fixed. In order to do so the 1.4.x remoting branch would seem to be unusable. What I want to understand is what has to change to move IMarshalledValue into the org.jboss.remoting.serialization package, and remove the IMarshalledValue from the MarshalledValue.

20. Re: Discussion of JBAS-2436

clebert.suconic Feb 21, 2006 7:23 PM (in response to clebert.suconic)

All of this seems to have been done to avoid have to have some duplicate code in the legacy org.jboss.invocation.* package.

I've done this way not only because of that, but it looked a better design and it didn't break any serialization contract. I had the code working once (into my local copy) without the tagging interface, and the code looked pretty bad.

The question now is whether this can be fixed. In order to do so the 1.4.x remoting branch would seem to be unusable. What I want to understand is what has to change to move IMarshalledValue into the org.jboss.remoting.serialization package, and remove the IMarshalledValue from the MarshalledValue.

I - We would have to change SerializationManager to return an Object on createMarshalledValue.

II - We will need another jboss-remoting release.

III - Every place that IMarshalledValue is referenced into MarshalledInvocation, I will have to test what type is the object, as I don't have a tag interface any more. I actually had it once into my local copy, and I didn't like the code I had.

21. Re: Discussion of JBAS-2436

clebert.suconic Feb 27, 2006 12:43 PM (in response to clebert.suconic)

I just removed the dependency between MarshalledValue and IMarshalledValue.

On Marshalledinvocation I had to use Object on marshalledArgs and to test for its type every time. It wasn't as bad as I thought it would be.

I'm looking forward now to remove/deprected IMarshalledValue from commons and create one on JBossRemoting. I will be talking to Tom for when I would be able to include such thing in a JBossRemoting release.

22. Re: Discussion of JBAS-2436

clebert.suconic Feb 27, 2006 12:44 PM (in response to clebert.suconic)

Ah... I had created MarshalledValueEX, as I want to use the same streaming from MarshalledValue on JavaSerializationManager for UnifiedInvoker (in case using the legacy streaming).