castor
  1. castor
  2. CASTOR-1934

gened call to XMLFieldDescriptorImpl cnstr not using FQCN in some cases, perhaps from imported schema

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.3.4
    • Component/s: XML code generator
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      Using snapshot 1.1.1-20070329.084439-9.

      I have a simple test case with two schemas, where one imports the other, and references an element defined in that schema. When I compile the code, I see the following exception:

      -----------------------
      .../wamu/xmlbinding/xx/descriptors/FooDescriptor.java:74: cannot resolve symbol
      symbol : class AccountProfile
      location: class wamu.xmlbinding.xx.descriptors.FooDescriptor
      desc = new org.exolab.castor.xml.util.XMLFieldDescriptorImpl(AccountProfile.class, "_accountProfile", "AccountProfile", org.exolab.castor.xml.NodeType.Element);
      -----------------------

      This compile error is happening because the reference of "AccountProfile.class" should be "wamu.xmlbinding.xx.AccountProfile.class". The class file exists, but it's not in the "descriptors" package, it's in the parent package.

      1. patch.c1934.20070430.txt
        1 kB
        Werner Guttmann

        Issue Links

          Activity

          Hide
          Werner Guttmann added a comment -

          Can you - for a second - turn off automatic naming collision resolution, and see whether the generated code compiles at all ?

          Show
          Werner Guttmann added a comment - Can you - for a second - turn off automatic naming collision resolution, and see whether the generated code compiles at all ?
          Hide
          Werner Guttmann added a comment -

          It looks like setting either a namespace to package mapping (or a schemaLocation to package mapping) should do the trick. Have a look at the builder properties file you provided. There is no namespace to package mapping for the namespace http://wamu.com/wmcs/das/aos/accountProfile. Once you add that, you should be fine.

          Show
          Werner Guttmann added a comment - It looks like setting either a namespace to package mapping (or a schemaLocation to package mapping) should do the trick. Have a look at the builder properties file you provided. There is no namespace to package mapping for the namespace http://wamu.com/wmcs/das/aos/accountProfile . Once you add that, you should be fine.
          Hide
          David M. Karr added a comment -

          Adding that line to the castorbuilder.properties file got around this problem.

          However, this seems like an odd way to resolve this problem.

          First, it seems odd to require this in the common castorbuilder.properties file. I had the impression that file was used for global settings of how Castor operates on your project. This means that I'll have to have a list of every namespace and package mapping referenced in every "castor-codegen" call, although I have a feeling this is only required for certain situations, not all (and I don't know what those conditions are). If required, it seems more natural to provide this information in the castor-codegen call.

          Second, this really needs some sort of diagnostic to detect that the mapping is required. Generating a compile error in generated code tells the developer nothing.

          Show
          David M. Karr added a comment - Adding that line to the castorbuilder.properties file got around this problem. However, this seems like an odd way to resolve this problem. First, it seems odd to require this in the common castorbuilder.properties file. I had the impression that file was used for global settings of how Castor operates on your project. This means that I'll have to have a list of every namespace and package mapping referenced in every "castor-codegen" call, although I have a feeling this is only required for certain situations, not all (and I don't know what those conditions are). If required, it seems more natural to provide this information in the castor-codegen call. Second, this really needs some sort of diagnostic to detect that the mapping is required. Generating a compile error in generated code tells the developer nothing.
          Hide
          Werner Guttmann added a comment -

          David, you can always use

          SourceGenerator.setNamespacePackageMapping(String, String)

          to set any namespace to package mapping 'programmatically' on the SourceGenerator instance you are using.

          About the 'error message', let me get back to you with some more thoughts later, okay ?

          Show
          Werner Guttmann added a comment - David, you can always use SourceGenerator.setNamespacePackageMapping(String, String) to set any namespace to package mapping 'programmatically' on the SourceGenerator instance you are using. About the 'error message', let me get back to you with some more thoughts later, okay ?
          Hide
          David M. Karr added a comment -

          How would I do that from the Ant task? I'm guessing that's not possible.

          My suggestion would be to have a new property on the ant task called "mappings", which would point to a file containing additional mappings to use for this instance.

          In a large project, the "castorbuilder.properties" file will be used at a global level. It's convenient to have a separate file at the subproject level, to specify mappings for related schemas. That's would be referenced in the "mappings" (or "nsmappings") property. This would either be a properties file, with one required single property, or a file assuming the syntax of the value of the current property.

          Concerning the error message, I can see how hard it would be to detect this situation. Imagine how hard it is for the developer, once they see that compile error.

          Show
          David M. Karr added a comment - How would I do that from the Ant task? I'm guessing that's not possible. My suggestion would be to have a new property on the ant task called "mappings", which would point to a file containing additional mappings to use for this instance. In a large project, the "castorbuilder.properties" file will be used at a global level. It's convenient to have a separate file at the subproject level, to specify mappings for related schemas. That's would be referenced in the "mappings" (or "nsmappings") property. This would either be a properties file, with one required single property, or a file assuming the syntax of the value of the current property. Concerning the error message, I can see how hard it would be to detect this situation. Imagine how hard it is for the developer, once they see that compile error.
          Hide
          Werner Guttmann added a comment -

          David, even when using Ant for triggering source code generation, there's the option to pass in custom.properties. In other words, the feature you are asking for is in place already. Unless you need two levels of builder properties ...

          Show
          Werner Guttmann added a comment - David, even when using Ant for triggering source code generation, there's the option to pass in custom.properties. In other words, the feature you are asking for is in place already. Unless you need two levels of builder properties ...
          Hide
          David M. Karr added a comment -

          The problem is that property (according to the doc) overrides the global castorbuilder.properties file, it doesn't add to it. So, every subproject that needs namespace mappings is going to have to get a separate copy of the entire castorbuilder.properties file, with one property changed, and everything else identical.

          I don't know what's worse, putting all the namespace bindings for all subprojects in the single castorbuilder.properties file, or cloning the file into every subproject with small changes. The latter is probably worse.

          Your "unless" at the end of your last comment hits the nail on the head.

          Show
          David M. Karr added a comment - The problem is that property (according to the doc) overrides the global castorbuilder.properties file, it doesn't add to it. So, every subproject that needs namespace mappings is going to have to get a separate copy of the entire castorbuilder.properties file, with one property changed, and everything else identical. I don't know what's worse, putting all the namespace bindings for all subprojects in the single castorbuilder.properties file, or cloning the file into every subproject with small changes. The latter is probably worse. Your "unless" at the end of your last comment hits the nail on the head.
          Hide
          David M. Karr added a comment -

          I'm going to attach a test case to this that demonstrates a similar problem, but I'm unable to fix this through appending to the "org.exolab.castor.builder.nspackages" property. I don't understand what I might be doing wrong.

          Show
          David M. Karr added a comment - I'm going to attach a test case to this that demonstrates a similar problem, but I'm unable to fix this through appending to the "org.exolab.castor.builder.nspackages" property. I don't understand what I might be doing wrong.
          Hide
          David M. Karr added a comment -

          After unpacking, put the latest 1.1.1 snapshot jars, along with commons-logging and xercesImpl into the "lib" directory, then do "ant anttask".

          I see the following errors so far:

          /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:361: cannot resolve symbol
          symbol : class AddressDetail
          location: class wamu.xmlbinding.consumer.descriptors.AddressTypeDescriptor
          desc = new org.exolab.castor.xml.util.XMLFieldDescriptorImpl(AddressDetail.class, "_addressDetail", "AddressDetail", org.exolab.castor.xml.NodeType.Element);
          ^
          /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:374: cannot resolve symbol
          symbol: class AddressDetail
          target.setAddressDetail( (AddressDetail) value);
          ^
          /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:380: cannot resolve symbol
          symbol: class AddressDetail
          return new AddressDetail();
          ^
          3 errors

          Show
          David M. Karr added a comment - After unpacking, put the latest 1.1.1 snapshot jars, along with commons-logging and xercesImpl into the "lib" directory, then do "ant anttask". I see the following errors so far: /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:361: cannot resolve symbol symbol : class AddressDetail location: class wamu.xmlbinding.consumer.descriptors.AddressTypeDescriptor desc = new org.exolab.castor.xml.util.XMLFieldDescriptorImpl(AddressDetail.class, "_addressDetail", "AddressDetail", org.exolab.castor.xml.NodeType.Element); ^ /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:374: cannot resolve symbol symbol: class AddressDetail target.setAddressDetail( (AddressDetail) value); ^ /home/u166705/work/castorbug2/gen/java/wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java:380: cannot resolve symbol symbol: class AddressDetail return new AddressDetail(); ^ 3 errors
          Hide
          Werner Guttmann added a comment -

          David, yes, you are right. In whatever way you use the (project/module local) property files, you'll end up overwriting previous namespace to package mappings (with the current code base). I honestly cannot (and would not be willing to give you a solution three days before a release), but I am more than willing to work with you on a long-term solution after 1.1.1 has been released.

          In other words, would it be acceptable to you to stick with the work-around for the time being ?

          Show
          Werner Guttmann added a comment - David, yes, you are right. In whatever way you use the (project/module local) property files, you'll end up overwriting previous namespace to package mappings (with the current code base). I honestly cannot (and would not be willing to give you a solution three days before a release), but I am more than willing to work with you on a long-term solution after 1.1.1 has been released. In other words, would it be acceptable to you to stick with the work-around for the time being ?
          Hide
          Werner Guttmann added a comment -

          Actually, are these schemas for which you are generating classes really completely unrelated ? 'Cause if not, iow if there's a common root schema, you might as well consider using the setGenerateImportedSchema(boolean) setter on the XML code generator.

          Show
          Werner Guttmann added a comment - Actually, are these schemas for which you are generating classes really completely unrelated ? 'Cause if not, iow if there's a common root schema, you might as well consider using the setGenerateImportedSchema(boolean) setter on the XML code generator.
          Hide
          Werner Guttmann added a comment -

          David, we (Steven and I) just confirmed that Castor XML is capable of picking up namespace to package mappings incrementally from three places:

          1) Default castorbuilder.properties (within the JAR).
          2) Project-specific castorbuilder.properties (at the root of the classpath)
          3) A custom property file as specified e.g. in the Ant config.

          In other words, at the end of calling setDefaultProperties(), we end up with the closure of all namespace to package mappings as defined in all three files. As almost always, I forgot that the project-specific castorbuilder.properties file must be rooted at the classpath, and as such cannot live in a package.

          I hope this clears things up a bit.

          Show
          Werner Guttmann added a comment - David, we (Steven and I) just confirmed that Castor XML is capable of picking up namespace to package mappings incrementally from three places: 1) Default castorbuilder.properties (within the JAR). 2) Project-specific castorbuilder.properties (at the root of the classpath) 3) A custom property file as specified e.g. in the Ant config. In other words, at the end of calling setDefaultProperties(), we end up with the closure of all namespace to package mappings as defined in all three files. As almost always, I forgot that the project-specific castorbuilder.properties file must be rooted at the classpath, and as such cannot live in a package. I hope this clears things up a bit.
          Hide
          David M. Karr added a comment -

          Let me try to address the last three comments:

          Would it be acceptable? Well, the workaround doesn't appear to work for me, but as I obviously don't have a support contract, I guess it would be acceptable .

          In the last test case I submitted, all of the schemas are related. I don't see the point of using the sGIS flag. It seems like just a convenience, not a strategy for avoiding the problem I'm having.

          When I'm running the code generator in the test case I submitted, there is only one castorbuilder.properties file.

          I think what would help me is if you were able to look at the second test case I submitted, and help me figure out how to adjust the properties file or the call to the ant task, to get the code to compile.

          Show
          David M. Karr added a comment - Let me try to address the last three comments: Would it be acceptable? Well, the workaround doesn't appear to work for me, but as I obviously don't have a support contract, I guess it would be acceptable . In the last test case I submitted, all of the schemas are related. I don't see the point of using the sGIS flag. It seems like just a convenience, not a strategy for avoiding the problem I'm having. When I'm running the code generator in the test case I submitted, there is only one castorbuilder.properties file. I think what would help me is if you were able to look at the second test case I submitted, and help me figure out how to adjust the properties file or the call to the ant task, to get the code to compile.
          Hide
          Werner Guttmann added a comment -

          David, I'll be defintely having a look at the second test case later on tonight. As I am not really keen to step out of my usual work environment , ''d appreciate some of your additional help. How much of a problem would it be if you remodelled your test case to comply with the guidelines for submitting bug reports. The attached test case you submitted does not make this easy. I'd appreciate if you supplied me with a JUnit test case that enabled me to run this relatively to src/bugs.

          Show
          Werner Guttmann added a comment - David, I'll be defintely having a look at the second test case later on tonight. As I am not really keen to step out of my usual work environment , ''d appreciate some of your additional help. How much of a problem would it be if you remodelled your test case to comply with the guidelines for submitting bug reports. The attached test case you submitted does not make this easy. I'd appreciate if you supplied me with a JUnit test case that enabled me to run this relatively to src/bugs.
          Hide
          David M. Karr added a comment -

          So you mean a pure java JUnit test case that calls the SourceGenerator directly, instead of using the Ant task? I guess that's feasible. I might not be done with it by tonight.

          Show
          David M. Karr added a comment - So you mean a pure java JUnit test case that calls the SourceGenerator directly, instead of using the Ant task? I guess that's feasible. I might not be done with it by tonight.
          Hide
          David M. Karr added a comment -

          Note that a JUnit test case is just going to generate the code, it's not going to compile it. Is there something that the JUnit test case can actually test for, as opposed to just calling SourceGeneratorMain 3 times?

          Show
          David M. Karr added a comment - Note that a JUnit test case is just going to generate the code, it's not going to compile it. Is there something that the JUnit test case can actually test for, as opposed to just calling SourceGeneratorMain 3 times?
          Hide
          David M. Karr added a comment -

          I'm trying to match the interface to SourceGeneratorMain to what I'm sending to the ant task, and I don't understand how to map my "properties" attribute (the custom properties file).

          Also, when I execute the "usage" for SourceGeneratorMain, it prints "-nameConflictStrategy " at the end, without an associated argument. I assume that's just a mistake in the usage message?

          Show
          David M. Karr added a comment - I'm trying to match the interface to SourceGeneratorMain to what I'm sending to the ant task, and I don't understand how to map my "properties" attribute (the custom properties file). Also, when I execute the "usage" for SourceGeneratorMain, it prints "-nameConflictStrategy " at the end, without an associated argument. I assume that's just a mistake in the usage message?
          Hide
          Ralf Joachim added a comment -

          David, how about marshaling/unmarshaling a sample document. Having said that I know that generated classes have to be compiled first for this to work. But at least this will allow Werner to create a test that can be integrated with our test suite.

          Show
          Ralf Joachim added a comment - David, how about marshaling/unmarshaling a sample document. Having said that I know that generated classes have to be compiled first for this to work. But at least this will allow Werner to create a test that can be integrated with our test suite.
          Hide
          David M. Karr added a comment -

          My issue is that the code that is generated does not compile. I can't build a test a test to demonstrate marshal/unmarshal because the code it would try to use does not compile.

          How about if my JUnit test case calls CastorCodeGenTask instead of SourceGeneratorMain? If it's feasible to do that, I think that will work. It still won't be compiling the generated source, but if you know what to look for in the results, it will make it easier for you to step through your code.

          Show
          David M. Karr added a comment - My issue is that the code that is generated does not compile. I can't build a test a test to demonstrate marshal/unmarshal because the code it would try to use does not compile. How about if my JUnit test case calls CastorCodeGenTask instead of SourceGeneratorMain? If it's feasible to do that, I think that will work. It still won't be compiling the generated source, but if you know what to look for in the results, it will make it easier for you to step through your code.
          Hide
          Werner Guttmann added a comment -

          Instead of calling SourceGeneratorMain, why not call SourceGenerator directly ? As that's exactly what SourceGeneratorMain does internally. Have a look at codegen/src/test/java/xml/generate/template for a sample test case.

          Show
          Werner Guttmann added a comment - Instead of calling SourceGeneratorMain, why not call SourceGenerator directly ? As that's exactly what SourceGeneratorMain does internally. Have a look at codegen/src/test/java/xml/generate/template for a sample test case.
          Hide
          David M. Karr added a comment -

          Ok, attached is a new test case that includes a JUnit test class that directly executes CastorCodeGenTask. I inspected the code it generates, and it still has the problem.

          The typical thing I check for in the generated code is whether the code in wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java references AddressDetail not as a FQCN.

          Show
          David M. Karr added a comment - Ok, attached is a new test case that includes a JUnit test class that directly executes CastorCodeGenTask. I inspected the code it generates, and it still has the problem. The typical thing I check for in the generated code is whether the code in wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java references AddressDetail not as a FQCN.
          Hide
          David M. Karr added a comment -

          Execute the JUnit test case and inspect the code in the wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java class. If it doesn't specify a FQCN for "AddressDetail", then it's still broken.

          Show
          David M. Karr added a comment - Execute the JUnit test case and inspect the code in the wamu/xmlbinding/consumer/descriptors/AddressTypeDescriptor.java class. If it doesn't specify a FQCN for "AddressDetail", then it's still broken.
          Hide
          David M. Karr added a comment -

          Werner, I just noticed your comment which came in after mine about the new test case. I assume it's still ok for my test case to execute CastorCodeGenTask directly, as opposed to SourceGenerator? It was easier for me to do it that way, since that maps directly to the test in my build.xml.

          Show
          David M. Karr added a comment - Werner, I just noticed your comment which came in after mine about the new test case. I assume it's still ok for my test case to execute CastorCodeGenTask directly, as opposed to SourceGenerator? It was easier for me to do it that way, since that maps directly to the test in my build.xml.
          Hide
          Werner Guttmann added a comment -

          Should not be a problem ... as far as I can tell.

          Show
          Werner Guttmann added a comment - Should not be a problem ... as far as I can tell.
          Hide
          Werner Guttmann added a comment -

          Allright, looks like I can now reproduce the problem. In other words, there's an AddressTypeDescriptor class that does not compile. Still have to get my head around as to why .....

          Show
          Werner Guttmann added a comment - Allright, looks like I can now reproduce the problem. In other words, there's an AddressTypeDescriptor class that does not compile. Still have to get my head around as to why .....
          Hide
          Werner Guttmann added a comment -

          Just looking into this a bit. It just occurred to me that there's two XML schemas that define an 'AddressType'' complex type, namely consumercrmtypes.xsd and crmtypes.xsd. And more surprisingly, these two schemas share the same target namespace. Is this design by intention ? I am not saying that I have found the problem, but somehow two schemas should not share the same target namespace, no ?

          Show
          Werner Guttmann added a comment - Just looking into this a bit. It just occurred to me that there's two XML schemas that define an 'AddressType'' complex type, namely consumercrmtypes.xsd and crmtypes.xsd. And more surprisingly, these two schemas share the same target namespace. Is this design by intention ? I am not saying that I have found the problem, but somehow two schemas should not share the same target namespace, no ?
          Hide
          David M. Karr added a comment -

          I think I had noticed that also. I didn't write these schemas, I'm just trying to build the application. I assume it's more likely a result of unplanned design, and merging of schemas from different areas. I'm not going to deny it's a mess, but I wouldn't expect that would cause this problem. If you can verify it is causing a problem, it would be good if a clear error condition could be created for this, so we know how to prevent it.

          Show
          David M. Karr added a comment - I think I had noticed that also. I didn't write these schemas, I'm just trying to build the application. I assume it's more likely a result of unplanned design, and merging of schemas from different areas. I'm not going to deny it's a mess, but I wouldn't expect that would cause this problem. If you can verify it is causing a problem, it would be good if a clear error condition could be created for this, so we know how to prevent it.
          Hide
          Werner Guttmann added a comment -

          One more observation: you are using elementFormDefault="unqualified" by intention, right ? Why am I asking this ? If you were to use elementFormDefault="qualified", the targetNameSpace would be (at least programmatically) associated with the addressDetail element, and hence it would carry a package as per the namespace to package definition.

          Show
          Werner Guttmann added a comment - One more observation: you are using elementFormDefault="unqualified" by intention, right ? Why am I asking this ? If you were to use elementFormDefault="qualified", the targetNameSpace would be (at least programmatically) associated with the addressDetail element, and hence it would carry a package as per the namespace to package definition.
          Hide
          Werner Guttmann added a comment -

          I just added an form="qualified" to the 'addressDetail' element within the complex type def for 'AddressType', and I don't get compilation errors any more.

          Show
          Werner Guttmann added a comment - I just added an form="qualified" to the 'addressDetail' element within the complex type def for 'AddressType', and I don't get compilation errors any more.
          Hide
          Werner Guttmann added a comment -

          David, it definitely has got nothing to do with the duplication of schemas as explained above. In this case, classes will be overwritten (whic migth cause different problems), but that's not the case here. It looks like the problem is with 'unqualification' of local elements.

          Show
          Werner Guttmann added a comment - David, it definitely has got nothing to do with the duplication of schemas as explained above. In this case, classes will be overwritten (whic migth cause different problems), but that's not the case here. It looks like the problem is with 'unqualification' of local elements.
          Hide
          David M. Karr added a comment -

          Just so I'm clear on this, changing anything from "unqualified" to "qualified" will change what XML documents will validate or marshal/unmarshal with the schema, correct? If that's the case, that's not a practical workaround for this.

          Show
          David M. Karr added a comment - Just so I'm clear on this, changing anything from "unqualified" to "qualified" will change what XML documents will validate or marshal/unmarshal with the schema, correct? If that's the case, that's not a practical workaround for this.
          Hide
          Werner Guttmann added a comment -

          David, I do remember that there is another (quite recent) bug that might be related to your problem. Let me check whether I can find it, and see whether they talk about the same problem.

          Show
          Werner Guttmann added a comment - David, I do remember that there is another (quite recent) bug that might be related to your problem. Let me check whether I can find it, and see whether they talk about the same problem.
          Hide
          Werner Guttmann added a comment -

          I think I now know as to why this ceased working when moving to Castor 1.1 M1. At that time, we started to separate the descriptor classes from the actual domain classes. With Castor 1.0.5, the code generated for the 'addressDetail' member does not have a package prefix either, but as the classes happen to be in the same package, this does not cause any harm. With our new layout (separate descriptor package, this of course does not work anymore).

          Which still does not answer the question as to what the correct solution should be ... ;-(.

          Show
          Werner Guttmann added a comment - I think I now know as to why this ceased working when moving to Castor 1.1 M1. At that time, we started to separate the descriptor classes from the actual domain classes. With Castor 1.0.5, the code generated for the 'addressDetail' member does not have a package prefix either, but as the classes happen to be in the same package, this does not cause any harm. With our new layout (separate descriptor package, this of course does not work anymore). Which still does not answer the question as to what the correct solution should be ... ;-(.
          Hide
          Werner Guttmann added a comment -

          Here's a theory. If a local element definition happens to be unqualified, i.e. it has not targetNamespace assigned (as e.g. the global type definitions of the same schema), we have to find a way to still come up with a package this class should be generated into. As it could happen that there's a namespace to package mapping for the complete schema namespace, somehw I think that this is the place where the class should be generated as well.

          Let's hope that this new logic does not break any additional code.

          Show
          Werner Guttmann added a comment - Here's a theory. If a local element definition happens to be unqualified, i.e. it has not targetNamespace assigned (as e.g. the global type definitions of the same schema), we have to find a way to still come up with a package this class should be generated into. As it could happen that there's a namespace to package mapping for the complete schema namespace, somehw I think that this is the place where the class should be generated as well. Let's hope that this new logic does not break any additional code.
          Hide
          Werner Guttmann added a comment -

          This is what I have in mind as a solution. I'd really appreciate feedback before committing myself to this.

          Show
          Werner Guttmann added a comment - This is what I have in mind as a solution. I'd really appreciate feedback before committing myself to this.
          Hide
          Werner Guttmann added a comment -

          David, are you in a position to build the binaries yourself (by any chances). Ideally, I'd love to provide you with a snapshot release, but somehow I am not really convinced to commit this to SVN trunk without some serious testing (on both sides).

          Show
          Werner Guttmann added a comment - David, are you in a position to build the binaries yourself (by any chances). Ideally, I'd love to provide you with a snapshot release, but somehow I am not really convinced to commit this to SVN trunk without some serious testing (on both sides).
          Hide
          David M. Karr added a comment -

          I'm sure it's possible for me to do it, but I've never done it, and I have two projects that have to take priority over this. If you could point me to the step-by-step instructions for doing this, that would help.

          Show
          David M. Karr added a comment - I'm sure it's possible for me to do it, but I've never done it, and I have two projects that have to take priority over this. If you could point me to the step-by-step instructions for doing this, that would help.
          Hide
          Werner Guttmann added a comment -

          Basically, we are talking about getting the latest sources from SVN, apply the patch and build the binaries yourself. If you are not really familiar with this and time is limited, I could try to upload a custom build to a selected area at Codehaus.

          Show
          Werner Guttmann added a comment - Basically, we are talking about getting the latest sources from SVN, apply the patch and build the binaries yourself. If you are not really familiar with this and time is limited, I could try to upload a custom build to a selected area at Codehaus.
          Hide
          David M. Karr added a comment -

          A possibly easier shortcut would be just dumping the source tree to a zip file and putting it on an ftp site. I can download that, apply the patch, and build it.

          Show
          David M. Karr added a comment - A possibly easier shortcut would be just dumping the source tree to a zip file and putting it on an ftp site. I can download that, apply the patch, and build it.
          Show
          Werner Guttmann added a comment - http://svn.castor.codehaus.org/browse/~tarball=zip/castor/castor/trunk/trunk.zip has a ZIP file of SVN trunk.
          Hide
          David M. Karr added a comment -

          I am proceeding with this. I've integrated the patch and built it, and now I'm stepping through the code. It didn't appear to work on the first try (no change in the result), so I'm making sure it's actually getting to the code you wrote.

          Show
          David M. Karr added a comment - I am proceeding with this. I've integrated the patch and built it, and now I'm stepping through the code. It didn't appear to work on the first try (no change in the result), so I'm making sure it's actually getting to the code you wrote.
          Hide
          David M. Karr added a comment -

          For a limited test case, I think I've resolved the issues with the generated package name. However, now I'm back to getting errors like this:

          [javac] Compiling 2420 source files to C:\p4ws\WS_u166705_AIS_2\EAI_weblogic\uia2_0707\subprojects\xmlbinding\target\classes
          /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/BorrowerType.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.consumer.CustomerType; attempting to use incompatible return type
          found : wamu.xmlbinding.loan.BorrowerType
          required: wamu.xmlbinding.consumer.CustomerType
          public static wamu.xmlbinding.loan.BorrowerType unmarshal(
          ^
          /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/Borrower.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.Borrower cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.consumer.CustomerType; attempting to use incompatible return type
          found : wamu.xmlbinding.loan.BorrowerType
          required: wamu.xmlbinding.consumer.CustomerType
          public static wamu.xmlbinding.loan.BorrowerType unmarshal(
          ^
          /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/Debtor.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.Debtor cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType; attempting to use incompatible return type
          found : wamu.xmlbinding.consumer.CustomerType
          required: wamu.xmlbinding.loan.BorrowerType
          public static wamu.xmlbinding.consumer.CustomerType unmarshal(
          ^
          /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/LoanListTypeCoBorrower.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.LoanListTypeCoBorrower cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType; attempting to use incompatible return type
          found : wamu.xmlbinding.consumer.CustomerType
          required: wamu.xmlbinding.loan.BorrowerType
          public static wamu.xmlbinding.consumer.CustomerType unmarshal(

          Show
          David M. Karr added a comment - For a limited test case, I think I've resolved the issues with the generated package name. However, now I'm back to getting errors like this: [javac] Compiling 2420 source files to C:\p4ws\WS_u166705_AIS_2\EAI_weblogic\uia2_0707\subprojects\xmlbinding\target\classes /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/BorrowerType.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.consumer.CustomerType; attempting to use incompatible return type found : wamu.xmlbinding.loan.BorrowerType required: wamu.xmlbinding.consumer.CustomerType public static wamu.xmlbinding.loan.BorrowerType unmarshal( ^ /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/Borrower.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.Borrower cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.consumer.CustomerType; attempting to use incompatible return type found : wamu.xmlbinding.loan.BorrowerType required: wamu.xmlbinding.consumer.CustomerType public static wamu.xmlbinding.loan.BorrowerType unmarshal( ^ /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/Debtor.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.Debtor cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType; attempting to use incompatible return type found : wamu.xmlbinding.consumer.CustomerType required: wamu.xmlbinding.loan.BorrowerType public static wamu.xmlbinding.consumer.CustomerType unmarshal( ^ /c/p4ws/WS_u166705_AIS_2/EAI_weblogic/uia2_0707/subprojects/xmlbinding/target/castor/src/wamu/xmlbinding/loan/LoanListTypeCoBorrower.java:97: unmarshal(java.io.Reader) in wamu.xmlbinding.loan.LoanListTypeCoBorrower cannot override unmarshal(java.io.Reader) in wamu.xmlbinding.loan.BorrowerType; attempting to use incompatible return type found : wamu.xmlbinding.consumer.CustomerType required: wamu.xmlbinding.loan.BorrowerType public static wamu.xmlbinding.consumer.CustomerType unmarshal(
          Hide
          Werner Guttmann added a comment -

          Which makes me wonder whether this is a result of the patch (like e.g. introducing a side effect), or whether these are genuine errors that you are seeing the first time. Having said that, can you please create a new issue and attach all relevant files, incl. XML schema(s), test case, etc.

          Please note that I still have to commit the suggested patch.

          Show
          Werner Guttmann added a comment - Which makes me wonder whether this is a result of the patch (like e.g. introducing a side effect), or whether these are genuine errors that you are seeing the first time. Having said that, can you please create a new issue and attach all relevant files, incl. XML schema(s), test case, etc. Please note that I still have to commit the suggested patch.
          Hide
          David M. Karr added a comment -

          I'm guessing this patch hasn't been applied yet? I tried using the latest 1.1.2 snapshot (5/6/07) and testing with it, and I realized it doesn't have the patch yet.

          Show
          David M. Karr added a comment - I'm guessing this patch hasn't been applied yet? I tried using the latest 1.1.2 snapshot (5/6/07) and testing with it, and I realized it doesn't have the patch yet.
          Hide
          Werner Guttmann added a comment -

          David, that's actually correct. I was waiting for feedback from another party, and I am now in a position to securely commit this patch with additional regression testing being performed for me .. ;.-).

          Having said that, this will have to wait for a few days, as I am spending nearly all my time in hospital after the birth of my daughter two days ago. Please bear with me for a few days .,,.

          Show
          Werner Guttmann added a comment - David, that's actually correct. I was waiting for feedback from another party, and I am now in a position to securely commit this patch with additional regression testing being performed for me .. ;.-). Having said that, this will have to wait for a few days, as I am spending nearly all my time in hospital after the birth of my daughter two days ago. Please bear with me for a few days .,,.
          Hide
          David M. Karr added a comment -

          Ah, well, then take as long as you want, then. No hurry. If you just notified me somehow when a new snapshot with this patch is available, that would be fine with me. Have fun.

          Show
          David M. Karr added a comment - Ah, well, then take as long as you want, then. No hurry. If you just notified me somehow when a new snapshot with this patch is available, that would be fine with me. Have fun.
          Hide
          Werner Guttmann added a comment -

          I have just attached a patch to CASTOR-1986 which I believe is superior than the one attached here. David, would you please be in a position to test the patch attached to CASTOR-1986 with this problem ? I'd appreciate any feedback, to be honest.

          Show
          Werner Guttmann added a comment - I have just attached a patch to CASTOR-1986 which I believe is superior than the one attached here. David, would you please be in a position to test the patch attached to CASTOR-1986 with this problem ? I'd appreciate any feedback, to be honest.
          Hide
          David M. Karr added a comment -

          I might have time to try this in a couple of days. However, I still don't have the capability to retrieve directly from SVN, so would you mind building a "trunk.zip", like you did before?

          Show
          David M. Karr added a comment - I might have time to try this in a couple of days. However, I still don't have the capability to retrieve directly from SVN, so would you mind building a "trunk.zip", like you did before?
          Hide
          Werner Guttmann added a comment -

          David, http://svn.castor.codehaus.org/browse/~tarball=zip/castor/castor/trunk/trunk.zip should give you what you are looking for. Please note that the patch for CASTOR-1968 has not been committed to SVN trunk yet, and thus needs to be applied manually.

          Show
          Werner Guttmann added a comment - David, http://svn.castor.codehaus.org/browse/~tarball=zip/castor/castor/trunk/trunk.zip should give you what you are looking for. Please note that the patch for CASTOR-1968 has not been committed to SVN trunk yet, and thus needs to be applied manually.
          Hide
          David M. Karr added a comment -

          I haven't gotten to the point of executing the compiled and generated classes, but all of my code generates and compiles without error now. I still think it's awkward to have to know to add namespace mapping entries when obscure compile errors happen. This isn't an issue when you're doing Castor work pretty often, but it sure causes problems when you don't know how to deal with it in the first place.

          Show
          David M. Karr added a comment - I haven't gotten to the point of executing the compiled and generated classes, but all of my code generates and compiles without error now. I still think it's awkward to have to know to add namespace mapping entries when obscure compile errors happen. This isn't an issue when you're doing Castor work pretty often, but it sure causes problems when you don't know how to deal with it in the first place.
          Hide
          Werner Guttmann added a comment -

          Looking into CASTOR-1864 again, it looks like CASTOR-1934 will have to be committed as well, as the problem Mattthias is encountering is not related to including/importing XML schemas at all. Having said that, I appreciate your patience, and I still believe that it should be possible to avoid those unnecessary namespace to package mappings once I have committed CASTOR-1986 and CASTOR-1934. Let's see how things go ...

          Show
          Werner Guttmann added a comment - Looking into CASTOR-1864 again, it looks like CASTOR-1934 will have to be committed as well, as the problem Mattthias is encountering is not related to including/importing XML schemas at all. Having said that, I appreciate your patience, and I still believe that it should be possible to avoid those unnecessary namespace to package mappings once I have committed CASTOR-1986 and CASTOR-1934 . Let's see how things go ...
          Hide
          Werner Guttmann added a comment -

          As I am about to commit the latest patch to this issue, I wonder whether the test case could be broken down to something more minimal, as I'd like to enhance the CTF test suite.

          Show
          Werner Guttmann added a comment - As I am about to commit the latest patch to this issue, I wonder whether the test case could be broken down to something more minimal, as I'd like to enhance the CTF test suite.
          Hide
          Matthias Hanisch added a comment -

          Sorry, I can only follow all the Castor development sproadically. Today, I tried again to run the castor generation on my testbed.
          This patch is still needed, otherwise it still generates classes from imported schema.
          So - in short - the facts didn't change in the last three months.

          Show
          Matthias Hanisch added a comment - Sorry, I can only follow all the Castor development sproadically. Today, I tried again to run the castor generation on my testbed. This patch is still needed, otherwise it still generates classes from imported schema. So - in short - the facts didn't change in the last three months.
          Hide
          Matthias Hanisch added a comment -

          Correction: the patch above does not work for Java enums. They are also generated in "package types;"
          Only old-style enums seem to be put into the package associated with the schema target namespace.

          Show
          Matthias Hanisch added a comment - Correction: the patch above does not work for Java enums. They are also generated in "package types;" Only old-style enums seem to be put into the package associated with the schema target namespace.
          Hide
          Matthias Hanisch added a comment -

          Correction again: even without the patch it seems to work with old-style enums so probably fixing CASTOR-1986 helped here.
          This patch seems to be outdated because it makes things worse for my other issue CASTOR-1881.
          Nevertheless, the real Java enums still have this problem.

          Show
          Matthias Hanisch added a comment - Correction again: even without the patch it seems to work with old-style enums so probably fixing CASTOR-1986 helped here. This patch seems to be outdated because it makes things worse for my other issue CASTOR-1881 . Nevertheless, the real Java enums still have this problem.

            People

            • Assignee:
              Werner Guttmann
              Reporter:
              David M. Karr
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: