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

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.

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

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.

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.

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 ?

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?

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.

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?

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

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.

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)?

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 .. .

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

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?

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 ?

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.

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

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

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

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 ....

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.

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.

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).

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.

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="$

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

"/>
</j:if>

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

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

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.

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.

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

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

Hold on, the usage messages on SourceGeneratorMain you mean ?

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.

Change committed, changing the usage message to ...

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

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.

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?

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.

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>
----------------------------------