From: Adrian B. <adr...@jb...> - 2005-11-15 21:10:11
|
You missed my point. We said don't do it, but you did it anyway. There was no update that these were non-issues that have been resolved. On Tue, 2005-11-15 at 15:44, Clebert Suconic wrote: > >1) This breaks serialization compatibility with earlier releases > > I made some tests with the actual version on the server and 4.0.3-sp1 on > the client, and it worked fine without any problems. Since the super > class doesn't have any attributes the serialization between versions > worked fine here. > > I'm going to make more tests on this anyway. And did you test it both ways? In all the possible places this is used? This code is pervasive. It is used on the client as well. Not to mention AOP (really common) and at least JBoss Cache having their own version. > > > >2) It introduces spurious dependencies of projects on remoting > > I need that dependency as pluggable serialization needs a super class on > MarshalledValue. (How can I swap between JavaSerialization and > JbossSerialization on MarshalledValues without a super class for the > implementation?) > You do it by using a correct abstraction. That means interfaces/contracts, not I'll just squeeze my kludge here. Why is the serialization implementation an issue that belongs in remoting anyway? e.g. Tomcat now has to depend on the JBoss Remoting version? Tomcat Caching -> MarshalledValue -> JBoss Remoting How does somebody else use this? Without dragging in 10,000 (exaggeration) other jars scattered across JBoss CVS at unknown versions? I'm very suspicious that once this new door has been opened the bloat dependency problem is going to get even worse. http://jira.jboss.com/jira/browse/JBAS-1796 > > > 3) Ever here of changing implementation details based on > factories and interfaces? > > I have some changes sitting on my local copy, waiting for the next > release of JBossRemoting that will use factories and interfaces. > If you look at some commits I made yesterday by accident > (org.jboss.invocation.InvokerInterceptor version 1.5.6.6) you are going > to see the interfaces we are going to use) These interfaces are actually > on JBossRemoting, and that's why we have the dependencies on the > extension. > > The best idea we had for this was to put the interface into Remoting, > what we (I and Telrod) thought it would be the best design. Do you have > any other idea for pluggable serialization on MarshalledValues? > Plugging in an ObjectStream is not an issue for Remoting. I don't want to see dependencies on JBoss Remoting when all somebody wants to do is have serialization that understands context classloading. Remoting has an extra requirement (remote classloading) where it needs to add further behaviour. But this is the not the default and it is a different issue. > Cheers, > > > Clebert > > > -----Original Message----- > From: jbo...@li... > [mailto:jbo...@li...] On Behalf Of > Adrian Brock > Sent: Tuesday, November 15, 2005 1:03 PM > To: jbo...@li... > Subject: RE: [JBoss-dev] Call optimization caution > > So this change has been made anyway???!!!??? > > " > package org.jboss.invocation; > > public class MarshalledValue extends RemotingMarshalledValue > implements java.io.Externalizable > " > > 1) This breaks serialization compatibility with earlier releases > 2) It introduces spurious dependencies of projects on remoting > 3) Ever here of changing implementation details based on > factories and interfaces? > > - MarshalledValue value = new MarshalledValue(object); > + IMarshalledValue value = > marshalledValueFactory.getMarshalledValue(object); > > Then somebody can choose to use old or new. > > On Fri, 2005-09-23 at 17:41, Scott M Stark wrote: > > We can introduce pluggable streams into the legacy invokers, but this > is > > an incompatible change since the manager or hooks do not exist in the > > legacy client. All that can be done is to have a per invoker > deployment > > configuration that allows for either backward compatibility, or the > > pluggable behavior. The general problem I'm seeing is a lack of > planning > > with regard to evolution of the component. > > The more general problem is lack of discussion/notification. > And when there is discussion, it is ignored! > > > I'm just saying we don't > > want to make the same mistake in the next generation of frameworks. > > > > > -----Original Message----- > > > From: jbo...@li... > > > [mailto:jbo...@li...] On > > > Behalf Of Clebert Suconic > > > Sent: Friday, September 23, 2005 1:59 PM > > > To: jbo...@li... > > > Subject: RE: [JBoss-dev] Call optimization caution > > > > > > Also, > > > > > > After finished pluggable serialization I will resume working on > > > http://jira.jboss.org/jira/browse/JBAS-1598 so I will be able > > > to check my own modification if they are still compatible. > > > > > > > > > > > > Clebert > > > -----Original Message----- > > > From: jbo...@li... > > > [mailto:jbo...@li...] On > > > Behalf Of Clebert Suconic > > > Sent: Friday, September 23, 2005 3:47 PM > > > To: jbo...@li... > > > Subject: RE: [JBoss-dev] Call optimization caution > > > > > > We are implementing the concept of Pluggable serialization, > > > but we are doing everything through remoting/UnifiedInvokers only. > > > The basic idea until now was to keep PooledInvoker and JRMP > > > untouched so it would be compatible with older versions in my > opinion. > > > The only change I will be doing is to have > > > org.jboss.server.invocation MarshalledValue extending > > > RemotingMarshalledValue as it was needed a super class for he > factory. > > > > > > Maybe we could also implement PooledInvokers using Pluggable > > > serialization and provide a SerializationManager compatible > > > with the SerializationManager being used on 4.0.2 to fix JBAS-2267. > > > > > > What you think? > > > > > > > > > Clebert > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > Download > > it for free - -and be entered to win a 42" plasma tv or your very own > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > JBoss-Development mailing list > > JBo...@li... > > https://lists.sourceforge.net/lists/listinfo/jboss-development -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |