Castor ignores case by default. Xml doesn't.

First patch for review.

I have got quite a biggish problem with this patch 8as much as I like it). It basically breaks code for everybody, as so far the assumption was that the constant names are in upper case. As such, I will have too introduce a new property that you have to enable/disable selectively to get/avoid this new naming scheme.

In addition, with the new mode this causes some serious problems for folks who e.g. have values such as 'true' in their enumerations, as java will be choking on key words.

Btw, let me just ask one more question: how would you feel about giving 'lengthier' names to constant definitions for 'm and 'M', respectively. Such as 'MILLIS' and 'MILLIONS' .. or whatever you like. This way, you could avoid the problem altogether.

I see both your points (lack of compatibility, problem with reserved keywords in Java). In the latter case we're poking against brain-deadness of Java, so it's not just XML that's braindead, see?

To resolve both points, maybe the following strategy could be used:
Instead of immediately emitting a java enum, collect all symbols that should be generated.
Then determine whether upcasing would give a clash
If so, emit symbols unchanged in case.
If not, emit symbols in uppercase as it used to be.

This would cover more cases than before, still of course not resolving issues with e.g. "true" or "while" as one of the enumerated values. I agree that at some point the user has to interfere, I'd just like to see the borderline where the user has to take action moved further away. Also for the cases where upcasing all symbols would previously work (i.e. no clash), still uppercase symbols would be generated.

I might add: If a user specifies a symbol via mapping file, do not change case of that specified symbol.

before we forget it, your patch obviously solves my problem in a non-binding-file-using-way. Let's see if I can offer you an implementation of the strategy outlined in my previous content.

This patch implements what I was outlining in a previous comment.
It will generate uppercase symbols as is the historic behaviour when there is no duplicate naming coming from uppercasing the symbols.
It will generate unchanged-case symbols otherwise.
(While I was there adding the sets I also changed the logic for checking for duplicate naming in the uppercase tradition which is obvious I think when you have a set of generated symbols available).

Martin, I am about to commit this patch as is. I still need to have a look at the existing documentation, and add a few test cases to our CTF. I am more than happy to get the latter done today; would you be able to help me out with the first one, e.g. identify the correct locations where the reference guide needs to be amended.

Werner, it's good to see that this issue hasn't been forgotten

I forgot one more thing about the patch: It will start generating case-sensitive symbols after it encountered the first case clash. That could be surprising. Please let me have another look at it, I just forgot about it. Maybe also a property should be added that can toggle this behaviour (i.e. turn off generating things case-sensitively no matter what).

I'm travelling at the moment but can get around to all three things (documentation, resetting case-sensitive behaviour if no clash for current set of symbols, property) between friday and monday. Please hold back comitting this patch until then if possible. Thanks.

No worries. I was just writing test cases as I write this, and it is good to know that I might have run into issues a few minutes later. Take your time, as I won't be releasing Castor 1.3 before early next week. If you looked at release 1.3 in Jira, you'll come to figure that I am facing about 5 issues to be resolved (incl. this one). In addition, it would be nice if I could ship the new fragment mapper as well (where unfortunately no documentation has been written).

@property: yes, I was thinking along these lines as well. In other words, provide folks with a way to go back to the old way of things.

Patch incl. test cases

Slightly improved patch, mainly focusing on Checkstyle issues.

Martin, any idea about when you'll be able to attach an improved match ? We've got only three remaining issues, and as always ... the faster, the better.

Martin, mind if I push this to a 1.3.1 release ?

Pushing back to 1.3.1 as indicated. I'd really love to release 1.3 GA, to be honest - and ship 1.3.1 shortly thereafter.

So is this bug still open or fixed!?

Sorry, can't tell at the moment. A structural inability of castor to deal with xsd:any has forced us to use another binding framework; I haven't had time to return to the issue. Sucks, I know. The earliest I can check [by having some more time again] is in mid-september. As I said, sorry. But that's what's happening with volunteers

Jean-Marc, the issue has not been resolved yet but there is a patch including tests attached. Reading through earlier comments I get the impression that only changes to docs are missing.

The issue in the comment from jan 21 still is there if the patch hasn't been updated. [i.e. after first case clash it will start generating case-sensitive output for all symbols by default and not only for the set of symbols where case-insensitivity is a problem]. Plus the patch doesn't handle interaction with the cmdline switch about case sensitivity well I think. Anyways, as I said, I don't have the time to do it for at least a few more weeks.

Thanks for the status update Martin.

Jean-Marc, whist I appreciate your frustration to some agree, may I please remind you that Castor is an open source project, and as such - per definition - relies on contributions from both committers as well as users (such as you are). In other words, why don't you take the recent patch as contributed from Martin and try to improve it yourself ?

Alternatively, let's wait for Martin to be able to free some time, or consider taking up professional support where I (or any other committer familiar with that code base) will look into this issue in a commercial way.