Greg, see my reply in CASTOR-1102 ... and I am on IRC, if you fancy .. ;-).
Werner -----Ursprüngliche Nachricht----- Von: Gregory Block [mailto:[EMAIL PROTECTED] Gesendet: Montag, 01. August 2005 12:58 An: [email protected] Betreff: Re: AW: [castor-user] Missing serialVersionUID in Castor generated classes? See my response. :) We just moved to ehcache here; I wasn't happy with OSCache performance or semantics; I'll look at changing back to it if/when they release OSCache 3.0, which is intended to get rid of the exception-throws on cache miss or cache expired, and the resulting synchronization they implement (it's just not appropriate in our environment) As for FKCache... Ugh. What a mess. Which version is the API built against? They're in the middle of changing their API implementation, and the current TOT's lost total control over programmatically building caches, which I'm not keen on. IMO: Mark FKCache as being based on an API seriously in flux in documentation - I suspect the API is going to continue to go under radical change, if indeed it ever gets updated; in its current state, it's a mess. OSCache is a good solid cache API, and JCS may be slow but it is relatively common. Neither of them, however, are used in my environment - I've just moved our local implementation of the expiration system to the ehcache build. (Which reminds me, I need to get around to building a hashbelt implementation of our existing cache API for those who want a faster cache that doesn't rely on external libs) On 1 Aug 2005, at 10:55, Werner Guttmann wrote: > Greg, > > if you could still ctrl-1 through some of these couurences, that > would be great. I agree on the subject of the generated classes, so > let's create a new issue at http://jira.codehaus.org/browse/CASTOR > and let#s assign it to the XML sub-project. > > Thanks > Werner > > PS Speaking of which, fancy testing some distributed caches ... ;-) ? > > -----Ursprüngliche Nachricht----- > Von: Gregory Block [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 01. August 2005 11:36 > An: [email protected] > Betreff: Re: [castor-user] Missing serialVersionUID in Castor > generated > classes? > > > Yeah, at some point, I'll go through andn cmd-1 some UIDs into those > in Eclipse; won't really solve the big problem, tho, which is that > Castor's own classes should (IMO) generate code that obeys the basic > rules for UIDs in classes - that two classes which serialize to the > same representation should have the same UID, to ensure that > serialized versions can be loaded in. > > That's going to become a *lot* more valuable once people start using > serializable caches, and people start trying to upgrade live > applications running distributed caching, possibly with persistent > disk caches, on their live services - who may suddenly find that the > entire live service contains a set of cached information which simply > isn't readable anymore for no reason other than that they simply > recompiled their app. > > On 26 Jul 2005, at 20:38, Werner Guttmann wrote: > > >> Greg, >> >> I wasn't particularly referring to generated classes per se. It >> just occurred to me - when replying - that there actually is a lot >> of classes out there in src codebase that are Serializable, but >> don't carry a UID. >> >> Werner >> >> On Tue, 26 Jul 2005 12:25:16 +0100, Gregory Block wrote: >> >> >> >>> In the code generator? I'm not so keen on changing things I don't >>> actually use in my projects - and code generation pretty much falls >>> at the bottom of the list of things I might ever want to use. :) >>> >>> Code generator *should* generate UIDs; that it does not is no better >>> or worse than generating code that generates lots of warnings... >>> but >>> in order for Code Generator to generate those UIDs, there's one >>> fundamental question worth asking: >>> >>> >>> Should CG always generate the same UID for a given list of fields, >>> types, and orders? In other words, should re-generating the exact >>> same schema result in the same UIDs? If people have a build process >>> that involves every clean build in completely re-generating those >>> classes, then they will essentially break their own serialization >>> with every major version. >>> >>> >>> Answer, IMO: YES. This means that UID generation won't resemble >>> Java's own mechanism, but will generate a long based on (probably) a >>> hash of the class name, package name, field member types, and field >>> names, in order. Changes which would not result in a change to the >>> hash will not get recognized; this would, however, mean that UIDs >>> will be based on the actual fields present in the XML, and XML >>> changes will auto-modify the UID to break serialization on that >>> class. >>> >>> Downside: Well, XML changes auto-modifying the UID sound awful, >>> because it means you can't manually handle that change in serialized >>> form and provide an implementation for de-serializing old serialized >>> versions of a class; on the other hand, these are *generated* >>> classes; if you wanted manual control, you shouldn't have generated >>> in the first place. >>> >>> Downside: Unless the UID generation also includes some version >>> information from Castor, later versions of castor, which may >>> generate >>> code differently, will not break that UID. Arguably, the castor >>> build or version number should be included in UID generation hash. >>> >>> >>> As for doing it the way Eclipse does: Eclipse compiles the class, >>> runs the JVM to generate the serial version UID, and then inserts >>> the >>> serial version UID back into the Java source. This is doable if, >>> for >>> example, you would like to include a dependency on the Eclipse java >>> compiler with Castor - at which point, we can then take the source >>> code, compile it, run java, and then using the AST tree that >>> Eclipse's compiler provides, insert the correct node into the tree, >>> resave the AST tree as java source on the disk, and continue. >>> >>> Whether or not the Castor developers wish to reconstruct their >>> source >>> generator on Eclipse AST trees is, of course, debateable. :) OTOH, >>> it works just fine for the Tomcat folks. >>> >>> On 24 Jul 2005, at 21:24, Werner Guttmann wrote: >>> >>> >>> >>>> Mind supplying us with a patch .. ;-) ? Given that Eclipse has some >>>> nice >>>> quick fixs in this area, this should not be too hard to achieve. >>>> >>>> >>> >>> >>> ------------------------------------------------- >>> If you wish to unsubscribe from this list, please >>> send an empty message to the following address: >>> >>> [EMAIL PROTECTED] >>> ------------------------------------------------- >>> >>> >>> >> >> >> >> >> >> ------------------------------------------------- >> If you wish to unsubscribe from this list, please >> send an empty message to the following address: >> >> [EMAIL PROTECTED] >> ------------------------------------------------- >> >> >> > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
