David, my hope is that by the time a mix of the issues CASTOR-1934, CASTOR-1986 has been fixed and patches have been committed against SVN trunk, issues like this should not appear any more. But for the time being, I hope that using the nspackages property is a sufficient work-around for you.
Werner Karr, David wrote: > To answer my own question (unless there are better answers), what I did > was find the "castor-codegen" call that directly references the schema > that declares the element, take the "package" specified there, and add > an entry to "org.exolab.castor.builder.nspackages" in my > castorbuilder.properties file, mapping the declared schema to that > package. That gets me through those issues. > >> -----Original Message----- >> From: Karr, David >> Sent: Thursday, May 31, 2007 8:12 AM >> To: [email protected] >> Subject: [castor-user] Another case where a subtype fails to >> override the unmarshal method >> >> I'm using the latest code from SVN, including a patch for >> CASTOR-1986 (and indirectly CASTOR-1934). I have a >> relatively large test case, with dozens of schemas, most of >> them including other schemas. I'm using JDK 1.4.2. >> >> My current problem is something like what I've seen before, >> where a generated subtype fails to compile because of its >> "unmarshal" method, because it tries to return the current >> type, which conflicts with the definition in the supertype. >> >> Is there a general strategy for dealing with this, or do I >> have to build a test case for this to determine a solution? >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
