When using Apache XML Beans to generate types from xsd:enumeration types, XMLBeans generates custom classes that are not Java 5 enums but some kind of special class to represent the enumeration.
This might be the case, because XMLBeans is older than Java 5 and there were no enums at the time or you still want to keep Java 1.4 compatibility. However, I would like to get "real" enum types, so my question is: Is there a way to generate Java 5 enums with Apache XML Beans?
(Jaxb does this like I want, but I'm not sure if I want to remove XMLBeans and introduce Jaxb just for that detail.)
I do not think you can achieve what what you want with XML beans. You even mentioned the reason yourself. I'd recommend you to move to JaxB.
But if you really wish to continue using XML beans I'd suggest you a patch. You can post-process the generated classes and convert them to enums. I did something like that in past using ant tasks. There are ant tasks that know to perform string replacements, so it is not a problem. In worse case you can implement your own task in java. But I believe you do not have. I think that this is the simplest solution.
Good luck.
Related
I'm currently developing a software where the user can define a complex hierarchy of objects as settings.
Also this settings objects will provide interfaces as an API for other developers.
Now I want to store these setting and reload it.
I'm currently considering different ways to do exactly that, but none of my solutions are "good" in my opinion.
The main goals should be:
It should output a String, because i prefer a human readable configuration over a fast one.
It should be reliable even when the the code is changing. This means not it should do magic, but it should be obvious that an change could break already stored configuration. (Eg. How do I prevent that my colleague renaming a class and breaking production. )
Storing and loading should work with object, interfaces and generics.
Keep configuration of what is stored how as low as possible. I would prefer convention over configuration.
I know many of you faced the same or a similar issue while developing.
So what was your solution? Which framework did you use and why?
All solutions I came up with are either not reliant, a huge configuration or to much code.
So I'm looking forward to get some good new perspectives on this topic from all of you.
Thanks.
I would recommend XStream. Without any configuration it has similar capabilities as java.io.*ObjectStream but outputs XML instead of binary blob. You will only want to add few aliases for class names to make file more readable.
I recommend to specify a XSD and use JAXB to generate the Java classes and marshal and unmarshal XML based settings files.
Make sure the root tag contains the version of the XSD. You can use StAX to read the version first and determine the correct version of JAXB classes if you need to support several versions.
For further information this how i solved this problem now:
I used Gson for serializing the object hierarchy to JSON. Added an Generic TypeAdapter to it for serializing and deserializing all known Interfaces. This adapter saves the class name into the JSON object and constructs this class while deserializing. No additional configuration is needed, besides registering this TypeAdapter for each used Interface.
In order to make it reliable I will add an Unit Test to the project that will deserialize the complete possible configuration. So any changes to the code will break the tests.
In this way i can fulfill all of the points mentioned above.
I hope this helps anyone.
I have seen similar questions saying that the direction to take (java to xsd or xsd to java) depends on your focus, in other words are you looking to create the perfect schema or perfect java design.
However I am curious to know if the use cases are the really same. A colleague of mind commented, "why would you want to go from java to xsd?", if you do that you have already created an implementation. Which sort of does beg the question, why would you start with hand written java, convert to xsd, and then eventually convert to generated java.
To try to ask it differently, does it really matter which route you take (java to xsd or xsd to java) , because in the end the artefact that you require is xsd, which can be converted adhoc to java when and if required.
Each approach has its pros and cons:
XML-To-Java:
PRO: The interface contract is a first class artifact. It is explicitly designed and coded. Expressing of constraints (e.g. number of times an element can/should appear) is directly and naturally supported by XSD.
CON: Degree of difficulty. In my experience, I have found that most professional Java developers tend not to be fluent in XML Schema. Thus there can be a learning curve.
Java-To-XML:
PRO: Fast, efficient development. Look at the JAX-RS and JAX-WS specs (implemented in tools such as Apache CXF). These APIs apply annotations to Java interfaces to produce web services. The web service contracts (i.e. the WDSL/WADL in XSD) are auto-generated by the web service framework. The advantage here is that Java developers can work entirely in Java. No need to learn XSD.
CON: Because the interface is generated, it is not a first-class artifact. It cannot easily be shared with consumers of your service. It also means that a Java developer could change part of the Java interface, and inadvertently change the service contract. I have seen this happen. A change to the structure of an object (which BTW is not even a method signature change) can alter the XSD.
I'm on my first project for generating java beans from xsd files. The generation works perfectly well, but now I want to add some special features to the generated classes. Modifying the generated code would be a bad idea, because it would be lost as soon as someone updates the code.
I don't understand how to get beans with custom functionallity generated from the unmarshalling process. Can you please point me in the right direction?
Thanks
Those generated classes are just value objects, so it won't be really a good idea to add any custom logic in them. However if you just need to make those generated classes more usable with better getters/setter, fluid API, etc, you could add some xjc plugins or even write your own plugin.
#EugeneKuleshov's answer is a good one. additionally, i believe you can configure xjc to generate interfaces instead of classes, and then you can implement the interfaces using your own custom model classes.
And what about extending the generated classes and overriding those methods you need?
I have to admit that I am pretty confused how annotations work in java (SOAP) webservices.
What does adding a tag do? I think that maybe adding a tag generates some xml or maybe a wsdl? When I build should I see a difference in those files?
Any description or link would be great. I have done a lot of searching but I think maybe I am searching for the wrong things. For example when I search for:
#securityDomain
I just get garbadge results. I am having difficulty finding a good description of what specific tags do as well as how tags in general work.
Update:
So is it safe to say that you can either use annotations or you can write your own xml/wdsl?
#nnotations are defined by the Java language. An Annotation is a class. When you mark something with an annotation, the compiler and runtime arrange for an object of that class to be visible at runtime via java reflection.
The JAX-WS and JAX-B standards each define a raft of annotations. At runtime, or at java2ws(dl) time, they look at those annotations to decide what to do.
It looks to me as if #SecurityDomain in particular is part of JBoss, not any global standard, so you have to read the JBoss documentation to find out what it does.
I found this.
My project is slowly implementing Java annotations. Half of the developers - myself included - find that doing anything complex with annotations seems to add to our overall maintenance burden. The other half of the team thinks they're the bee's knees.
What's your real-world experience with teams of developers being able to maintain annotated code?
My personal experience is that, on average, dealing with annotations is far easier for most developers than dealing with your standard Java XML Configuration hell. For things like JPA and Spring testing they are absolute life-savers.
The good thing about annotations is that they make configuration on your classes self-documenting. Now, instead of having to search through a huge XML file to try and figure out how a framework is using your class, your class tells you.
Usually the issue with changes like this is that getting used to them simply takes time. Most people, including developers, resist change. I remember when I started working with Spring. For the first few weeks I wondered why anyone would put up with the headaches associated with it. Then, a few weeks later, I wondered how I'd ever lived without it.
I feel it breaks into two uses of annotations - annotations to provide a 'description' of a class vs. annotations to provide a 'dependency' of the class.
I'm fine with a 'description' use of annotations on the class - that's something that belongs on the class and the annotation helps to make a shorthand version of that - JPA annotations fall under this.
However, I don't really like the 'dependency' annotations - if you're putting the dependency directly on the class - even if it's determined at runtime from an annotation rather than at compile time in the class - isn't that breaking dependency injection? (perhaps in spirit rather than in rule...)
It may be personal preference, but I like the one big XML file that contains all the dependency information of my application - I view this as 'application configuration' rather than 'class configuration'. I'd rather search through the one known location than searching through all the classes in the app.
It depends highly on IDE support. I feel that annotations should be kept in sync with the code via checks in the IDE, but that support for this is somewhat lacking.
E.g. the older version of IDEA would warn if you overrode a function without #Override, but wouldn't remove the #Override tag if you changed the method signature (or the superclass signature, for that matter) and broke the relation.
Without support I find them a cumbersome way to add metadata to code.
I absolutely love annotations. I use them from Hibernate/JPA, Seam, JAXB....anything that I can. IMO there's nothing worse than having to open up an XML file just to find out how a class is handled.
To my eye annotations allow a class to speak for itself. Also annotations are (hopefully) part of your IDEs content assist, whereas with XML config you are usually on your own.
However, it may come down to how the XML configs and Annotations are actually used by any particular library (as most offer both), and what sort of annotation is used. I can imagine that annotations that define something that is build-specific (eg. file/url paths) may actually be easier as XML config.
i personally feel that the the specific use case you mentioned (auto-generate web forms) is a great use case for annotations. any sort of "framework" scenario where you can write simplified code and let the framework do the heavy (often repetitive) lifting based on a few suggestions (aka annotations) is, i think, the ideal use case for annotations.
i'm curious why you don't like annotations in this situation, and what you consider to be the "maintenance burden"? (and, i'm not trying to insult your position, just understand it).