Hi Werner What I meant from my last question was why we are seeing these issues, is it a known bug that is has been rectified on the TRUNK or is the cause of the problem still unknown? Can you point me to the JIRA issue that has been logged against the problem?
Thanks Mike. -----Original Message----- From: Werner Guttmann [mailto:[email protected]] Sent: 16 April 2012 08:14 To: Mike Wood Cc: [email protected] Subject: Re: [castor-user] Failing to unmarshall Hi Mike, On 14.04.2012 08:38, Mike Wood wrote: > Hi Werner > >> From your response it sounds like you have seen the behaviour I have >> described in 1.3.2 and hence it is also unstable, please confirm? It is actually quite simple: there are some bug reports against Castor 1.3.2 that appear to report similar (if not the same) issues that have been looked into. > If so what version would you recommend we use? Can you please (re-)test with TRUNK, or a snapshot release of 1.3.3 ? > As mentioned I cannot recreate this problem in development, it only happens > in a live environment. > Can you explain why we are seeing these issues, configuration, setup a known > bug? Sorry, but that questions is not clear to me. What is it that you wanted to know ? Regards Werner > > Thanks > > Mike. > > -----Original Message----- > From: Werner Guttmann [mailto:[email protected]] > Sent: 03 April 2012 19:43 > To: [email protected] > Cc: Mike Wood > Subject: Re: [castor-user] Failing to unmarshall > > Hi Mike, > > can I please ask you to test against current TRUNK and report back your > findings ? I am suprised that you had those issues with 1.3.1 (when I would > have expected to see 1.3.2 mentioned here), but current trunk has seen a lot > of bug fixes applied. > > Kind Regards > Werner > > On 28.03.2012 14:37, Mike Wood wrote: >> Hello >> >> We have been using Castor for over 5 years on our product without any >> major issues. >> >> We recently upped version of Castor to 1.3.1 and have started to >> encounter issues when our application starts up then begins >> unmarshalling files. >> >> The sequence of events seems to be the same every time. >> >> The first failure reports this error... >> >> Failed to convert string to object: Nested error: >> org.exolab.castor.xml.MarshalException: White space is required >> between the processing instruction target and data.{File: [not available]; >> line: >> 1; column: 10} >> >> The second failure reports this error... >> >> Failed to convert string to object: Nested error: >> org.exolab.castor.xml.MarshalException: Content is not allowed in >> prolog.{File: [not available]; line: 1; column: 1} >> >> Then every single file the application tries to unmarshall results in >> this error... >> >> Failed to convert string to object: The class for the root element >> 'OUR_TO_ARP_File' could not be found. >> >> The application must be stopped and restarted to alleviate the situation. >> >> There is nothing wrong with any of the files we are asking Castor to >> unmarshall, they are well formed and if we restart the application it >> will unmarshall the files without issue. >> >> I have tried to recreate the sequence of events in a development >> environment as yet without success. >> >> I have even forced the first two errors by creating a file with >> random text before the declaration to force the 'Content not >> allowed..' error and by removing all of the spaces from the xml >> declaration in another file to force the 'White space...' error but >> subsequent files unmarshall without any problem. >> >> Does Castor go through some sort of initialisation process that may >> be failing to complete leading to the problems we are seeing or could >> someone suggest another reason this may be happening? >> >> Thanks >> >> Mike. >> > > ______________________________________________________________________ > __ This e-mail has been scanned for all viruses. > ______________________________________________________________________ > __ > ________________________________________________________________________ This e-mail has been scanned for all viruses. ________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
