|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Werner Guttmann - 24/May/07 04:36 AM
Are you using namespace to package mappings in any sense ?
I don't know what you mean.
The problem is that your code doesn't include a necessary import statement. To reproduce, do wget http://worldcatlibraries.org/registry/resolver/ResolverRecords.xsd (The second one is included via Then do and try compiling. It fails because you don't import ResolverRegistryEntry in ppp.descriptors.RecordsDescriptor.java Adding the -generateImportedSchemas flag to your first call of the source generator should do the trick, as this way Castor will be able to resolve imports as a result of imports/includes itself.
Thanks, I try that. Even if that works, it is still a bug in Castor that needs to be fixed.
Still doesn't work because imports are missing:
For instance: I'd be interested to know why you think this is a bug that needs to be fixed (ignoring your second reply for the time being). If a class A refers to class B (that is generated as a result of another XML schema), and that class is not generated at all or elsewhere (e.g. in a different package), I would not consider this to be a bug.
Having said that, I will have a look at your scenario.
Adding the following property to a custom builder property file
org.exolab.castor.builder.nspackages=\ resolves all compilation problems for me. Please note that I am running this against SVN trunk. Would you be willing to give this a try, using e.g. one of the 1.1.2 snapshot releases, e.g. the latest available. Please note that I agree that it should not be necessary to add a namespace to package mapping at all. But with the high number of (regression) issues being reported right now, I'd rather give you a work-around and have a look at this in more detail later on.
You're misdescribing the scenario. Could you just wget the two files, run the source generator, then compile it yourself while specifying a package name? The scenario is that "If a class A refers to class B (that is generated as a result of another XML schema), and that class is in fact generated with the same package prefix 'p.q.r', and if Castor fails to "import p.q.r.A;" when it generates the code for "p.q.r.descriptors.B", but still produces code that accesses 'A', rather than p.q.r.A, I would consider this a bug." Castor refers to a class ('ResolverRegistryEntry') in its code in a class in the descriptor.* subhierarchy, AND it does not use the fully qualified class name when doing so, nor does it import this class - this is incorrect, no matter how you look at it. I note that as I work-around, I'm running the source generator for both .xsd's, then use a simple sed script to place the missing import statement. The code compiles and runs.
I think there's no need to get upset here, Godmar. For what it's worth, I am spending an hour of my weekend to help you with your issue, and apparently I am not being paid for this work.
> Could you just wget the two files, run the source Which is exactly what I am doing, the only difference being that on the source generator, I am setting setGenerateImportedSchemas() to true, and I am using the custom property as shown above. With these two 'changes', I get code that compiles without any warnings/errors. In other words, using the setGenerateImportedSchemas() setter or not obviously makes a difference, and given the fact that your main XML schema imports/includes the other one, I'd suggest that you change your code generation strategy. That's basically all I am saying. which version are you using?
With Castor 1.1, and with setGenerateImportedSchemas given, I'm getting a new set of errors, posted above. (See the post "Still doesn't work because imports are missing:..." That said, it is incorrect for Castor to output code that it knows will not compile - because it doesn't follow the Java language specification - even if user error were to blame; Castor should output an error message instead. Your efforts are appreciated. I am running this against SVN trunk (which is almost identical to the latest 1.1.2 snapshot release). And even with 1.1.1, a few problems related to incorrect/missing import statements have been fixed. Would you be willing to try it with the latest 1.1.2 snapshot release ? In other words, it works for me, and there's no compilation errors.
ps: I don't know if this makes a difference, but I have boundproperties enabled in my castor build properties file. And keep in mind the issue occurs because a class defined in the main package directory needs to be explicitly import in classes defined in the descriptors/* subdirectory.
Are you saying the problems have been fixed between 1.1 and 1.1.1? I'm using 1.1
I'm hesitant to willy-nilly upgrade Castor, since different versions often change APIs and require debugging & fixes because of that, but if you know that this bug has been fixed there I'd do it. Godmar, I guess a minor release always tends to be a bug fix release only, where (mostly) regression issues are being addressed. And in the case of 1.1.1, we are mainly talking about issues that are a result of folks switching (for the first time ever) away from 0.9.x releases (which they have not been willing until the arrival of 1.1 - psychology at work). Let me reassure you that 1.1.1 is a bug fix release only. In addition, the release notes available at http://www.castor.org/release-notes.html
 clearly describe the scope of a release. In other words, we try to provide enough information (and a lot of time to create this information set) for you to come up with an educated decision whether to upgrade or not.
