XML serialization for Groovy classes - java

For an application build on Spring MVC + Groovy + Google App Engine i need simple XML serializer/marchaller.
I'v tried:
XStream - it doesn't work on Google App Engine, because it uses restricted (at GAE) classes
Jaxb2 - it doesn't work with Groovy classes, because groovy class have additional (hidden) fields (like metaClass, etc)
XmlBeans as I understand can be used only for deserializing from XML to Java Beans
Castor seems to be big overhead (i don't need any XMLSchema and so on)
I want to just dump class to the corresponding XML, and i want to configure tag names using some simple config (java annotations, for ex), without XMLSchema/DTD
So, requirements is:
usable at Google App Engine
no XMLSchema/DTD
simple configuration
fast
it's enough only object->xml
maven2 support
groovy support (or manually configured list of used fields)
(optional) spring integration
Can anyone recommend me an good tool for this?

I don't know if there is a lib which fits your requirements, but you could take a look into that list: http://karussell.wordpress.com/2009/09/03/xml-serializers-for-java/
e.g. the simple lib is a good candidate

Related

What is the best way to parse data using same API between JEE Restfull webservice and Android?

We have a big project which is composed by JEE modules, JAVA client applications, Android applications, and other self-made java projects.
Because of the variety of projects, we decided to make java libs projects and java entity projects which are common to JEE, Java client applications and Android applications in the goal of limit code redundancy between projects.
At the beginning, we only had Java Clients and Restfull web services on the JEE server side which were exchanging data using JAXB XML Binding API. So it was easy to use JAXB annotations on our Classes in the entity project (which is set as dependency on Java Client project and JEE projects). Both sides could easily encode and decode XML data with the same annotations.
Now that we have an Android app, I wanted to use the same way to exchange data. The thing is that JAXB is 'depreciated' on Android. So I found in Jackson lib that there is a JaxbAnnotation parameter for getting data which is bind with JAXB but I'm not convinced by the full compatibility of the solution.
I also tried using JSON binding since I saw that JSON-B will be the standard in JavaEE 8 but it seems that it needs JavaEE API classes and I don't think that it's good to add it to Android project.
So my question is: What is the best practice to exchange data between JEE Restfull web services and Android application using the same entity dependency (and same parsing API) and limiting the XML or JSON binding annotation on the entity objects?
I hope that you will well understand the problem.
Thank you.
Let's name your entities project entities-module. This project contains POJO classes annotated with JAXB annotations such as: #XmlElement, #XmlType, etc. Since, like you wrote, "JAXB is 'depreciated' on Android" you need to choose between: read JAXB annotations by other tools or create new customised POJO structure.
Read JAXB annotations by other tools
Jackson library has good support for JAXB annotations. All you need to do is to use jackson-module-jaxb-annotations module. It is easy to register and if you already use Jackson for serialising/deserialising JSON this is obvious choice. How to do that you can find reading answers for this question on SO: Using JAXB with Google Android.
Pros:
You do not need to create new POJOs schema.
In case of changes in Restful API you use next version of entities-module project.
Cons:
Problems with enabling JAXB on Android.
Performance issues linked with using heavy JAXB and Jackson module layers.
New module
Second choice is to create new module with POJOs and use faster and smaller library like SimpleXML.
Pros:
Better performance
No problems with building app with depreciated JAXB classes.
You can optimise structure: ignore unused fields, choose better types, etc.
Cons:
You need to create new module with new classes structure.
Learn and maintain new library
In case of changes in API you need to duplicate changes in few modules.
You need to take a look on above pros and cons list and decide what is the best for you.
I would like to also add two more options:
Replace JAXB annotations with Jackson annotations. Jackson has really good XML support beside great for JSON. It will enable for you easy support for JSON and XML formats in your API. Also, you can use Jackson library on Android.
Create new JSON API for Android app. Mostly, UI flows on Android app is different than on Web App and you will, probably, end up with that idea anyway.

XML vs Java configuration. SpringMVC web-application config

I am starting to learn about the Spring framework. I have seen two ways to configure a web application, one uses a web.xml to configure the servlets ect. The other uses a Java class that implements a WebApplicationInitializer and is annotation driven.
I was told that, "XML is the old way, no new project should use XML anymore". Can anyone tell me why this is? Lots of online resources quote "Convention over Configuration", however, using the online learning tools I have access to, the vast majority of examples are using xml configuration. I am finding it very difficult to find relevant examples with Java configuration.
I would also like to know what the pro's and con's of using one over the other are? If it it easier to find resources based around xml configuration, then would it be destructive to future job prospects to side step the Java configuration and focus on xml?
The advantages of Java Config is the type safty. The Compiler can check if you wire your application correctly (based on the types). Refactoring is a little bit easier.
Using XML configuration this can only checked during runtime.
My own opinion is that there is not a big difference between the two approches. You only "tell Spring" differnetly how to wire the application. The Java Config brings in some nice features (e.g. Spring Security Config), but also hides some "magic" which is sometimes harder to understand.
You may also have a look at earlier questions about this topic.
In Projects we still do here a lot of XML configuration which works pretty well. New Configs are often written as Java Config and integrated into the "lagacy" configs.

Java bean mapping library - which to choose (transforming one object to another)?

I have multi tier project with Model, DTO, Managers/Services using DTOs and also some CXF webservices clients with a layer that transforms responses to my models.
We are using different approaches, the project is big, we use for example Spring Beautils an many by-hand mappings which can produce errors, are hard to maintain but are fastest.
I've found Orika an interesting library, that doesnt use reflection int the way the Dozer does, it generates code (like the by-hand code) in some point but I don't know when - when you build your application with maven or when the application is being deployed on for example Weblogic server?
What would you chhose???
BTW: Do you know any other libraries that are worth using (I use Java 1.7, log4j, junit, spring, hibernate, cxf, jersey, guava, lamba4j)?
You could be interested to see JMapper Framework.
Especially as it permits to manage the multi-level mapping (wiki page here)

What's a good way to generate XML from vanilla Adobe CQ5?

My current implementation generates XML using JSPs, but the number of different record types I'm working with has grown and the number of JSP templates has become unwieldy to maintain.
So I coded up a solution using javax.xml.bind but quickly found that the code would compile but not run in OSGi. Long story short, there is a natively compiled dependency -- com.sun.* -- that is not included in the Felix boot classpath by default. Including this dependency is a matter of modifying sling.properties to include com.sun.* in the org.osgi.framework.bootdelegation config line. However, I'm working in a large corporate production environment so the thought of managing an extra configuration piece is not ideal.
So, the meat of my question: is there a better way to generate custom XML programmatically in Adobe CQ? Is there a different JAXB impl in the stack that I should be using, instead of javax.xml.bind? Is there another XML marshalling API that is more CQ/Felix friendly?
I've not got any concrete documentation on this yet, but it's possible to include com.sun.* without changing the Sling boot delegation.
I've done it in this pom.xml for a demo project using CXF in CQ5 as an OSGi service. It's either the <dependency> or the <Import-Package> in the maven-bundle-plugin.
The whole project is available on GitHub at https://github.com/antonyh/cq5-cxf - it builds, installs, and works without changes to boot delegation on CQ5.4 / CQ5.5.
CQ5.5 osgi bundles include org.apache.cocoon.cocoon-xml which exports packages:
org.apache.cocoon.xml.dom,version=2.0.0
org.apache.cocoon.xml.sax,version=2.0.0
Which are available for use in other osgi bundles or component jsp files.
For "vanilla" XML you can simply add a .xml extension to your content URL and an XML representation of the content will be output. This can be fetched by HTTP.

Lightweight Java web framework - specific requirements

The first time I encountered e.g. Ruby's Sinatra framework or PHP's Zend Framework, I wondered if there is something adequate in Java, it all seems so bloated here. Although there are myriads of frameworks around, I have found none so far that I deemed perfect for the kind of architecture I would like to implement.
I wanted to design a web application that would be heavy on the Javascript with most of the application logic implemented on the client, the Java back-end would more or less just serve as a data store or perform complex computations.
I did look through related questions here but I couldn't find the perfect answer, each of the suggested solutions had a quirk that would not match the requirements.
So this is what I am looking for, a open source framework with the following features:
Convention over Configuration
No XML configuration except for web.xml
Pure Java (no Scala, no Groovy, ...)
natural REST-style URLs such as /news/2011/july (no .do, no .jsp, ...)
REST-aware
it shouldn't force me to deploy on an application server (e.g. EJB should be optional)
session support would be nice but not mandatory
code generation as in Rails would be awesome but not mandatory
minimum of dependencies, small in overall size
MVC would be nice, but
I'd like to be able to choose the M part, choose the persistence libraries on my own (no bundling).
No automatically generated code for the view, neither HTML, Javascript, nor CSS
An integrated template language would be nice, but it should be minimalistic (simple control flow, access to template variables)
Layout support (i.e. you are able to specify a common template for similar views)
Free choice of Javascript framework for the views
Basically this would mean an MVC framework that does the routing for me and offers template support for the views, but the rest is fully modular, no magic. Is there any minimalistic framework that would provide this (or at least is modular enough to be configured that way)?
How about Play Framework?
Convention over Configuration
Play only has few configuration files. Most of its structure is by convention.
For example the basic structure goes like this:
|
+---/app - All executable artifacts go here (java files, conf files and view templates).
| |
| +---/model - Your model Java classes.
| |
| +---/view - Your view templates.
| |
| +---/controller - Your controller classes
|
|---/conf - Contains all configuration files for the application. Initially contains application configuration and routing table.
|
|---/lib - Libraries your appliaction needs. Added automatically to classpath.
|
|---/log
|
|---/public - Public stuff are your static assets that your server gives directly
|
|---/test
|
|---/tmp - All your temporarily compiled .class files are here
No XML configuration except for web.xml
Play has no XML configuration, including no web.xml. It has a Routing file instead. See the example below what it uses for routing.
Pure Java (no Scala, no Groovy, ...)
It's pure Java, but you can use Scala or Groovy through a plugin.
natural REST-style URLs such as /news/2011/july (no .do, no .jsp, ...)
REST-aware
From the site:
Play is a real "Share nothing" system. Ready for REST, it is easily scaled by running multiple instances of the same application on several servers.
In fact routing in a Rest like manner is quite easy:
# Play 'routes' configuration fileā€¦
# Method URL path Controller
GET / Application.index
GET /about Application.about
POST /item Item.addItem
GET /item/{id} Item.getItem
GET /item/{id}.pdf Item.getItemPdf
It's not hard to guess which goes where once you get used to Play a bit.
it shouldn't force me to deploy on an application server (e.g. EJB should be optional)
It doesn't. In fact you deploy by saving your files. EJB are completely optional and so are .war, .ear and other forms of deployment.
code generation as in Rails would be awesome but not mandatory
I don't think it does much code generation but I'm not 100% on that. It does automatically create all required folders and instantiate a basic example page. I don't know if Rails generates anything else...
MVC would be nice, but
- I'd like to be able to choose the M part, choose the persistence libraries on my own (no bundling).
- No automatically generated code for the view, neither HTML, Javascript, nor CSS
- An integrated template language would be nice, but it should be minimalistic (simple control flow,
See MVC in Play
Think this is a minor counter point. Play models must use JPA or extend certain Model class which comes with Play. See Play framework-model for more info.
It doesn't generate HTML though you can use your template language inside your .html,.css,.js and other files to create dynamic pages.
I has inbuilt template language based on Groovy template language e.g.
You have ${emails.unread ?: 'no'} ${emails.unread?.pluralize('email')} !
Other pros:
It's quite fun to programm in.
Did I mention the hotswap that allows you to redeploy your app by saving source files?
Great error logs.
Cons:
It's 51MB not sure if this qualifies as lightweight :/
I have used the Stripes framework on several projects in the past, and it sounds like it meets all/most of your criteria, especially the convention over configuration. There is no XML configuration- there is one stripes.properties file that has general behavioral configuration (it's a one time addition to your classpath). A one time edit to the web.xml is needed to configure the "Stripes Dispatcher", which is a Filter that routes requests to their appropriate action beans. ActionBeans are automatically discovered, so you do not have to even update your web.xml when you add more Action Beans. Your URLs are all set up using annotations on the action beans, rest supported, dynamic ActionBean bindings, Server-Side validation and conversion via built-in annotations for simple types, with the ability to create your own validation handlers and convertors for complex types. Works with JSPs and your custom JS/CSS libraries. Documentation and support forums are great. It's quick to learn if you follow their tutorial.
Spring Roo: I found it easy to start with. It can generate UI code but its up to you to use it.

Categories