Oops, I have just realized that I have already committed some changes on EMPIREDB-95, that have nothing to do with error handling. I missed that because it was assigned to 2.1.1 where the commits actually affected 2.1. and even should have gone to EMPIREDB-91 which I have just closed.
Francis what do you think. Should I revert my changes to the description of EMPIREDB-95, close it and create a new issue, or leave it as it is now? Regards Rainer Rainer Döbele wrote: > from: Rainer Döbele [mailto:[email protected]] > to: [email protected] > re: re: [jira] Updated: (EMPIREDB-97) Serialization of Empire-DB > objects > > Hi Francis, > > yes I myself have asked this question a while ago, whether we should > keep this old style error handling as an option. > Currently we can switch between Exception-mode and an exception-less > mode with Boolean return values for most functions to indicate an error. > > I agree that this exception-less mode is not really needed and I have no > problem getting rid of it and only do Exceptions in the future. However > it only makes sense if we also change the return values of most > functions and thus there is a lot to rethink an test - which means quite > a bit of work. > > I would suggest to leave it for now until we have finished our 2.1. > release. > This should then be a major task for a 2.2. release. > > I thought we have an issue for this already but could not find any. > I have now changed EMPIREDB-95 which was "Code cleanup and review" (did > quite mean anything) to "Remove optional support for old style error > handing". > > Regards > Rainer > > > Francis De Brabandere wrote: > > from: Francis De Brabandere [mailto:[email protected]] > > to: [email protected] > > re: Re: [jira] Updated: (EMPIREDB-97) Serialization of Empire-DB > > objects > > > > Rainer, > > > > We probably already had a discussion about this ErrorObject idea. I > > still see this as some kind of anti-pattern from old times where > > inheritance was the key to everything. > > > > Could you (again) explain me what the added value of this ErrorObject > > is (ignoring backwards compatibility)? I'll add that info to the wiki > > in case I forget once again or somebody else asks the same question. > > > > Cheers, > > Francis > > > > On Wed, Jan 26, 2011 at 11:36 PM, Rainer Döbele <[email protected]> > > wrote: > > > Hi Eike, > > > > > > I can follow your conclusion and agree that making ErrorObject > > serializeable makes no sense (why would anyone want to serialize an > > error anyway?), whereas serializing EmpireException is fine. > > > > > > I have not applied your patch yet (but I will do), but there is one > > more thing that came to my mind: > > > DBReader is not serializeable as it requires a reference to an open > > java.sql.ResultSet. > > > We have to make sure, that that a NotSerializeable exception is > > thrown, when attempting to serialize this class. > > > > > > Thanks and regards, > > > Rainer > > > > > > > > > Eike Kettner (JIRA) wrote: > > >> from: Eike Kettner (JIRA) [mailto:empire-db- > [email protected]] > > >> to: [email protected] > > >> re: [jira] Updated: (EMPIREDB-97) Serialization of Empire-DB > > >> objects > > >> > > >> > > >> [ https://issues.apache.org/jira/browse/EMPIREDB- > > >> 97?page=com.atlassian.jira.plugin.system.issuetabpanels:all- > tabpanel > > ] > > >> > > >> Eike Kettner updated EMPIREDB-97: > > >> --------------------------------- > > >> > > >> Attachment: 1_dbobject.patch > > >> 0_exception.patch > > >> > > >> Hi there, > > >> > > >> As I started working on the serialization thing, I figured that > it's > > >> not a good idea to let ErrorObject implement Serializable. Nearly > > every > > >> object extends ErrorObject and for some (and especially for objects > > to > > >> come) it is not desireable to be serializable. I think its not that > > >> good > > >> to open so many object for serialization. Then there are already > > >> classes > > >> that hold non-serializable references (I found XMLConfiguration to > be > > >> such a class). So, I think it could be a source of bugs to open > every > > >> object this way... > > >> > > >> The other side is, that ErrorObject uses a static ThreadLocal to > hold > > >> error info. This wouldn't be serialized anyways. This means > > >> EmpireException wouldn't be serializable even if ErrorObject > > implements > > >> Serializable. > > >> > > >> Instead I chose to serialize EmpireException by using a > serializable > > >> implementation of ErrorInfo. The major difference here: > > EmpireException > > >> does not hold a reference to the concrete object anymore, but only > a > > >> copy of the error infos. IMHO, this is good for an exception, but I > > >> have > > >> no glue to what extend users rely on EmpireException#getErrorObject > > to > > >> return a DBTable, XMLConfiguration etc. This is applied with the > > first > > >> patch. > > >> > > >> Then I chose to let DBObject implement Serializable. I think that > > it's > > >> nice if data model objects are serializable. Plain SQL strings are > > >> serializable and so I think objects like DBCommand or DBOrderByExpr > > >> (that represent parts of SQL) should be serializable, too :). This > is > > >> applied in the second patch. > > >> > > >> Regards, > > >> Eike > > >> > > >> > > >> > Serialization of Empire-DB objects > > >> > ---------------------------------- > > >> > > > >> > Key: EMPIREDB-97 > > >> > URL: > > https://issues.apache.org/jira/browse/EMPIREDB- > > >> 97 > > >> > Project: Empire-DB > > >> > Issue Type: Wish > > >> > Components: Core > > >> > Reporter: Eike Kettner > > >> > Attachments: 0_exception.patch, 1_dbobject.patch > > >> > > > >> > > > >> > Looking at class EmpireException, it holds references to two non- > > >> serializable objects: ErrorObject and ErrorType which breaks the > > >> contract with the Exception API. > > >> > Now, it would be great for several use-cases to have Empire-DB > > >> objects serializable. If ErrorObject would be serializable, it > would > > >> first make EmpireException serializable (assuming ErrorType to be > > >> serializable) and next it would make every other DBXyz object in > this > > >> hierarchy serializable. > > >> > Here is for reference the mail thread from users@ mailing list: > > >> > ------------------------------ > > >> > On Sat, Jan 22, 2011 at 7:26 PM, Eike Kettner <[email protected]> > > wrote: > > >> > > Hi Rainer and Francis, > > >> > > > > >> > > thanks for your quick replies and for giving this a chance. > > >> Serializing > > >> > > an exception is sure not something massive used, however > > sometimes > > >> it is > > >> > > quite a nice feature. For example, a JMSLogger sends log events > > to > > >> a > > >> > > broker, and there exceptions are serialized. Well, I see that > > this > > >> is > > >> > > not used often, and more or less a "special case" :). Still, I > > >> would > > >> > > consider a non-serializable exception a small "bug" - just > > because > > >> it's > > >> > > dictated by the java api. > > >> > > > > >> > > I had a quick look at the sources and as far as I can see, it > > >> should be > > >> > > ok to make "everything" serializable. There is always the > > >> > > "serializable-drawback" to consider: users can save objects on > > disk > > >> and > > >> > > later try to load them with a new version of empire-db, where > > class > > >> > > definitions have changed. Well, I think one can live with this, > > and > > >> it > > >> > > does not apply to many other use-cases of serialization (rmi, > > >> > > serialization used in wicket or messaging), because objects are > > >> > > serialized only for a short amount of time. > > >> > > > > >> > > Regards, > > >> > > Eike > > >> > > > > >> > > On [Sat, 22.01.2011 13:49], Rainer D=F6bele wrote: > > >> > >> Hi Eike, > > >> > >> > > >> > >> I agree with Francis that I don't quite see the point for > > >> serializing an Exception, although I must admit that > > >> java.lang.Throwable is Serializable. > > >> > >> > > >> > >> But then I agree that we should consider making DBObject or > > >> ErrorObject serializeable which then would apply to the entire > object > > >> hierarchy. > > >> > >> Regards > > >> > >> > > >> > >> Rainer > > >> > >> > > >> > >> > > >> > >> Francis De Brabandere wrote: > > >> > >> > from: Francis De Brabandere [mailto:[email protected]] > > >> > >> > to: [email protected] > > >> > >> > re: Re: Serialization of EmpireException > > >> > >> > > > >> > >> > Hi Eike, > > >> > >> > > > >> > >> > I see no reason for not making them Serializable. > > >> > >> > > > >> > >> > Rainer? > > >> > >> > > > >> > >> > Cheers, > > >> > >> > Francis > > >> > >> > > > >> > >> > On Fri, Jan 21, 2011 at 4:31 PM, Eike Kettner > <[email protected]> > > >> wrote: > > >> > >> > > > > >> > >> > > Hello, > > >> > >> > > > > >> > >> > > I was trying to serialize EmpireException but ran into an > > >> error. > > >> > >> > > EmpireException is marked as Serializable > (RuntimeException) > > >> > >> > > but it holds references to ErrorObject and ErrorType which > > are > > >> not > > >> > >> > > serializable. Hence a NotSerializableException is thrown. > > >> > >> > > > > >> > >> > > When asking this, I like to ask whether there is a thought > > >> about making > > >> > >> > > some model objects like DBRowset DBTable etc serializable. > > >> Since most or all > > >> > >> > > DBXyz objects hold model information only it should be > okay > > >> for them to > > >> > >> > > be serializable, imho? I use messaging and often Apache > > Wicket > > >> which > > >> > >> > > both use serialization, that's why I'm asking this. (For > > >> example, I'd > > >> > >> > > like to pass around where and order-by expressions). > > >> > >> > > > > >> > >> > > Kind Regards, > > >> > >> > > Eike > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > -- > > >> > >> > http://www.somatik.be > > >> > >> > Microsoft gives you windows, Linux gives you the whole > house. > > >> > >> > > >> > > > > >> > > >> -- > > >> This message is automatically generated by JIRA. > > >> - > > >> You can reply to this email to add a comment to the issue online. > > > > > > > > > > > > > > -- > > http://www.somatik.be > > Microsoft gives you windows, Linux gives you the whole house.