Having said that, yes, there have been some issues with this area, and yes, most of them have been fixed already (as it works on SVN trunk). I know for sure that CASTOR-1934 is one remaining issue which has not been committed yet, as I'd like to imprive the test scenarios for this particular one, but a patch has already been made available. And finally, can you please attach your custom builder property file to this issue, as clearly this is part of your working environment, which I'd like to reproduce. The more information I have, the better .., for obvious reasons. Having said that, I don't believe that enabling bound properties will actually make a difference. If I were you, I'd download 1.1.1, and test drive this scenario, If it fixes your problem, fine for you. I'd then subsequently read the release notes for 1.1.1 to see whether there's any potential changes that affect you (in a negative way). If 1.1.1 is not sufficient for your needs, I can offer you a snapshot release that is immutable and should cover your needs until we make 1.1.2 available publicly., PS And no, we do not change public APIs as we like, unless we are talking about a major release. And even then we use deprecation (sic!). Sorry, but there's loads of commercial grade users of Castor, and we simply cannot allow ourselves to be unprofessional. I read the changelog before I filed this bug report, and I didn't see this issue addressed. The issue persists in 1.1.1. To reproduce the issue, please run the following shell script:
mkdir castor (Adjust the -Djava.ext.dirs as necessary to include your commons logging facility.) The error msg is: ppp/descriptors/RecordsDescriptor.java:74: cannot find symbol To reproduce the failure of castor 1.1.1 when generateImportSchemas is given, please execute this shell script: — You'll again get numerous error msg. Run this script to implement your suggestion of setting org.exolab.castor.builder.nspackages: — — which yields errors such as: ps: if I specify the package 'ppp' in castorbuilder.properties instead of the magic 'xml.c1986.generated', it compiles.
If the nspackages directive in castorbuilder.properties is indeed necessary, castor should refuse to generate the .java file unless such as declaration is given, lest it knowingly generates code that does not conform to the JLS. pps: alternatively, a reasonable default assumption would be that the classes of the externally referred schema use the same package prefix (while still allowing nspackages in castorbuilder.properties to override them.) In either case, silently generating code that is known not to compile is wrong.
Godmar, above I have provided you with a work-around that enables you to use Castor without having to wait for a patch to be applied and a new release. And that gives me time to investigate things further .. at my personal pace. If you wanted this to be dealt with in a faster way, please consider taking up professional services. I hope you reckon that this is an open source project that relies on my (unpaid) contributions, contributions from all other committers and the community (potentially including you).
The namespace to package mapping should, indeed, not be required for your XML schemas to work. In other words, yes, there's most likely a bug. And we'll be looking at this. But by providing you with a work-around (using the nspackage directive as shown above), I tried to decrease dependencies for you. Hmm, something makes me think that the patch attached here is far cleaner than the one attached with CASTOR-1934.
Godmar, would you be able to attach a sample XML document that I could use to create a new regression test case for our internal test suite ? Once that has been attached, I am ready to commit the patch as is.
Please see the URLs already included above for sample documents.
Mayve I am blind, but I cannot find a URL for an XML document that happens to be a valid XML document that I could use for unmarshalling and that validates successfully against the given set of schemas.
If you need an XML document, rather than the XML schema, download http://worldcatlibraries.org/registry/lookup?IP=128.208.3.88
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
castor fails to include import statement for externally defined types
