In every Java project where I need to do strong cryptography, I run into these dreaded unreadable stacktraces which send you into the woods. After a long search I usually discover that the Unlimited Strength Java Cryptography Extensions are not installed. To prevent frustration of users of your software, you can simply add a bit of informative logging to help him/her solve it when the solution is known.
If you are using JAXB in a maven/java project to unmarshal an XML document and you get:
javax.xml.bind.UnmarshalException: unexpected element (uri:”urn:iso:std:somestuff:xsd:somestuff”, local:”Document”). Expected elements are (none)
Or if you are using JAXB to marshal an XML document and you get:
com.sun.istack.internal.SAXException2: unable to marshal type “generated.somestuff.Document” as an element because it is missing an @XmlRootElement annotation
You have probably fallen victim of the fact that JAXB does not do “Simple Binding” by default. If your project is a maven project and you generated classes based on an xsd file, this is how you fix it (without changing the xsd file):
When doing integration testing or fixing a bug in a piece of Java code that uses Oracle as a database, being able to do quick exports and imports of your schema can be a big help. Sometimes just calling Oracle’s imp/exp commandline tools from your code can be of help, but I was looking for something a bit more portable and less demanding on my local development machine. I found that Oracle’s datapump functionality can be called from stored procedures, which in turn can be called from a normal JDBC statement.
After reading my last blogpost on Anonimatron, you must have asked yourself “Great, but how do I actually use Anonimatron to de-personalize my database”? I tried my best to make basic Anonimatron configuration as self-explanatory as possible, just start it without any command line arguments and it will tell you.
Less adventurous or in a big hurry? This blogpost will show how simple it is to install and configure Anonimatron on an example MySQL database.
In every software project, there comes a time where a bug pops up, nobody knows how to reproduce it, and somebody says “I know, let’s test this against a copy of the production database”. Even with the best intentions, once production data leaves the production machine with all its safeguards it becomes really hard to do access control on that data.
Most of the time, it’s not even needed to have that data. Developers just need a data set which resembles the production scenario close enough. Some brave souls have mixed succes with data generators, but those generators usually are tedious to maintain and die a slow death under the pressure of the daily grind.
In some ambitious projects automated integration testcases are built on top of the data which was inserted by the data generators. As the generators die, so die the tests. If you recognize this pattern, Anonimatron might be the answer for you.
Suppose you have a Java Server application, and some of the runtime binaries in that application are external to your application. Generated image files, compiled Silverlight components in your pages, or resource files which are managed by an external team.
Much like the jar files used by your application, these external binaries can be seen as dependencies, with versions. This blogpost assumes your project is built with Maven 2, because the real world isn’t always a greenfield project.
Because Maven is designed around jar file dependencies, and a lot of it’s internal decisions are based on file extensions, it looks like this problem can not be tackled with Maven. But there is a way to do this. It will decouple your sub-projects and make version and dependency management much better.
In the project I am working on right now we use apache XCF and Spring to provide a SOAP service to our customers. As part of the messages, there is a userid/password combo telling the application which user sent the request. I struggled with that today because I think that userid/password info should actually be in the SOAP Header, cleaning up my API, enable me to implement different authentication techniques in the future and generally be more “compliant” to the SOAP standard. Boy was I wrong.