castor

Matthias, looking at the attribute definition below ...

<xs:attribute name="enumAttr" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="a"/>
<xs:enumeration value="b"/>
<xs:enumeration value="c"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>

in the context of your XML schema (with attributeFormDefault set to 'unqualified'), I wonder what the resulting namespace of that anonymous simple type definition will be. My working assumption is that this anon type will not be associated with the target namespace of the schema; if that's the case, Castor works just fine. I guess I will have to verify that my assumption.

Hallo Werner!

You may be right with your assumptions. But the current generation of a class with "package types;" is not feasible.
I think, the assumption that the anonymous type belongs to the namespace of the outer element is at least more oriented to "real life". But I am not schema expert.
If you leave it in the current way, I have two options:
(1) There is a feature in Castor (unknown for me) where I can specify the package of anonymous simple types) or any other option which restores the <1.1 behavior. If this is the case, could be please give a hint to that?
(2) I have to convert all inner simpleTypes to top-level non-anonymous types which hopefully keeps the compatiblity of my schemas in my real life use case.

I'll attach the schema with option (2), which is - in my humble opinion - equivalent to the element with the anonymous simple type (->enumTest2 with enumType2).

Even if it involves some work, I can probably live with solution (2), but please consider that currently anonymous simple types in conjunction with unqualified attributes are unusable with castor and I think that this usage pattern is not that uncommon.

Thanks for your time.

Second variant with top-level simpleType. Castor generates nice package hierarchy using this approach.

Matthias, I am just having quite a longish conversation with a colleague of mine here at work, and we cannot really agree on a valid approach re: the XML schema spec. In other words, it looks like we will have to go and ask those who know .. .

With regards to your particular problem, here's my current train of thought:

a) I don't know why the behavior of Castor with regards to class generation for a anon simple type within an attribute definition did change. I still have to have a look at this.
b) The current solution looks 'okay' to me, though the code in XMLBindingComponent.getTargetNamespace() needs to be improved with regards to target namespace resolution. Currently, for a simple type (and complex types as well), a target namespace is assumed if the simple (complex) type definition is global. Which in my current thinking is not sufficient, as it should be 'targeted' as well if the parent of that simple (complex) type definition is declared to be 'qualified'.

Having said that, I do acknowledge (given that I can validate my current thinking) that this change in behaviour between 1.0.x and 1.1 is not optimal to you. But whatever might have caused it, it is a change for the better, as it improves semantic coherence.

If converting all anon simple types is an option to you and does not cause you too much work, I'd love to leave it as it is.

Actually, introducing a new command line switch for the source generator that allowed you to specify a default package for artefacts generated for unqualified XML schema elements might be an option.

Ant last but not least, feel free to join me (us) at http://irc.codehaus.org, channel #castor.

As a reminder, the important parts of the IRC session today, of course subjectively compressed:

<Matze> Regarding 1864: when I said it is possible to convert it ( i meant converting it for my current project). At our company we heavily use Castor and (probably) not all of us will agree here.
<Matze> So a command line option, which turns the generation back to 0.9-1.0 days would be very appreciated, if there is no cleaner option.
<Matze> Still, I think, that it s a "common understanding", that an anonymous inner simpleType just belongs to its element. Disclaimer: it is long ago when I read the schema spec last time and I am not a lawyer
<Matze> Where should the anonymous simpleType belong to, if not to its enclosing element?
<ralf> if i understand what werner wanted to offer in his comment to 1864 was that all anonymous generated class go into a default package
<ralf> it also sounds reasonable that they should be put in the same package as the enclosing element but i am not able to tell you if that is easy
<wguttmn> hi Matze
<wguttmn> yes, the offer is indeed to make all classes that represent the Java class that's generated as a result of an anon type for an unqualified element/attribute
<wguttmn> go into a configurable package, the default being the default package.
<wguttmn> in other words, a new command lineoption to source generator that will be exposed in the standard ways.
<wguttmn> having said that, if you happen to have multiple target namespaces 8as you would with imports, this still means that you will not be able to
<wguttmn> generated (locally) unqualified artefacts into separate packages.
<wguttmn> how does this read ß
<Matze> that would help me even if it is a repetition of the "package" entry in binding.xml
<Matze> of course we have imports with different target namespaces, but in our case, we do not generate imported schemas
<wguttmn> maybe there's a way of allowing things to be defined tehre as well .....
<wguttmn> as far as I remember, namespace to package mappings can be defined in three places:
<Matze> they are generated on their own: 1 schema -> 1 jar as a rule of thumb
<wguttmn> a) binding file
<wguttmn> b) catsorbuilder.properties
<wguttmn> c) through a setter on SourceGenerator.
<wguttmn> okay, looks like this will work for you and your environment.
<Matze> yes
<wguttmn> which makes me still wonder whether this si a valid enough approach in general.
<Matze> what do you think? is this use case uncommon, because i wonder that noone cried since November when it got introduced
<wguttmn> good question ...
<wguttmn> I guess I will introduce this new way of specifying namespace to package mappings for unqualified artefacts and make it clear in the
<wguttmn> release notes as well as HTML docs what this means.
<wguttmn> and clean up any ambiguity as part of that job.
<wguttmn> and maybe read up on what the JAXB spec has got to say on this very subject ....
<Matze> So if you add the command line option, it just means that I can really start trying that version.
<wguttmn> i have gopt a(commercial) client of mine that seems to be thinking along the same lines(s)
<wguttmn> is there any other 'biggies' out there (bugs or missing features) that you'd like to see added/tackled ?
<Matze> Maybe. When I have the "anonymous simpleType" support, I will maybe come beyond source generation.
<Matze> Any plans, when you get this in?
<wguttmn> so if you happen to have a few minutes, please do not hesitate to join us here ,,,,
<wguttmn> I'll try for 1.1, but cann ot promise anything
<Matze> As soon as you have it, I will continue testing. Right now, just for trying a version, it would be too much work to convert all simpleTypes, for example.

