Re: [castor-dev] Dependency on Xerces in Castor XML?
Great. In this case, Andrew, can you please create a new enhnacement request at http://bugzilla.exolab.org, and add myself to the CC list. It would be great of you could copy most of this conversation to the bug report as well, for completeness sake. Thanks Werner On Thu, 13 Jan 2005 15:07:13 -0600, Keith Visco wrote: > >Hey Andrew, > >I think it's a good idea, especially since more and more people don't >want to include the entire Xerces jar just to get the serialization >support required from Castor. I've been contemplating that for a long >time now, just never had the time to tackle it. It should be pretty >straight forward since the Castor Marshaller works with ContentHandler >and DocumentHandler primarily and only a very few lines of code actually >deal with the Serializer directly. The only thing the Serializer >abstraction needs to do is provide a way to set a few properties, such >as indentation (pretty printing), omiting the XML declaration at the >top, etc, and then returning a SAX ContentHandler or DocumentHandler >that Castor can marshal to, but I think you probably knew all that already. > >One thing that would be good also is if the Serializer can return a >LexicalHandler as well (it could be the same class that implements the >ContentHandler) for allowing us to Serialize CDATA sections and perhaps >even comments. > >We can then simply move the current code found in Configuration to a >Xerces specific implementation of the Castor Serializer (or whatever it >ends up being called) interface. > > >If you tackle this soon you'll just need to coordinate with Werner as >he's planning on doing a 0.9.6 release soon, so I think we need to wait >until after that release as to not introduce any last minute issues. > >In any case, +1 from me. > >--Keith > > > >Andrew Fawcett wrote: >> Hi, >> >> Currently the Configuration class allows the developer to provide an >> alternative serializer so long as its based on the Xerces Serializer >> interface. Since we at CODA are try to remove Xerces from our products >> and use the default JVM parser and serializer, having Castor locked into >> Xerces this way is kind of fly in the ointment. >> >> I was wondering what peoples thoughts where on abstracting Castor' >> serializer requirements into its own Serializer interface. The existing >> configuration property would then do a better job of allowing developers >> to then provide truly any serialiser they want. Of course default >> behaviour would be as it is now. So Castor would ship with a default >> implementation this new interface that works with Xerces. Thoughts? >> Anybody have any objections if I start to look into this within the next >> few weeks? >> >> Cheers, >> >> Andrew Fawcett >> "The Mad Brit" >> >> >> >> The information in this message is confidential and may be legally >> privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. >> >> >> >> >> >> --- >> 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
Re: [castor-dev] Dependency on Xerces in Castor XML?
Hey Andrew, I think it's a good idea, especially since more and more people don't want to include the entire Xerces jar just to get the serialization support required from Castor. I've been contemplating that for a long time now, just never had the time to tackle it. It should be pretty straight forward since the Castor Marshaller works with ContentHandler and DocumentHandler primarily and only a very few lines of code actually deal with the Serializer directly. The only thing the Serializer abstraction needs to do is provide a way to set a few properties, such as indentation (pretty printing), omiting the XML declaration at the top, etc, and then returning a SAX ContentHandler or DocumentHandler that Castor can marshal to, but I think you probably knew all that already. One thing that would be good also is if the Serializer can return a LexicalHandler as well (it could be the same class that implements the ContentHandler) for allowing us to Serialize CDATA sections and perhaps even comments. We can then simply move the current code found in Configuration to a Xerces specific implementation of the Castor Serializer (or whatever it ends up being called) interface. If you tackle this soon you'll just need to coordinate with Werner as he's planning on doing a 0.9.6 release soon, so I think we need to wait until after that release as to not introduce any last minute issues. In any case, +1 from me. --Keith Andrew Fawcett wrote: Hi, Currently the Configuration class allows the developer to provide an alternative serializer so long as its based on the Xerces Serializer interface. Since we at CODA are try to remove Xerces from our products and use the default JVM parser and serializer, having Castor locked into Xerces this way is kind of fly in the ointment. I was wondering what peoples thoughts where on abstracting Castor' serializer requirements into its own Serializer interface. The existing configuration property would then do a better job of allowing developers to then provide truly any serialiser they want. Of course default behaviour would be as it is now. So Castor would ship with a default implementation this new interface that works with Xerces. Thoughts? Anybody have any objections if I start to look into this within the next few weeks? Cheers, Andrew Fawcett "The Mad Brit" The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. --- 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
Re: [castor-dev] Dependency on Xerces in Castor XML?
Andrew, just wondering what XMl parser you might be using, as I'd like to have a brief look at its 'Serializer' interface. Can you please point me to some documentation ? Regards Werner On Thu, 13 Jan 2005 12:16:49 +0100, Werner Guttmann wrote: >Hi Fernando, > >there isn't a problem with Xerces per se, but (as stated by Andrew) there's >people out there that dislike Xerces for various reasons (speed, memory >footprint, etc.), and hence would want to use a different parser. > >Personally, I think that we should try to remove the Xerces dependency, but I >am not sure whether creating a new Serializer interface is the best was >forward. Let's hear what people like Keith have got to say ... > >Regards >Werner > >PS ! No HTML messages, please ! > >--Original Message Text--- >From: Fernando González Cortés >Date: Thu, 13 Jan 2005 11:33:13 +0100 > >I thing flexibility is great. > >I'm currently a develper of the gvSIG project which needs Castor as I need >air, ¿¿¿is there any problem with the Xerces??? > >cheers >Fernando González Cortés > gvSIG development team > http://www.gvsig.gva.es > IVER T.I. > Valencia - Spain > > >- Original Message - >From: Andrew Fawcett >To: castor-dev@exolab.org >Sent: Thursday, January 13, 2005 11:10 AM >Subject: [castor-dev] Dependency on Xerces in Castor XML? > > >Hi, > >Currently the Configuration class allows the developer to provide an >alternative serializer so long as its based on the Xerces Serializer >interface. Since >we at CODA are try to remove Xerces from our products and use the default JVM >parser and serializer, having Castor locked into Xerces this way is kind >of fly in the ointment. > >I was wondering what peoples thoughts where on abstracting Castor' serializer >requirements into its own Serializer interface. The existing configuration >property would then do a better job of allowing developers to then provide >truly any serialiser they want. Of course default behaviour would be as it is >now. So Castor would ship with a default implementation this new interface >that works with Xerces. Thoughts? Anybody have any objections if I start to >look into this within the next few weeks? > >Cheers, > >Andrew Fawcett >"The Mad Brit" > > > > >The information in this message is confidential and may be legally privileged. >It may not be disclosed to, or used by, anyone other than the addressee. If >you receive this message in error, please advise us immediately. > >Internet emails are not necessarily secure. CODA does not accept >responsibility for changes to any email which occur after the email has been >sent. >Attachments to this email may contain software viruses, which could damage >your systems. CODA has checked the attachments for viruses before >sending, but you should virus-check them before opening. > > > >--- >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
Re: [castor-dev] Dependency on Xerces in Castor XML?
Hi Fernando, there isn't a problem with Xerces per se, but (as stated by Andrew) there's people out there that dislike Xerces for various reasons (speed, memory footprint, etc.), and hence would want to use a different parser. Personally, I think that we should try to remove the Xerces dependency, but I am not sure whether creating a new Serializer interface is the best was forward. Let's hear what people like Keith have got to say ... Regards Werner PS ! No HTML messages, please ! --Original Message Text--- From: Fernando González Cortés Date: Thu, 13 Jan 2005 11:33:13 +0100 I thing flexibility is great. I'm currently a develper of the gvSIG project which needs Castor as I need air, ¿¿¿is there any problem with the Xerces??? cheers Fernando González Cortés gvSIG development team http://www.gvsig.gva.es IVER T.I. Valencia - Spain - Original Message - From: Andrew Fawcett To: castor-dev@exolab.org Sent: Thursday, January 13, 2005 11:10 AM Subject: [castor-dev] Dependency on Xerces in Castor XML? Hi, Currently the Configuration class allows the developer to provide an alternative serializer so long as its based on the Xerces Serializer interface. Since we at CODA are try to remove Xerces from our products and use the default JVM parser and serializer, having Castor locked into Xerces this way is kind of fly in the ointment. I was wondering what peoples thoughts where on abstracting Castor' serializer requirements into its own Serializer interface. The existing configuration property would then do a better job of allowing developers to then provide truly any serialiser they want. Of course default behaviour would be as it is now. So Castor would ship with a default implementation this new interface that works with Xerces. Thoughts? Anybody have any objections if I start to look into this within the next few weeks? Cheers, Andrew Fawcett "The Mad Brit" The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. --- 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
Re: [castor-dev] Dependency on Xerces in Castor XML?
I thing flexibility is great. I'm currently a develper of the gvSIG project which needs Castor as I need air, ¿¿¿is there any problem with the Xerces??? cheers Fernando González Cortés gvSIG development team http://www.gvsig.gva.es IVER T.I. Valencia - Spain - Original Message - From: Andrew Fawcett To: castor-dev@exolab.org Sent: Thursday, January 13, 2005 11:10 AM Subject: [castor-dev] Dependency on Xerces in Castor XML? Hi, Currently the Configuration class allows the developer to provide an alternative serializer so long as its based on the Xerces Serializer interface. Since we at CODA are try to remove Xerces from our products and use the default JVM parser and serializer, having Castor locked into Xerces this way is kind of fly in the ointment. I was wondering what peoples thoughts where on abstracting Castor' serializer requirements into its own Serializer interface. The existing configuration property would then do a better job of allowing developers to then provide truly any serialiser they want. Of course default behaviour would be as it is now. So Castor would ship with a default implementation this new interface that works with Xerces. Thoughts? Anybody have any objections if I start to look into this within the next few weeks? Cheers, Andrew Fawcett "The Mad Brit" The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately.Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. --- 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
