Skip to main content

empty enum episode

5 replies [Last post]
mikhailfranco
Offline
Joined: 2007-12-05
Points: 0

I have a token-based XSD enumeration,
and xjc generates a Java enum definition, as expected,
but there is no binding info generated in the episode file,
so the enums cannot be reused across schemas,
and are generated in every derived project.

Is this expected, or am I doing something wrong ?
Is there any way to share enums across multiple schema bindings ?

Thanks,
Mik

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lexi
Offline
Joined: 2004-04-09
Points: 0

Enums are indeed buggy right now.
The problem is that simple types don't have appropriate class items/class outlines and so there's nothing to customize there.

What I usually do in such cases is (1) either generate no enum (2) use an antrun plugin to delete the excessively generated enum classes. Since enums are already compiled in the episode schema, it is quite safe to simple delete the excessively generated files.

i'm not sure if the problem is resolveable in the currect JAXB RI architecture.

pjdarton
Offline
Joined: 2008-02-18
Points: 0

I'm having much the same issue - I'm using JAXB to generate code for XML schemas that include enums, and JAXB's "episode" facility is failing because it's not including any mention of the enum classes in the episode file it creates.

However, I _do_ have "appropriate class items" for my enum definitions - I get a Java enumeration generated for each XML enumeration I define and, furthermore, the name is munged as I would expect: I've told it to add "Stub" to the end of all the names, and just as a complex type "Foo" gets turned into "my/package/name/FooStub.java", a simple enum "Bar" gets turned into "my/package/name/BarStub.java".
Unfortunately, the episode file is missing the lines that say '

This means that next time JAXB sees a need for the Bar definition, it creates a new one, only it'll create it in the default package, not the one it used previously, resulting in broken code...
(so, no, just deleting the "excessively generated" classes isn't an option, as the newly generated classes will refer to the "excessively generated" classes and not the originally generated ones)

This means that the "episode" files generated by JAXB are effectively "not fit for purpose", which really isn't acceptable (one wonders if the author's been taking too many lessons from Microsoft's Vista team...)

pjdarton
Offline
Joined: 2008-02-18
Points: 0

Further note: It isn't simply a case of a bug in JAXB's generation of episode files.
If one generates an episode file that includes the missing enum class, e.g. , then JAXB completely ignores it.
As a result, it re-generates the enum, but it does so according to the current command-line & configuration settings, not (necessarily) those that were used to generate the original.

I do, however, believe I have a solution, albeit a rather messy one (I feel that "messy" is justified when working around a tool whose own behaviour is messy).

1) Never use the "-p" command-line argument to set the package - use a bindings file instead.
2) Parse your bindings file to list what packages you expect to be generated.
3) Run XJC, generating code into a tempory area
4) Take the episode file that XJC generated, and merge it with your own bindings file in order to create your own episode file. You'll need to delete the '' clause from the generated episode file AND also replace ' 5) Take _only_ the expected Java packages (as calculated in step 2) from the tempory area, throwing away anything else that XJC might have generated.
6) Jar up the result, ensuring that your merged episode/bindings file is META-INF/sun-jaxb.episode so it'll automatically be parsed by future XJC sessions.

This seems to work for me - whilst XJC still generates code for enums, it generates them in the same way it did originally (because of the merged-in original bindings directives in the episode file), and, because we're only taking code we _expected_ to get, we don't see those duplicates outside the temp area.

I'm a little unsure of the effect of removing the clause, but I found that it didn't work with it in.
Equally, you can forget using any global bindings, as JAXB can't handle it if an included episode file specifies global bindings as well as your own bindings file.

It took some quite huge Ant macros to do all this (ones that would be tiny if JAXB actually worked properly!), but it (seems to) work here...

mikhailfranco
Offline
Joined: 2007-12-05
Points: 0

Forgot to mention this is under JAXB RI 2.1.5

Mik

nacha_n
Offline
Joined: 2012-10-07
Points: 0

Hi,
Scd bindings for enum types dont seem to be honored even if the episode files are manually injected with such bindings:

<bindings if-exists="true" scd="~tns:ErrorCategory">
            <class ref="com.ebay.marketplace.services.ErrorCategory"/>
        </bindings>

The pojo for ErrorCategory still gets regenerated. Does anyone know if this is fixed?
Thanks,
Nacha