If I may add a wish here: It would be nice to have support in the binding file for that (for the first step, command line option is absolutely enough), because then I have the important parts together, e.g.
<package>
<name>x.y.z</name>
<namespace>http://...</namespace>
</package>
<anonpackage>
<name>x.y.z.anon</name>
</anonpackage>
If there is only command line, then I have the package once in binding.xml and once in build environment where source generator is called.

Matthias, I'll be adding support for the command line first (and try to get this in in time for 1.1), and deal with binding file support at a later time.

Initial patch for review. So far, I have added a new property to castorbuilder.properties that allows you to define a default Java package name for unqualified XML schema artefacts.

Improved patch that allows a user to specify the default Java package name for unqualified XML schema content by calling SourceGenerator.setPackageNameForUnqualifiedContent(). This method is coded in such a way that any package name provided here will override a package name specified in the builder properties.

Actually, some comment of a colleague of mine got me thinking today. I guess I will check with 1.0.5 sources to get an idea how it could ever worked the way it did work in the past. As such, I will not include this with 1.1

No problem. I also prefer to have a substainable solution for this.
As I never ran a Castor version without applying some patches, I'll just continue to do so at least for some further investigation of this new version.
Your patches will at least help me to do that.
But as we discussed in the chat last week: I am sure and would bet 5 euros, that this will show up after the 1.1 release .

By the way: the problem appears also with Castor's own binding.xsd:
the complexType "fieldType" has also two enumeration based attributes and they are also generated in "package types;" if source generator is called as in my test scenario.
It just works for the Castor build process because a base package is provided with the ant task and not - as it is in my case - inside the binding file.

This is probably the reason why nobody else complained: It seems to be common to pass the base package directly either via ant task "castor-srcgen" or command line option "-package".

Just FYI: my current workaround is to remove the namespace-package mappings from binding.xml and use the "-package" option or "package" attribute in castor-srcgen on the source generator instead.
I can live with this solution. I would just note, that with this change the "-package" option is de-facto mandatory. It would be good to reflect this in documentation.

Looks like CASTOR-1934 is suffering from the very same issue.

And in CASTOR-1934, a 'base' package is always provided. It looks like 'unqualification' is the culprit ... ;-(.

It might be worthwhile for you to follow the conversation at CASTOR-1934.

Matthias, please see my last comment over at CASTOR-1934 to get an idea about progress being made and ideas about testing, etc.

Werner, I just read CASTOR-1934 today and I can imagine that your patch from Monday would solve also my problem.
I will try this as soon as possible, not today because of lack of time, but hopefully this week.

I'd appreciate any update from your side ....

Damned, JIRA dropped my comment.
So now in short form. Using your patch from CASTOR-1934 and latest sources generate anonymous classes as specified in the binding.xml namespace-package mapping. So I could remove the "package" attribute from source generator ant task again.
Generated code looks ok. No compilation errors.
So everything behaves like in the 0.9.5 days.
Tomorrow I will do some runtime checks and will let you know about problems there. Thanks so far.

Runtime also works smoothly.

Thanks for the feedback/testing. I guess I shall commit CASTOR-1934 in due time, then ..

Just for completeness sake, all patches attached above are rendered obsolete because of the progress with CASTOR-1934.

Yes, agreed. I never liked and never used the approach with the anonymous package.

Final patch for review.

Matthias, I have just attached a patch to CASTOR-1986 which I believe is actually superior to the one attached to CASTOR-1934. Would you be in a position to test-drive this again ? I agree that I am asking for a lot of time (again), but the patch attached to CASTOR-1986 deals with the problem at the root of all these issues (CASTOR-1934, CASTOR-1986, ...) and does not introduce additional logic.

Hi Werner! I will try today or tomorrow.

Hi Werner, bad news from me.

I used current SVN trunk with patches from CASTOR-1986 and CASTOR-1881. Especially, I reverted the patch from CASTOR-1934, which solved this issue before.
As you can guess, using this code base, my problem comes back. You can also try it yourself. The attached test case from above also generates "package types;" again for the enumerations.
Feel free to ask for more information. I can also try new patches. But for now SVN+CASTOR-1881+CASTOR-1934 is the best choice for me.

Again, I added a comment to CASTOR-1934. Can you please watch this issue as well, so that you receive notifications to CASTOR-1934 as well ?

Having looked into your problem once more, I think I will commit CASTOR-1934 as is, as it clearly addressed issues related to unqualified schema artefacts. Can I please ask you to attach a sample XML document that I can successfully use to unmarshal from and that validates against the XML schema(s) attached ?

Werner, I do not have a sample XML document for THAT schema. The original schema, where I encountered the problem first, was too complex and I was not allowed to put an original schema from our company here.
On the other hand, what do you want to prove with this sample document? Without the patch from CASTOR-1934 I get compile errors since the packages, which are imported from user code (e.g. a.b.c.types) do not match with the generated packages (types).

> On the other hand, what do you want to prove with this sample document?
Ideally, I don't want to commit a fix only, but in addition improve the Castor XML test suite with a test that is based upon your XML schema, where classes will be generated and compiled. In addition, such a test case (normally) includes a sample XML document that will be unmarshalled against the classes generated.