might be cleaner indeed for the changelog On Thu, Jan 27, 2011 at 9:59 AM, Rainer Döbele <[email protected]> wrote: > 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. >
-- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house.
