Excluding empty strings from hibernate example criterion

Hibernate example criterion is a useful tool for search functions. Altough it is highly configurable there is no built in function for exclude empty strings from your criteria. I found solutions in hibernate forums. The trick is creating your own property selector and set it to your example instance;

Take the Supernatural Character Quiz

Some more words on ScriptTagProxy and Restful Client with ExtJs

I wrote about ScriptTagProxy (STP) before [1]. AFAIK it is the only way to make cross domain calls in ExtJs. So at firt I thougt that it is also the only way to use cross domain Restful Web Services but using a Restful WS with ScriptTagProxy is impossible and here is why;

The working method of STP is simple. Under the hood it creates a script element in the document object [2]. Sets the URI of the script [3] and other stuff. Then it adds it adds it to the head element of the document, so browser get ( literally with GET method ) the script from another domain. Here is the code example that the logic is also used by ExtJs in the doRequest method of STP;

script = document.createElement('script');
  script.src = 'http://example.com/cgi-bin/jsonp?q=What+is+the+meaning+of+life%3F';
  script.id = 'JSONP';
  script.type = 'text/javascript';
  script.charset = 'utf-8';
  // Add the script to the head, upon which it will load and execute.
  var head = document.getElementsByTagName('head')[0];
  head.appendChild(script);

If you know a bit about Restful WS you already saw the problem. After head.appendChild browser GET the script. So there is nothing to do for using POST, PUT and delete method and there is no way to use a cross domain Restful WS with ExtJs. If you think using about XmlHttpRequest and Ajax manully there is also same problem as Patrick Donelan says;

