Hey, Antonio. If I'm not mistaken, it shouldn't be absolutely necessary to have all your fields be serializable assuming your object implements the Serializable interface and your not using any persistent or remote caches. The Memory cache itself doesn't -actually- serialize anything; it only casts them to the Serializable interface. In practice it's a requirement to have everything in your object implement the Serializable interface ONLY if your actually serializing it (like with a disk, remote, or lateral cache). This is very bad practice, but if your willing to say 'I know it says it's serializable, and it implements the Serializable interface, but it's really not' and accept that kludge this may be your easiest option. I repeat, this is VERY bad form, but most likely you can get away with it.
If you absolutely cannot implement the Serializable interface (either through composition or extending), it's theoretically possible to change the interface from Serializable to Object in JCS, assuming your using only memory caches (no disk, no remote, no lateral), but this is -=highly ill advised=-. See further suggestions for better altertinatives. Assuming you need to use a Serializing cache like remote, disk, or lateral: You can mark all non serializable fields as 'transient', and have the object implement a 'restoreState()' feature which resets the value of those fields, which YOU call every time you get the object out of cache. 'restoreState()' would ensure that none of those fields are null. Marking them transient tells the Serializer not to serialize them. Taking the above suggestion a step further, you could implement the Memento pattern where a separate object which -can- be serialized contains the logic necessary to capture the state of your entity in a serializable way, and recreate it on demand. An 'I'm Feeling Lucky' Google pointed me here: http://www.dofactory.com/patterns/PatternMemento.aspx but further searches will reveal many more references I'm sure. Then you simply cache the Mementos. If your clever you'll wrap this in a Bridge or Adapter and save yourself the trouble of making/restoring from Mementos throughout your code. This, or the restoreState() solution is probably the one I'd implement myself, but all reasonable disclaimers apply: I am not an OO design God, your mileage may vary, use this advice at your own peril, other solutions may suit your needs better, I take no responsibility for your code or design decisions, implementation is left as an exercise to the reader, yadda yadda yadda, blah blah blah. Hope this helps. -Travis Savo <[EMAIL PROTECTED]> -----Original Message----- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 6:04 AM To: [EMAIL PROTECTED] Subject: Can the Transient cache store non Serializable objects. Hi: We are testing at Cocoon JCS. The actual tests are running well. But we have a question: Is posible to store in the Transient cache non-Serializable objects? We noted that o.a.jcs.access.CacheAccess.put() serialize the content of the Object. We needed to change an Object to allow it work with JCS: http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108479287011928&w=2 But now we have a problem: The class in question contains: 1) private Logger logger; /* from AbstractLogEnabled */ 2) private SourceResolver resolver; 3) private String systemId; 4) protected Map namespaceURIs = new HashMap(); 5) private ServiceManager manager; While 3 and 4 are Serializable, the rest is not. Now, please explain how fields 1, 2, and 5 will be de-serialized. We know the default Java behavior in this scenario is: they will be null. Next, imaging how those XSP pages we are testing will work when 1,2, and 5 are null. This problem is crucial for us. Please explain about that. Best Regards, Antonio Gallardo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
