I recently needed to create an XML Schema XSD file from an existing XML file. A short research pointed me to Trang. Description from their website:
Trang, a program for converting between different schema languages, focused on RELAX NG; in particular, it can convert between the compact and XML syntaxes, it can convert between RELAX NG and DTDs, and it can convert from RELAX NG to W3C XML Schema
But beside the convertion between different schema languages, Trang is also able to create schemas based on XML files.
The creation of an XSD is done as follows for UTF-8 encoding using a JRE 1.5 or above:
Or, with explicit input and output format if the former command does not work as expected:
My new employer uses Subversion as the central
version control system, so I'm trying to take the first steps as my former employer
still used the good old CVS. (This also means that you don't find advanced infos
here but only novice infos.)
So, how to import an existing project to Subversion? I don't mind loosing the
history of the project, of course this makes the whole migration process a lot easier.
1. Create a Subversion repository
First, a central Subversion repository has to be created if it does not exist already:
2. Import an existing project to the trunk
So, let's import the project directory myproject to Subversion. I already
learned that the recommended structure should be as follows:
As in a non-Subversion project, the trunk, tags and branches directories
usually do not exist yet, they have to be created first. The import sequence for the project directory myproject becomes as follows:
As the Subversion repository is locally visible, I use the file:// schema.
Don't forget to add myproject to the last command or all files in svn_myproject
will be imported directly into the root directory of the repository.
You cannot work directly with the created myproject_svn directory above,
you first have to checkout it again:
3. Create a branch
Creating a branch is just a Subversion copy:
Here, the trunk/ directory is copied recursively in the working
directory brances/myproject-branch. The output of the command svn status
indicates that the directory is ready to be added to the repository.
The + says that branches/myproject-branch is just a copy and nothing new.
When commiting, Subversion creates the directory in the repository:
Subversion does not really copy all files, but just creates a new repository
entry pointing to the original tree, so this is also called a “cheap copy”.
Please refer to the Subversion documentation for more detailed infos.
The one step method without the need of a temporary directory is as follows:
Tired adding private static final Logger logger = Logger.getLogger(XXX.class); by hand to your Java classes?
Use Eclipse templates instead. Navigate to Windows -> Preferences -> Java -> Editor -> Templates. And add following new template to the Java context:
Finally, this should look as follows:
Now, if you are in the Java context, then type "logger" followed by "Ctrl+space". You are invited to choose from different templates including your template entered above:
After choosing the template, you ending up with an added logger plus the corresponding Java import:
Reading and writing UTC timestamps to a database when the default timezone may change. E.g., this might happen in an application server if an application running in the same JRE changes the default timezone as follows:
The easiest solution to solve this problem I know is to create an own mapping type extending the standard Hibernate timestamp type org.hibernate.type.TimestampType:
Use it as follows with Java annotations (you could use the type class also
in a XML configuration file):
Of course, this mapping class only works with Hibernate and is not standard JPA.
Ever got NULL entity entries from Hibernate? I did.
Having a table V_MEAS_SITE with following attributes:
The V_ in the table name indicates that this is a Oracle view and not a table.
This name follows our naming conventions. As the name of the view indicates,
the view is holding all information about measurement sites (I actually work
for the national weather service). This table is mapped to the following Java class:
Let's write an EJB session bean reading some data:
That's easy. OK, let's test this mapping with a JUnit test class:
However, this test fails. There are indeed some NULL entity entries in the list.
Hibernate must be broken! Of course, Hibernate is not broken. Do you see what went wrong?
I did after some time of debugging. The view catches content of different tables and is
therefore de-normalized. The primary key of the V_MEAS_SITE view is not MEAS_SITE_ID
but INSTALLATION_ID!
As a view has no explicit contraints there is no primary key constraint neither and therefore
you have no explicit indications about the "logic" in the data. In this case it means that
there are more than one entry for a given measurement site ID. And that's why Hibernate
returned the NULL values.
Of course it would be nice, if Hibernate had thrown some Exceptions to help
a careless Java developer...
By the way, Oracle DB allows to query the DLL statement: