We are actually using #2 in our production environment. I fix castor myself if it is not working. I check in these things 1. a version of working castor 2. schemas. I have to do it this way because our schemas are a standard and WILL be added to so it will change and I will need to regenerate and regenerate. What option you take below really depends on what you want. #2 could work in almost all circumstances. #1 can get you started but if you schemas change alot, you will be regenerating code again....mine as well use option #2 in that case. When I find bugs, I update castor and submit test cases and bug fixes to castor. Imagine if one developer from every company that uses castor submitted bug fixes. Stability to castor would come very quickly. Instead alot of people take approach #1 which is ok too. I am already down to one last bug I need to fix in castor for my stuff(list feature). I only need lots more test cases to make sure future development on castor doesn't break my stuff, so I can stay in synch with castor. Just my 2 cents, Dean
Ken Burcham wrote: >Kai, > > I've worked with generated source in production projects (even if not >so much with castor) and I would think there are two possible responses: > >1) Use the source generator as a way to get started. Then maintain the >schema/dtd+castormapping+javaobjects by hand thereafter, no longer >utilizing the source generator. > >2) Do not put any functionality aside from what the source generator >generates in the castor objects. Use them only for persistence so that >any bug fixes would be structural changes that would require updating >the schema/dtd and then source regeneration. > >Either way, you just don't want to be in a position where you ever >regenerate your source and then have to touch anything by hand. That's >when it starts getting expensive. Personally, since #2 never seems to >work right, #1 is where I usually land. > >Hth, > >ken. > >-----Original Message----- >From: Mai Kai Zhen [mailto:[EMAIL PROTECTED]] >Sent: Monday, January 06, 2003 5:42 AM >To: [EMAIL PROTECTED] >Subject: [castor-dev] how high is the cost of maintenence of castor xml >in real world? > >This is a rather general question. >I can see how java xml binding can save me time up front. I am >wondering >about the maintenence cost. > >People generate a set of classess from either schema or dtd to do >marshall >and unmarshall. Should the generated source files be put in source >control? >If there's a bug in the generated file, it should be fixed in source >control. >But later if castor is updated, and should the updated castor be used to > >generate source files? The bug fixes already made into an >organization's >source control need to be checked to see if the latest version of castor > >fixes those bugs already? >If later, the dtd or schema is updated(some elements are changed, new >elements are added), castor needs to be run to generate source files >from >the updated dtd or schema. Then the content of newly-generated files can >be >different from the existing files. Then the bug fixes to the existing >files need to be check to see if it's needed for the new files. > >I am wondering if this is how it's done in real world. >I am concerned that the cost I can save up front can be much less than >the >maintenence cost. Can I be better off writing my own classes to handle > >the java xml binding?(no, I don't mean writing a code generator. I mean > >using a parser to read XML and make some objects out of it, just like >the >generated classes). >I really need a quick response...... > >Thanks. >Kai > > > > > >_________________________________________________________________ >�������������ĵ����ʼ�ϵͳ�� MSN Hotmail�� http://www.hotmail.com > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
