castor
  1. castor
  2. CASTOR-1875

When SourceGenerator doesn't omit warnings, it hangs build waiting for confirmation

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: XML code generator
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      2

      Description

      If you set SourceGenerator to NOT omit warnings (using the odd notion of setting "warnings" to "true"), and it's used in a normal build situation where the castor process is forked, the SourceGenerator will wait for input confirming whether to continue or not, even BEFORE printing the warning. In this situation, the build is hung, and will not complete. If the build is run from the command line on a console, and the user pressed ^C at this point, the forked process spins away, creating even more confusion.

      In general, I'd say there's not much point in prompting for whether to continue or not. A warning is a warning. It should always continue on. If the generated code is broken, it won't compile. At least printing the warning gives me more information about what's wrong.

      if there's a desire to not change existing behavior, then add another command-line option, like "-continue", to indicate to always continue on warnings. The doc for this should recommend using that flag in anything but a pure direct command-line execution of the SourceGenerator (just about the only situation where prompting can be of any use).

      Just in case, I'll attach a zip file containing my Ant build file, properties file, and the xsd I'm trying to process.

      1. patch.c1875.20070221.txt
        2 kB
        Werner Guttmann

        Activity

        Hide
        Werner Guttmann added a comment -

        David, can you please try to set the nameConflictStrategy to "informViaLog", as this will avoid prompting for any input and simply just report any conflicts.

        Show
        Werner Guttmann added a comment - David, can you please try to set the nameConflictStrategy to "informViaLog", as this will avoid prompting for any input and simply just report any conflicts.
        Hide
        Werner Guttmann added a comment -

        If this does not help, I'll have a more detailed look at this your problem tomorrow.

        Show
        Werner Guttmann added a comment - If this does not help, I'll have a more detailed look at this your problem tomorrow.
        Hide
        Werner Guttmann added a comment -

        Btw, by setting the name conflict strategy, I refer to the setNameConflictStrategy() method on the SourceGenerator.

        Show
        Werner Guttmann added a comment - Btw, by setting the name conflict strategy, I refer to the setNameConflictStrategy() method on the SourceGenerator.
        Hide
        David M. Karr added a comment -

        If the only way to change this is to call a method on SourceGenerator, I don't see how I can do this. If there's no way to set this through properties, Ant, or Maven, then I don't think it helps me any.

        In any case, I can live with it like this for now, as I really just need to focus on fixing the conflicts in the binding file (so I have to figure out why my bindings don't appear to help). My hand-built Ant script to call the SourceGenerator lets me see what the conflicts are, as long as I run it interactively.

        Show
        David M. Karr added a comment - If the only way to change this is to call a method on SourceGenerator, I don't see how I can do this. If there's no way to set this through properties, Ant, or Maven, then I don't think it helps me any. In any case, I can live with it like this for now, as I really just need to focus on fixing the conflicts in the binding file (so I have to figure out why my bindings don't appear to help). My hand-built Ant script to call the SourceGenerator lets me see what the conflicts are, as long as I run it interactively.
        Hide
        Werner Guttmann added a comment -

        David, a few days ago I just checked in a small enhancement to the Ant task for the XML code generator that adds a property that allows you to set the name conflict strategy. I definitely will try to get the Castor Maven plugin adapted as well.

        With the patch available on SVN trunk, you could either build the sources yourself, or wait one or two more days for me to release a new snapshot release of Castor 1.1.1.

        Show
        Werner Guttmann added a comment - David, a few days ago I just checked in a small enhancement to the Ant task for the XML code generator that adds a property that allows you to set the name conflict strategy. I definitely will try to get the Castor Maven plugin adapted as well. With the patch available on SVN trunk, you could either build the sources yourself, or wait one or two more days for me to release a new snapshot release of Castor 1.1.1.
        Hide
        Werner Guttmann added a comment -

        Given that there's an addition to the Ant task def for the XML code generator, can I assume that it is safe to mark this as resolved ?

        Show
        Werner Guttmann added a comment - Given that there's an addition to the Ant task def for the XML code generator, can I assume that it is safe to mark this as resolved ?
        Hide
        David M. Karr added a comment -

        Perhaps. What does "informViaLog" do? If that is set, will you see the warnings in stdout, along with the messages about "Creating classes for: ..."?

        Related to this, is it possible to conceive of a situation where a class name generation conflict can really be considered a warning, and not a fatal error?

        Show
        David M. Karr added a comment - Perhaps. What does "informViaLog" do? If that is set, will you see the warnings in stdout, along with the messages about "Creating classes for: ..."? Related to this, is it possible to conceive of a situation where a class name generation conflict can really be considered a warning, and not a fatal error?
        Hide
        Werner Guttmann added a comment -

        David, unlike the default name conflict resolution strategy ("warnViaConsoleDialog"), this strategy simply logs all name conflicts occurring during source code generation to a Jakarta commons-logging logger (and thus, if used, an underlying e.g. Log4J logger). Iow, set the "informViaLog", configure your logger accordingly and you'll be able to spot where conflicts occurred after the complete generation run.

        I am not sure about the "Creating class for: " messages, to be honest, but I guess if they are reported to stdout now, they will remain there (as this code area has not been touched yet).

        And now to your last question: yes, there's situations where a (locally) defined element of name x, defined in two different complexType definitions X and Y, will lead to situation where the fact that the class is overwritten is harmless, namely when X/x and Y/x are of the same type.

        A lot of my time of the last three weeks has gone into a new feature made available as part of 1.1.1 (snapshot), where an automatic naming collision resolution mechanism has been added that renders the use of a binding file (to avoid naming collisions, that is) almost obsolete.

        I hope this answers your questions.

        Show
        Werner Guttmann added a comment - David, unlike the default name conflict resolution strategy ("warnViaConsoleDialog"), this strategy simply logs all name conflicts occurring during source code generation to a Jakarta commons-logging logger (and thus, if used, an underlying e.g. Log4J logger). Iow, set the "informViaLog", configure your logger accordingly and you'll be able to spot where conflicts occurred after the complete generation run. I am not sure about the "Creating class for: " messages, to be honest, but I guess if they are reported to stdout now, they will remain there (as this code area has not been touched yet). And now to your last question: yes, there's situations where a (locally) defined element of name x, defined in two different complexType definitions X and Y, will lead to situation where the fact that the class is overwritten is harmless, namely when X/x and Y/x are of the same type. A lot of my time of the last three weeks has gone into a new feature made available as part of 1.1.1 (snapshot), where an automatic naming collision resolution mechanism has been added that renders the use of a binding file (to avoid naming collisions, that is) almost obsolete. I hope this answers your questions.
        Hide
        David M. Karr added a comment -

        Oh. NOW I understand what you mean by automatic conflict resolution. And I had just finished posting another note to castor-user asking whether I really need to create a gazillion elementBinding elements.

        Is 1.1.1 available yet for me to try to use? If it's not available in a release yet, will I have to pull it from SVN?

        Show
        David M. Karr added a comment - Oh. NOW I understand what you mean by automatic conflict resolution. And I had just finished posting another note to castor-user asking whether I really need to create a gazillion elementBinding elements. Is 1.1.1 available yet for me to try to use? If it's not available in a release yet, will I have to pull it from SVN?
        Hide
        Werner Guttmann added a comment -

        http://snapshots.repository.codehaus.org/org/codehaus/castor/ is your friend. Please look for the latest 1.1.1 release.

        Show
        Werner Guttmann added a comment - http://snapshots.repository.codehaus.org/org/codehaus/castor/ is your friend. Please look for the latest 1.1.1 release.
        Hide
        Werner Guttmann added a comment -

        But please do consider the changelog since 1.1 has been released already to get an idea whether you might want to build JARs yourself (from SVN). Alternatively, I could make a new snapshot release available later today.

        Show
        Werner Guttmann added a comment - But please do consider the changelog since 1.1 has been released already to get an idea whether you might want to build JARs yourself (from SVN). Alternatively, I could make a new snapshot release available later today.
        Hide
        David M. Karr added a comment -

        I just installed the jars from the 1.1.1 (20070212.085814-2) snapshot, changed my classpath to point to them, removed the "bindingfile" parameter in my Ant task call, and reran my test. The first warning I get is the same as I got with 1.1, before I started adding elementBinding elements to the binding file. Is that surprising?

        When you refer to "informViaLog" and "warnViaConsoleDialog", you're calling that the "name conflict resolution strategy", right? Shouldn't that be "reporting", not "resolution"? Are there values of that field that actually have something to do with "resolving" the conflict (perhaps the "automatic" strategy you've been referring to)?

        Show
        David M. Karr added a comment - I just installed the jars from the 1.1.1 (20070212.085814-2) snapshot, changed my classpath to point to them, removed the "bindingfile" parameter in my Ant task call, and reran my test. The first warning I get is the same as I got with 1.1, before I started adding elementBinding elements to the binding file. Is that surprising? When you refer to "informViaLog" and "warnViaConsoleDialog", you're calling that the "name conflict resolution strategy", right? Shouldn't that be "reporting", not "resolution"? Are there values of that field that actually have something to do with "resolving" the conflict (perhaps the "automatic" strategy you've been referring to)?
        Hide
        Werner Guttmann added a comment -

        Okay, forgot to mention that you'll need to enable 'automatic name conflict resolution' by enabling the following property in a custom castorbuilder.properties file:

        1. Specifies whether automatic class name conflict resolution
        2. should be used or not; defaults to false.
          #
          org.exolab.castor.builder.automaticConflictResolution=true

        Having done so, I would personally set the name conflict 'reporting' strategy to "informViaLog" to hopefully find out that there are no conflicts anymore. Please be aware that you might have to set a name suffix (e.g. Type or ComplexType) for complexType defs if your XML schema has element and complexType definitions where the resulting class name would be the same, e.g. /root and /complexType:Root. And using a suffix type is sometimes not sufficient, as I have seen XML schemas where there's a global element named /root, a type named RootType and (somewhere) a local element definition /complexType:X/rootType.

        In other words, even with the new automatic naming conflict resolution, thinking is still required. Let's hope that we can ease that when starting to think about documentation .. .

        Show
        Werner Guttmann added a comment - Okay, forgot to mention that you'll need to enable 'automatic name conflict resolution' by enabling the following property in a custom castorbuilder.properties file: Specifies whether automatic class name conflict resolution should be used or not; defaults to false. # org.exolab.castor.builder.automaticConflictResolution=true Having done so, I would personally set the name conflict 'reporting' strategy to "informViaLog" to hopefully find out that there are no conflicts anymore. Please be aware that you might have to set a name suffix (e.g. Type or ComplexType) for complexType defs if your XML schema has element and complexType definitions where the resulting class name would be the same, e.g. /root and /complexType:Root. And using a suffix type is sometimes not sufficient, as I have seen XML schemas where there's a global element named /root, a type named RootType and (somewhere) a local element definition /complexType:X/rootType. In other words, even with the new automatic naming conflict resolution, thinking is still required. Let's hope that we can ease that when starting to think about documentation .. .
        Hide
        Werner Guttmann added a comment -

        Having said that, feel free to join me at http://irc.codehaus.org, selecting #castor.

        Show
        Werner Guttmann added a comment - Having said that, feel free to join me at http://irc.codehaus.org , selecting #castor.
        Hide
        David M. Karr added a comment -

        Next question: How do I set the name conflict reporting strategy? Is it in the castorbuilder.properties file, or a command-line argument to SourceGeneratorMain?

        Show
        David M. Karr added a comment - Next question: How do I set the name conflict reporting strategy? Is it in the castorbuilder.properties file, or a command-line argument to SourceGeneratorMain?
        Hide
        Werner Guttmann added a comment -

        Hmm, depends what we are talking about there.

        a) Current 1.1.1 snapshot: SourceGenerator.setNameConflictStrategy() only.
        b) SVN trunk: a), plus Ant task property.

        In the castorbuilder.properties file, you'll enable and disbale the 'automatic resolution mode' only by the means of setting a property.

        As such, can you please create a follow-up issue asking us to add a new command line parameter to SourceGeneratorMain ?

        PS How are you usually invoking the XML code generator ? Ant ? Maven ?

        Show
        Werner Guttmann added a comment - Hmm, depends what we are talking about there. a) Current 1.1.1 snapshot: SourceGenerator.setNameConflictStrategy() only. b) SVN trunk: a), plus Ant task property. In the castorbuilder.properties file, you'll enable and disbale the 'automatic resolution mode' only by the means of setting a property. As such, can you please create a follow-up issue asking us to add a new command line parameter to SourceGeneratorMain ? PS How are you usually invoking the XML code generator ? Ant ? Maven ?
        Hide
        David M. Karr added a comment -

        Normally, I execute the SourceGenerator from Maven 1.0.2, through a modified custom tag, using the SourceGenerator command-line options, so an Ant task property won't do me any good. I'll file an issue asking for a command-line argument for SourceGenerator.

        Show
        David M. Karr added a comment - Normally, I execute the SourceGenerator from Maven 1.0.2, through a modified custom tag, using the SourceGenerator command-line options, so an Ant task property won't do me any good. I'll file an issue asking for a command-line argument for SourceGenerator.
        Hide
        David M. Karr added a comment -

        What fun. Clicking the "CREATE NEW ISSUE" link gets a NPE in JIRA. I guess I need to root around to get to this.

        Show
        David M. Karr added a comment - What fun. Clicking the "CREATE NEW ISSUE" link gets a NPE in JIRA. I guess I need to root around to get to this.
        Hide
        Edward Kuns added a comment -

        Can't this be configured in a properties file in the classpath?

        Show
        Edward Kuns added a comment - Can't this be configured in a properties file in the classpath?
        Hide
        Ralf Joachim added a comment -

        David, the admins are aware of the problem and currently try to fix it.

        Show
        Ralf Joachim added a comment - David, the admins are aware of the problem and currently try to fix it.
        Hide
        Werner Guttmann added a comment -

        David, just to make sure, you are using Maven 1.0.2, and not Maven 2 ? As if we'd be talking about Maven 2, I am about to gain full control of the Maven 2 Castor plugin ....

        Show
        Werner Guttmann added a comment - David, just to make sure, you are using Maven 1.0.2, and not Maven 2 ? As if we'd be talking about Maven 2, I am about to gain full control of the Maven 2 Castor plugin ....
        Hide
        David M. Karr added a comment -

        We're using 1.0.2. As the normal castor plugin in 1.0.2 doesn't allow specification of a binding file, we defined a version of it ourselves inline. Using this, if we can get to the properties we need through either the SourceGenerator command line (preferred) or the castorbuilder.properties file, that would be sufficient.

        Show
        David M. Karr added a comment - We're using 1.0.2. As the normal castor plugin in 1.0.2 doesn't allow specification of a binding file, we defined a version of it ourselves inline. Using this, if we can get to the properties we need through either the SourceGenerator command line (preferred) or the castorbuilder.properties file, that would be sufficient.
        Hide
        Werner Guttmann added a comment -

        Well, to switch e.g. to the "informViaLog" class name conflict 'reporting' strategy, simply call the setClassNameStrategy() method on the SourceGenerator.

        In order to start using the new automatic class name conflict resolution, define the
        org.exolab.castor.builder.automaticConflictResolution property as discussed above in a local castorbuilder.properties, and pass this to the SourceGenerator using setDefaultProperties().

        In other words, it should be easily possible to achieve both from within your custom Maven plugin.

        Show
        Werner Guttmann added a comment - Well, to switch e.g. to the "informViaLog" class name conflict 'reporting' strategy, simply call the setClassNameStrategy() method on the SourceGenerator. In order to start using the new automatic class name conflict resolution, define the org.exolab.castor.builder.automaticConflictResolution property as discussed above in a local castorbuilder.properties, and pass this to the SourceGenerator using setDefaultProperties(). In other words, it should be easily possible to achieve both from within your custom Maven plugin.
        Hide
        David M. Karr added a comment -

        How do I call a method in my maven plugin? I thought I could just execute main methods (I'll ask about this on the maven-user list).

        Show
        David M. Karr added a comment - How do I call a method in my maven plugin? I thought I could just execute main methods (I'll ask about this on the maven-user list).
        Hide
        Werner Guttmann added a comment -

        David, i guess I assumed that you have actually written your own custom Maven 1 plugin for Castor, which might actually be a wrong assumption.

        Show
        Werner Guttmann added a comment - David, i guess I assumed that you have actually written your own custom Maven 1 plugin for Castor, which might actually be a wrong assumption.
        Hide
        David M. Karr added a comment -

        All we did was extract the castor taglib, that begins something like this:

        <define:taglib uri="castor"
        xmlns:define="jelly:define"
        xmlns:j="jelly:core"
        xmlns:ant="jelly:ant">
        <define:tag name="generate">

        and added this:

        <j:if test="$

        {!empty(bindingfile)}

        ">
        <ant:arg value="-binding-file"/>
        <ant:arg value="$

        {bindingfile}

        "/>
        </j:if>

        We stored this in the maven.xml for the subproject that needed to specify a binding file.

        Show
        David M. Karr added a comment - All we did was extract the castor taglib, that begins something like this: <define:taglib uri="castor" xmlns:define="jelly:define" xmlns:j="jelly:core" xmlns:ant="jelly:ant"> <define:tag name="generate"> and added this: <j:if test="$ {!empty(bindingfile)} "> <ant:arg value="-binding-file"/> <ant:arg value="$ {bindingfile} "/> </j:if> We stored this in the maven.xml for the subproject that needed to specify a binding file.
        Hide
        Werner Guttmann added a comment -

        Patch for SourceGeneratorMain for review (and feedback). As I cannot create a new issue myself .. , I am attaching this here.

        Show
        Werner Guttmann added a comment - Patch for SourceGeneratorMain for review (and feedback). As I cannot create a new issue myself .. , I am attaching this here.
        Hide
        David M. Karr added a comment -

        This will work for me, but I would think it would be better if the default was to print them to the console, without any prompting. I can't imagine anyone thinking the current way it works (prompting the user whether to continue or not) to be useful.

        Show
        David M. Karr added a comment - This will work for me, but I would think it would be better if the default was to print them to the console, without any prompting. I can't imagine anyone thinking the current way it works (prompting the user whether to continue or not) to be useful.
        Hide
        Werner Guttmann added a comment -

        I appreciate what you are trying to say, and I really agree, but I'd rather make this switch in default mode at a later time.

        Show
        Werner Guttmann added a comment - I appreciate what you are trying to say, and I really agree, but I'd rather make this switch in default mode at a later time.
        Hide
        David M. Karr added a comment -

        Shouldn't the usage messages indicate what the possible values are for the name conflict strategy?

        Show
        David M. Karr added a comment - Shouldn't the usage messages indicate what the possible values are for the name conflict strategy?
        Hide
        Werner Guttmann added a comment -

        Yes, could do. Will amend .....

        Show
        Werner Guttmann added a comment - Yes, could do. Will amend .....
        Hide
        Werner Guttmann added a comment -

        Hold on, the usage messages on SourceGeneratorMain you mean ?

        Show
        Werner Guttmann added a comment - Hold on, the usage messages on SourceGeneratorMain you mean ?
        Hide
        David M. Karr added a comment -

        In your patch, the description field says "Sets name conflict strategy to use." I would think it would be useful to indicate what the possible choices are. If that information is easily available somewhere else, that's ok, but in the context I can see (this patch), it seemed somewhat vague.

        Show
        David M. Karr added a comment - In your patch, the description field says "Sets name conflict strategy to use." I would think it would be useful to indicate what the possible choices are. If that information is easily available somewhere else, that's ok, but in the context I can see (this patch), it seemed somewhat vague.
        Hide
        Werner Guttmann added a comment -

        Change committed, changing the usage message to ...

        "Sets name conflict strategy to use (possible values are "'informViaLog', 'warnViaConsoleDialog')"

        Show
        Werner Guttmann added a comment - Change committed, changing the usage message to ... "Sets name conflict strategy to use (possible values are "'informViaLog', 'warnViaConsoleDialog')"
        Hide
        Werner Guttmann added a comment -

        Just made a new snapshot release available at

        http://snapshots.repository.codehaus.org/org/codehaus/castor/

        Please note that the JAR for the Ant tasks has been renamed castor-anttasks-1.1.1-SNAPSHOT.jar, and can be found at

        http://snapshots.repository.codehaus.org/org/codehaus/castor/castor-anttasks/

        I hope you'll find everything you'll need.

        Show
        Werner Guttmann added a comment - Just made a new snapshot release available at http://snapshots.repository.codehaus.org/org/codehaus/castor/ Please note that the JAR for the Ant tasks has been renamed castor-anttasks-1.1.1-SNAPSHOT.jar, and can be found at http://snapshots.repository.codehaus.org/org/codehaus/castor/castor-anttasks/ I hope you'll find everything you'll need.
        Hide
        David M. Karr added a comment -

        I'm not sure if I did something wrong, but I'm getting this:

        [java] java.lang.IllegalArgumentException: The ClassNameConflictResolutionStrategy ' informViaLog' does not exist in the Castor builder properties file and is therefore not supported.

        Note that it's printing ' informViaLog' (an initial space).

        Am I supposed to be adding something else to the castorbuilder.properties file?

        Show
        David M. Karr added a comment - I'm not sure if I did something wrong, but I'm getting this: [java] java.lang.IllegalArgumentException: The ClassNameConflictResolutionStrategy ' informViaLog' does not exist in the Castor builder properties file and is therefore not supported. Note that it's printing ' informViaLog' (an initial space). Am I supposed to be adding something else to the castorbuilder.properties file?
        Hide
        David M. Karr added a comment -

        I figured it out. I really expected I'd have to add "-nameConflictStrategy informViaLog" to the command line, not "-nameConflictStrategyinformViaLog". That's just odd. It'll work, though.

        Show
        David M. Karr added a comment - I figured it out. I really expected I'd have to add "-nameConflictStrategy informViaLog" to the command line, not "-nameConflictStrategyinformViaLog". That's just odd. It'll work, though.
        Hide
        David M. Karr added a comment -

        I would appreciate it if you could look at my generator console output here. There are a couple of unexpected things that happened here. Note that I'm sending "-Dlog4j.rootLogger=DEBUG,console" to the SourceGeneratorMain command line, as a workaround for not being able to send the warnings directly to the console. I'm also sending "-verbose", and not sending "-f".

        The first minor issue is the substring ".informViaLog" appearing at the end of some messages. I imagine that is not intended.

        The second minor issue (I think) is the warning about no appenders found, on one call to the SourceGenerator, which is odd, since I'm setting the rootLogger on the command line (perhaps I'm just misunderstanding log4j configuration).

        The next issue is that I think I would have expected to see a warning for the situation that produced this compile error:

        .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/Message.java:22: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.Message
        public class Message extends Message

        The (paraphrased) output follows this.

        ---------------------------------
        [echo] Generating sources for .../LoanRiskRating.xsd
        [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog
        [java] Creating classes for: loanRiskRatingRequest
        [java] Creating classes for: message
        [java] Creating classes for: messages
        [java] Creating classes for: property
        [java] Creating classes for: loanRiskRatingResponse
        [java] Creating classes for: loanProperties
        [touch] Creating ...\target\castor\tstamp\LoanRiskRating.xsd
        [echo] Generating sources for .../QuestionData.xsd
        [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog
        [java] Creating classes for: choiceIndices
        [deleted]
        [java] Creating classes for: questionSection
        [touch] Creating ...\target\castor\tstamp\QuestionData.xsd
        [echo] Generating sources for .../QuestionWeights.xsd
        [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog
        [java] Creating classes for: questionWeights
        [java] Creating classes for: questionWeight
        [touch] Creating ...\target\castor\tstamp\QuestionWeights.xsd
        [echo] Generating sources for .../CompassCREServiceTypes.xsd
        [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog
        [java] log4j:WARN No appenders could be found for logger (org.exolab.castor.xml.ValidationContext).
        [java] log4j:WARN Please initialize the log4j system properly.
        [java] Creating classes for: PortfolioLoanResultsRequest
        [deleted]
        [java] Creating classes for: Portfolio
        [java] Creating classes for: Portfolio
        [deleted]
        [java] Creating classes for: Portfolio
        [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio
        [java] Creating classes for: ReportResponse
        [java] Creating classes for: Warnings
        [java] Creating classes for: Messages
        [java] Creating classes for: Message
        [java] Creating classes for: Message
        [java] Creating classes for: Errors
        [java] Creating classes for: LoanLossDetailRequest
        [java] Creating classes for: Portfolio
        [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio
        [java] Creating classes for: PortfolioTimeSeriesRequest
        [java] Creating classes for: Scenarios
        [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Scenarios -> com.wamu.xmlbinding.compass.v1_2.Scenarios -> com.wamu.xmlbinding.compass.v1_2.Scenarios
        [java] Creating classes for: Portfolio
        [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio
        [java] Creating classes for: LeaseRollTimeSeries
        [java] Creating classes for: leaseRollTimeSeriesType
        [touch] Creating ...\target\castor\tstamp\CompassCREServiceTypes.xsd
        [echo] Compiling to .../target/classes
        [echo]
        ==========================================================

        NOTE: Targetting JVM 1.4, classes
        will not run on earlier JVMs

        ==========================================================

        [javac] Compiling 171 source files to ...\target\classes
        .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/Message.java:22: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.Message
        public class Message extends Message
        ^
        .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/descriptors/MessageDescriptor.java:21: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.descriptors.MessageDescriptor
        public class MessageDescriptor extends com.wamu.xmlbinding.compass.v1_2.descriptors.MessageDescriptor {
        ^
        -----------------------------------

        Note that the last generator call used the following binding file (the others do not use one):
        ----------------------------------
        <binding xmlns="http://www.castor.org/SourceGenerator/Binding"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:tns="http://ws.ppr.info/CompassCREService/1.2"
        >
        <complexTypeBinding name="Portfolio">
        <java-class name="PortfolioType"/>
        </complexTypeBinding>
        <complexTypeBinding name="Scenarios">
        <java-class name="ScenariosType"/>
        </complexTypeBinding>
        </binding>
        ----------------------------------

        Show
        David M. Karr added a comment - I would appreciate it if you could look at my generator console output here. There are a couple of unexpected things that happened here. Note that I'm sending "-Dlog4j.rootLogger=DEBUG,console" to the SourceGeneratorMain command line, as a workaround for not being able to send the warnings directly to the console. I'm also sending "-verbose", and not sending "-f". The first minor issue is the substring ".informViaLog" appearing at the end of some messages. I imagine that is not intended. The second minor issue (I think) is the warning about no appenders found, on one call to the SourceGenerator, which is odd, since I'm setting the rootLogger on the command line (perhaps I'm just misunderstanding log4j configuration). The next issue is that I think I would have expected to see a warning for the situation that produced this compile error: .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/Message.java:22: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.Message public class Message extends Message The (paraphrased) output follows this. --------------------------------- [echo] Generating sources for .../LoanRiskRating.xsd [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog [java] Creating classes for: loanRiskRatingRequest [java] Creating classes for: message [java] Creating classes for: messages [java] Creating classes for: property [java] Creating classes for: loanRiskRatingResponse [java] Creating classes for: loanProperties [touch] Creating ...\target\castor\tstamp\LoanRiskRating.xsd [echo] Generating sources for .../QuestionData.xsd [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog [java] Creating classes for: choiceIndices [deleted] [java] Creating classes for: questionSection [touch] Creating ...\target\castor\tstamp\QuestionData.xsd [echo] Generating sources for .../QuestionWeights.xsd [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog [java] Creating classes for: questionWeights [java] Creating classes for: questionWeight [touch] Creating ...\target\castor\tstamp\QuestionWeights.xsd [echo] Generating sources for .../CompassCREServiceTypes.xsd [java] – The generated classes will use a case insensitive method for looking up enumerated type values.informViaLog [java] log4j:WARN No appenders could be found for logger (org.exolab.castor.xml.ValidationContext). [java] log4j:WARN Please initialize the log4j system properly. [java] Creating classes for: PortfolioLoanResultsRequest [deleted] [java] Creating classes for: Portfolio [java] Creating classes for: Portfolio [deleted] [java] Creating classes for: Portfolio [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio [java] Creating classes for: ReportResponse [java] Creating classes for: Warnings [java] Creating classes for: Messages [java] Creating classes for: Message [java] Creating classes for: Message [java] Creating classes for: Errors [java] Creating classes for: LoanLossDetailRequest [java] Creating classes for: Portfolio [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio [java] Creating classes for: PortfolioTimeSeriesRequest [java] Creating classes for: Scenarios [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Scenarios -> com.wamu.xmlbinding.compass.v1_2.Scenarios -> com.wamu.xmlbinding.compass.v1_2.Scenarios [java] Creating classes for: Portfolio [java] Loop found in class hierarchy: com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio -> com.wamu.xmlbinding.compass.v1_2.Portfolio [java] Creating classes for: LeaseRollTimeSeries [java] Creating classes for: leaseRollTimeSeriesType [touch] Creating ...\target\castor\tstamp\CompassCREServiceTypes.xsd [echo] Compiling to .../target/classes [echo] ========================================================== NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs ========================================================== [javac] Compiling 171 source files to ...\target\classes .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/Message.java:22: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.Message public class Message extends Message ^ .../target/castor/src/com/wamu/xmlbinding/compass/v1_2/descriptors/MessageDescriptor.java:21: cyclic inheritance involving com.wamu.xmlbinding.compass.v1_2.descriptors.MessageDescriptor public class MessageDescriptor extends com.wamu.xmlbinding.compass.v1_2.descriptors.MessageDescriptor { ^ ----------------------------------- Note that the last generator call used the following binding file (the others do not use one): ---------------------------------- <binding xmlns="http://www.castor.org/SourceGenerator/Binding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://ws.ppr.info/CompassCREService/1.2" > <complexTypeBinding name="Portfolio"> <java-class name="PortfolioType"/> </complexTypeBinding> <complexTypeBinding name="Scenarios"> <java-class name="ScenariosType"/> </complexTypeBinding> </binding> ----------------------------------

          People

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

            Dates

            • Created:
              Updated:
              Resolved: