In response to your blog: There is nothing that requires the component to re-initialize a field that has been marked as transient. If the component requires a field to be set that hasn't been it also has the option to throw a Runtime Exception.
My main point when I proposed using transient as part of a solution to the serialization problem was that a component HAS TO assume something about what is available from its deployment environment (its container). Type 3 IoC is a very lightweight approach that encapsulates that knowledge in the ctor. This breaks many standard Java usages (not a JB, can't be serialized). My proposal encapsulates that knowledge in xDoclet comments and the use and management of the transient keyword. Either one of these approaches is amenable to code-generation solutions to allow the component to be adapted for use in an arbitrary framework. Only one of them allows the generated components to easily integrate into other environments. i.e. JavaBean support is everywhere. > -----Original Message----- > From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] > Sent: Friday, July 11, 2003 8:56 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [OS-webwork] Xwork IoC requirements > > > Jason, > > Read my weblog issue on this: > > http://blogs.atlassian.com/scuttlebutt/ > > Cheers, > Mathias > ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