Due to the Same Origin Policy that browsers impose on Javascript, the XmlHttpRequest object is prevented from communicating with external domains (it's an attempted security feature). There are known work-arounds, such as script tag injection (where you use the src attribute on html elements to trick the browser into communicating remotely) however this is limited to GET requests only so you're not going to be able to do much RESTful communication with it. (FYI this is implemented in Ext as the ScriptTagProxy class which is a drop-in for the HttpProxy class).
Your other options are to use Flash for cross-domain requests, or to wait for the W3C Access Control (which lets you make cross-site XmlHttpRequests) to be implemented by all the browsers.

It is posibble to make the request inside your domain to a java bean via JSP. But this is not a good workaround with performance issues also you can't use advantages of Ext.data.Store's restful features and you have to write and maintain so much code.

[1] http://dayonmars.blogspot.com/2010/07/extjs-calls-url-with-options-method.html
[2] You can read it as web page.
[3] Actually the script could be a data package which is surrounded by a functions name. For example; methodName("book": { "id": "1", "author": "Tom Clancy");

Referances;
http://neil.fraser.name/news/2009/07/27/
http://www.codeproject.com/KB/webservices/ExtJS_WebServices_Remote.asp
http://www.sencha.com/learn/Manual:RESTful_Web_Services

Benefits of @Repository annotation ( and Root of the hierarchy of data access exceptions ) in Spring Framework

There are a bunch of stereotype annotations in Spring. Most of time differences are not exactly known. For example we use @Component annotation for DAO classes for a long time in our company and it works. But we didn't know benefits of @Repository annotation till now.

If we want to summarize it, we can say that "By using @Repository annotation in DAO classes, different kinds of exceptions that belongs to many kinds of data access technologies will be transparently converted to standard DataAccessException classes of Spring"

Let's think about real life. In an enterprise project we may need more than one data access technologies like JPA, Hibernate or even JDBC. Each of them has its own benefits but all has their own exceptions. In that case exception handling can easily turns into a code hell.

Root of the hierarchy of data access exceptions adress this issue and gives us a bunch of classes that we can handle easily in a standart way. Thus we have a strong abstraction layer for data access exceptions and we can handle each exception case as we want.

Schema of data access exceptions classes is below;

[1] Root of the hierarchy of data access exceptions discussed in Expert One-On-One J2EE Design and Development. Please see Chapter 9 of this book for detailed discussion of the motivation for this package.

ExtJs calls url with OPTIONS method problem.

When I'm trying to create a Restful grid with ExtJs it calls url with OPTIONS method . I couldn't despite I explicityly define method as GET. After two days finally I find the solution ScriptTagProxy.

You can read explanation from ExtJs documentation;

"An implementation of Ext.data.DataProxy that reads a data object from a URL which may be in a domain other than the originating domain of the running page.

Note that if you are retrieving data from a page that is in a domain that is NOT the same as the originating domain of the running page, you must use this class, rather than HttpProxy."

But now there is another problem because documentation also says that;

The content passed back from a server resource requested by a ScriptTagProxy is executable JavaScript source code that is used as the source inside a script tag. In order for the browser to process the returned data, the server must wrap the data object with a call to a callback function, the name of which is passed as a parameter by the ScriptTagProxy.

 You have to send your data inside a  script. The name of the script is sending in the callback parameter of the URI like http://foo.com/bar?callback=methodName .

Spring test masking exceptions

Spring test module has lots of benefits. Bu some times it may be a bit confusing.

When Using spring test module it mostly produces only one exception for all exceptions. As below

java.lang.NoSuchMethodError:
org.junit.runner.notification.RunNotifier.testAborted(Lorg/junit/runner/Description;Ljava lang/Throwable;)V

exception masking all others and getting debug process harder for me. Finally I can figure out the problem. If you use spring 2.5.x series you have to use Junit 4.4 . If you use 3.0 then Junit 4.7 will suits for u.

"signer information does not match signer information of other classes in the same package" Error

I get this error when trying to test some of my new program prototype. And the reason was conflict of JUnit3 ( which comes with Hapi ) and JUnit4 ( which I've added manually ).

After removing Junit3 from may build path everything goes Ok.

Camel Mina and "java.lang.NoSuchFieldError: name" error

We decide to use IPF for HL7 processing validation and integration. If you think HAPI is not enough or a bit cumbersome for you IPF might be the solution you look for.

Anyway after reading tutorials I try to write an example app which uses Camel-mina component to listen tcp for messages. But there is strange error thrown by Surefire component. After googling and trying a few hours finally I can find the solution here. The problem is about dependencies camel-mina component depends on both mina-core 1.1.7  and slf4j 1.5.5 while the mina-core 1.1.7 itself depends on slf4j 1.4.3.

And the solution is reorganizing dependencies in pom.xml as below;

...

        <dependency>
            <groupId>org.apache.camel</groupId>
            <artifactId>camel-hl7</artifactId>
            <version>1.6.0</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.mina</groupId>
                    <artifactId>mina-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.apache.camel</groupId>
            <artifactId>camel-mina</artifactId>
            <version>1.6.0</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.mina</groupId>
                    <artifactId>mina-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.apache.mina</groupId>
            <artifactId>mina-core</artifactId>
            <version>1.1.7</version>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-simple</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>



...

Introduction to HAPI - 1

Explanation for HAPI packages;


ca.uhn.hl7v2.app

This package includes Application stuff.

From an HL7 messaging perspective, an Application is a consumer of a messages. Once a parser parses an incoming message, the message would normally be forwarded to an Application of some sort (e.g. a lab system) which would process the message in some way meaningful for it, and then return a response.

If you are wondering how to integrate HAPI into an existing server application, this is probably the place. Create a class that implements Application, then look at Responder and SimpleServer to see how to get HAPI to listen for messages on a socket and pass them to your Application.

ca.uhn.hl7v2.llp

This package includes stuff for working on a Lower Layer Protocol (LLP). And an implementation of "Minimal Lower Layer Protocol" from the HL7 Implementation Guide, Appendix C

The HL7 protocol will be used primarily in network environments. Most of the details of error detection and correction are handled by the lower levels of any reasonable network protocol and are not appropriate for the HL7 Standard. Many mini and mainframe computer systems, however, operate in communication environments that do not provide sufficient lower layer functionality.

In these cases HL7 offers severalalternate lower layer protocols to suit different environments. It is not a requirement of a vendor to implement any of these protocols to be considered HL7 compliant at the encoding rule level.

( See Health Level Seven Implementation Support Guide for further details on LLP. )


ca.uhn.hl7v2.view

This package includes only one class which is a Swing panel that displays the contents of
a Message object in a JTree. The tree currently only expands to the field level (components shown as one node).


ca.uhn.hl7v2.model

This package ( in the hapi-base-.jar ) includes interfaces, abstract classes and exceptions for HL7 data model.  İmplementation of data model is in the generated source jars.

ca.uhn.hl7v2.parser: This package includes a name which doesn't need an explanation :)

ca.uhn.hl7v2.preparser: This package includes classes extracts specified fields from unparsed messages.

ca.uhn.hl7v2.protocol: This package includes classws for HL7 comminication roles and backends.

ca.uhn.hl7v2.conf: This package includes stuff for parsing and validating conformance profile messages.

ca.uhn.hl7v2.validation: This package includes validation utilities for parsed and encoded messages.

ca.uhn.log: This package enhances logging for HAPI.