Unable to find org.hibernate.search.event.FullTextIndexEventListener on the classpath

If you get the following message on a Hibernate project:

204 [main] INFO org.hibernate.cfg.search.HibernateSearchEventListenerRegister - Unable to find org.hibernate.search.event.FullTextIndexEventListener on the           classpath. Hibernate Search is not enabled.                                                                 
that' because in some way  it was not possible to find the respective library that contains that class.
Check these two possibilities:

1. If using Eclipse, first refresh your project then go to the menu, preferences, build path, library tab.
Press the "add jar" button and point to your project's lib directory.
If it happens to appear any jar file that's because it was not registered on the classpath. Select all of them and press "ok button".
Return to your project and run again. Sometimes it's advisable to "clean" the project before just to make sure.

2. If the problem is not solved by the prior procedure, certainly the respective library is missing on your project's environment.
To solve this, first download the Hibernate's libraries at http://www.hibernate.org/downloads
For instance, the "hibernate-search-3.4.1.Final.tar.gz" or the zip version or choose a newer version if your project uses newer libraries or older version if the other way around.
Now, the fastest way is to copy the following files to your project's lib:

hibernate-search-3.4.1.Final.jar
hibernate-search-analyzers-3.4.1.Final.jar
hibernate-search-infinispan-3.4.1.Final.jar

Remember that you need to refresh you project and add the respective jars on the project's build path - see description on first procedure, above, and repeat it.

If after that you still get other error or warning messages that is about "missing things", do the following to solve this problem at once:

Select all the jars from the downloaded version of hibernate and copy them to a temporary folder.
Begin comparing the versions of all your project's jars with the temporary folder that contains the hibernate's jars.
Remember that the versions shall be compatible, so it's reasonable that the versions should be most close as possible, better if they match, when possible.
Replace your project's jar with the newest versions considering you project's version and complement with the other files that are missing. This procedure will help you to avoid having new problems in the future.
After all missing files were added to your project, refresh it and update the build path as commented above.
Remember that this procedure is valid for a Hibernate project.

You project will shall run without error/warning messages now.

NOTE:
If you use hibernate Annotations, you do not need to configure the event listeners, they are registered for you transparently.

Convert a PostgreSQL Database from LATIN1 to UTF8

At first I tried a procedure using iconv.
This procedure is described below and it was based on one found at http:/bryan-murdock.blogspot.com/2008/11/convert-postgresql-database-from-latin1.html
but unfortunately it didn't work for me.
So, I decided to try another alternative, that should be simple and fast, which is described here.

Procedure using editor's encoding and manual settings

Dump the database:
pg_dump -U postgres rental > rental/rental.dbs.out


Edit the file dumped on the prior step using an editor which has encoding features.
My default editor is SciTE and it was the editor that I used to do this.
Note: this editor has Windows and Linux versions.
On the editor, change the original encoding used for the file, switching to UTF-8, and "save as" the document with a new name.
Here, on this procedure I've saved it as "rental/rental.dbs.out.utf8".

After that, change the PostgreSQL's encoding on the same file.
You'll find something like this:
--
-- PostgreSQL database dump
--

SET client_encoding = 'LATIN1';
SET standard_conforming_strings = off;
...

Switch to:
--
-- PostgreSQL database dump
--

SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
...

Save the document and exit.
Remember, save it as UTF-8.

NOTE: if the dump file opens on the editor and shows gibberish and goofy signals instead of the normal data,
you must check your editor encoding or the procedure used to generate the dump file.
The text must appear legible as it should be.

Drop the old latin1 database:
dropdb rental

Log as postgres or another user with the necessary privileges:
psql -U posgres

Create the new utf-8 database:
create database rental with template = template0 owner = postgres encoding = 'utf8';

Connect to the new database created:
\c rental

Restore the converted dumped file - the one which you edited and saved as UTF-8 changing its encoding:
\i rental/rental.dbs.out.utf8

It's done.

Below, you find the final checking topic with the result obtained.


Handling Huge Files

But if the file is huge, for instance bigger than 300MB?
Using editors with huge files become difficult.
The solution is to split the file and when the procedure is finished, join the split files again.
To split you can you use cutf, a simple command line tool.
For help, just type cutf.

To append the files back, you can use:
On linux:
  cat file_to_append >> file_to_join  
On windows:
  type file_to_append >> file_to_join  

That's it.



Final checking

rental=# \c postgres
You are now connected to database "postgres".
postgres=# create database rental with template = template0 owner = postgres encoding = 'utf8';
CREATE DATABASE
postgres=# \c rental
You are now connected to database "rental".


rental=# show client_encoding;
client_encoding
-----------------
UTF8
(1 row)


rental=# show server_encoding;
server_encoding
-----------------
UTF8
(1 row)


rental=# select * from category;
cod_category | description
---------------+-------------------
1 | ação
2 | aventura
3 | biográficos
4 | comédia
5 | drama
6 | épicos
7 | espionagem
8 | fantasia
9 | ficção científica
10 | ficção histórica
11 | guerra




Attempt using iconv

Dump the database:
pg_dump -U postgres rental > rental/rental.dbs.out

Convert it to utf-8 with iconv:
iconv --from-code latin1 --to-code utf-8 rental/rental.dbs.out > rental/rental.dbs.out.utf8

Drop the old latin1 database:
dropdb rental

Created the new utf-8 database:
psql -U posgres
create database rental with template = template0 owner = postgres encoding = 'utf8';

Restore the converted backup:
psql -U postgres rental < rental/rental.dbs.out.utf8

>Before
postgres=# \l
List of databases
Name | Owner | Encoding
----------------+----------+----------
rental | postgres | LATIN1


rental=# select * from category;
cod_category | description
---------------+----------------------
1 | ação
2 | aventura
3 | biográficos
4 | comédia
5 | drama
6 | épicos
7 | espionagem
8 | fantasia
9 | ficção científica
10 | ficção histórica
11 | guerra

>After
rental=# \l
List of databases
Name | Owner | Encoding
----------------+----------+----------
rental | postgres | UTF8

rental=# select * from category;
cod_category | description
---------------+-------------------------------------------
1 | aÃ\u0083§Ã\u0083£o
2 | aventura
3 | biogrÃ\u0083¡ficos
4 | comÃ\u0083©dia
5 | drama
6 | Ã\u0083©picos
7 | espionagem
8 | fantasia
9 | ficÃ\u0083§Ã\u0083£o cientÃ\u0083­fica
10 | ficÃ\u0083§Ã\u0083£o histÃ\u0083³rica
11 | guerra

slf4j issues on JEE projects

The following errors have something in common - the slf4 library.




Each of them are commented, and probably you can find if your problem fits to one of them.




Example #1
SLF4J: Class path contains multiple SLF4J bindings.Criação inicial do objeto SessionFactory falhou. Erro: java.lang.NoSuchMethodError: org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder;

This is really simple to solve.
Search for two versions of slf4 libraries, like this:
project/lib/slf4j-api-1.6.1.jar
project/lib/slf4j-api.jar
Delete one of them, preferably the one which does not have the version number.

Example #2 - Running on Eclipse
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/servers/jboss-5.1.0.GA/common/lib/slf4j-jboss-logging.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/servers/jboss-5.1.0.GA/client/slf4j-jboss-logging.jar!/org/slf4j/impl/StaticLoggerBinder.class]


If the jar files listed above are not inside the project, try to find if you have some duplicated reference on the project's properties, like Build Path (Source,Project and Library tabs), Targeted Runtimes, etc.


For instance, if you have a reference to another project that also contains the same libraries, they'll conflict. The pictures below show a conflict between the project and the referenced project, the one added on Project tab.
You can have the same issue on the Library tab, if you added libraries from a server, for example.
Following the red arrows. Click over the picture to zoom.

The eclipse console will show an error message like this:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/alsdias/work/dev/servers/jboss-5.1.0.GA/common/lib/slf4j-jboss-logging.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/alsdias/work/dev/servers/jboss-5.1.0.GA/client/slf4j-jboss-logging.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.


If everything seems to be fine, but the problem is still there, the fastest way to solve a "ghost" reference is to create a new project, importing the code again.

Example #3
Hibernate: select nextval ('hibernate_sequence')
Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.event.PreInsertEvent.getSource()Lorg/hibernate/event/EventSource;
at org.hibernate.validator.event.ValidateEventListener.onPreInsert(ValidateEventListener.java:172)


Usually happens due incompatibilities with the project's library and the slf4 version.
Using annotations, this problem was solved switching these versions:
slf4j-api-1.5.10.jar
slf4j-simple-1.5.0.jar

by this one:
slf4j-api-1.6.1.jar


Example #4
17:39:03,260 INFO Configuration:1547 - Configured SessionFactory: null
...
anything else here


The 4th example leads us to a false conclusion - that the problem occurred due a null SessionFactory.
This is a common message and it is usually logged by the application during successful procedures, as shown in the example below,
which shows the output generated by a simple insertion of an entity on the database table.
Sometimes, it's the last message to be generated before the exception occurrence, and so, we may think that it is the cause.

In this case, check the version of the slf4.jar used on the project.
If using annotation, try this version:
slf4j-api-1.6.1.jar

Conclusion:
If you're getting these kinds of errors, try another version for your slf4..jar  before trying anything else.

For more details about slf4 error/warning messages, check http://www.slf4j.org/codes.html#StaticLoggerBinder

Example of successful procedure containing the "SessionFactory: null" message:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
17:39:02,870 INFO Environment:514 - Hibernate 3.2.6
17:39:02,876 INFO Environment:547 - hibernate.properties not found
17:39:02,879 INFO Environment:681 - Bytecode provider name : cglib
17:39:02,883 INFO Environment:598 - using JDK 1.4 java.sql.Timestamp handling
17:39:02,962 INFO Configuration:1432 - configuring from resource: hibernate.cfg.xml
17:39:02,963 INFO Configuration:1409 - Configuration resource: hibernate.cfg.xml
17:39:03,260 INFO Configuration:1547 - Configured SessionFactory: null
17:39:03,576 INFO DriverManagerConnectionProvider:41 - Using Hibernate built-in connection pool (not for production use!)
17:39:03,576 INFO DriverManagerConnectionProvider:42 - Hibernate connection pool size: 20
17:39:03,577 INFO DriverManagerConnectionProvider:45 - autocommit mode: false
17:39:03,588 INFO DriverManagerConnectionProvider:80 - using driver: org.postgresql.Driver at URL: jdbc:postgresql://localhost:5432/getit
17:39:03,589 INFO DriverManagerConnectionProvider:86 - connection properties: {user=postgres, password=****}
17:39:04,480 INFO SettingsFactory:89 - RDBMS: PostgreSQL, version: 8.3.7
17:39:04,481 INFO SettingsFactory:90 - JDBC driver: PostgreSQL Native Driver, version: PostgreSQL 8.4 JDBC3 (build 701)
17:39:04,661 INFO Dialect:152 - Using dialect: org.hibernate.dialect.PostgreSQLDialect
17:39:04,692 INFO TransactionFactoryFactory:31 - Using default transaction strategy (direct JDBC transactions)
17:39:04,706 INFO TransactionManagerLookupFactory:33 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
17:39:04,707 INFO SettingsFactory:143 - Automatic flush during beforeCompletion(): disabled
17:39:04,708 INFO SettingsFactory:147 - Automatic session close at end of transaction: disabled
17:39:04,708 INFO SettingsFactory:154 - JDBC batch size: 15
17:39:04,708 INFO SettingsFactory:157 - JDBC batch updates for versioned data: disabled
17:39:04,710 INFO SettingsFactory:162 - Scrollable result sets: enabled
17:39:04,711 INFO SettingsFactory:170 - JDBC3 getGeneratedKeys(): enabled
17:39:04,711 INFO SettingsFactory:178 - Connection release mode: auto
17:39:04,713 INFO SettingsFactory:205 - Default batch fetch size: 1
17:39:04,713 INFO SettingsFactory:209 - Generate SQL with comments: disabled
17:39:04,717 INFO SettingsFactory:213 - Order SQL updates by primary key: disabled
17:39:04,717 INFO SettingsFactory:217 - Order SQL inserts for batching: disabled
17:39:04,718 INFO SettingsFactory:386 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
17:39:04,721 INFO ASTQueryTranslatorFactory:24 - Using ASTQueryTranslatorFactory
17:39:04,722 INFO SettingsFactory:225 - Query language substitutions: {}
17:39:04,722 INFO SettingsFactory:230 - JPA-QL strict compliance: disabled
17:39:04,723 INFO SettingsFactory:235 - Second-level cache: enabled
17:39:04,723 INFO SettingsFactory:239 - Query cache: disabled
17:39:04,723 INFO SettingsFactory:373 - Cache provider: org.hibernate.cache.NoCacheProvider
17:39:04,729 INFO SettingsFactory:254 - Optimize cache for minimal puts: disabled
17:39:04,730 INFO SettingsFactory:263 - Structured second-level cache entries: disabled
17:39:04,741 INFO SettingsFactory:283 - Echoing all SQL to stdout
17:39:04,741 INFO SettingsFactory:290 - Statistics: disabled
17:39:04,741 INFO SettingsFactory:294 - Deleted entity synthetic identifier rollback: disabled
17:39:04,744 INFO SettingsFactory:309 - Default entity-mode: pojo
17:39:04,744 INFO SettingsFactory:313 - Named query checking : enabled
17:39:04,817 INFO SessionFactoryImpl:161 - building session factory
17:39:05,361 INFO SessionFactoryObjectFactory:82 - Not binding factory to JNDI, no JNDI name configured
Hibernate: select nextval ('hibernate_sequence')
Hibernate: insert into public.test (name, id) values (?, ?)

Base de Dados de CEP em MySQL, PostgreSQL e Dicas Adicionais

NOTE:
English is the usual language here on the purpose to increase sharing possibilities once it is an international language, however the information here is just about some specific brazilean stuff - the CEP, our USPC, so it was written in the native language.

Por esses dias andei precisando criar massa de dados em vários bancos com o propósito de testar performance e funcionalidades de uma aplicação. Quando esbarrei com a necessidade de carregar as tabelas de dados de CEP, naveguei a Internet por um longo período, encontrando todo tipo de informação menos o que eu realmente precisava - a base de dados do CEP.
Uma nota de indignação geral foi comum na maioria dos sítios(sites), reclamando o direito de obter-se o material de domínio público.
Afinal, o CEP até 2000, ainda era cedido sem restrições, posteriormente perdendo tal característica quando alterou o nome para DNE - Diretório Nacional de Endereços, segundo informação encontrada em http://www.vextenso.com.br/blog/55/banco-de-dados-com-os-ceps-do-brasil-retrocesso.html

Finalmente, em uma segunda tentativa inconformada, encontrei a informação necessária em http://republicavirtual.com.br/cep/index.php, cujo download fica  aqui.

Eu gostaria de agradecer o gesto do colega e o ótimo trabalho, tomando a liberdade de multiplicar tal gesto fazendo referência também aqui, no blog, e adicionando uma versão alternativa para PostgreSQL e MySQL.

Você pode encontrar os arquivos no link abaixo, já que aqueles que foram postados na nuvem sempre acabavam deletados.

https://ultering.com/it4us/Base de dados


DICAS

1. Disponibilizei um link alternativo dessa base original em MySQL(cep_mysql_sql.7z), com a alteração a seguir:
 `tp_logradouro` varchar(20) DEFAULT NULL,
foi alterado para
 `tp_logradouro` varchar(30) DEFAULT NULL,
devido a mensagem de erro ocasionado por campo maior em uma das tabelas.
O restante funcionou perfeitamente.

2. A versão em PostgreSQL foi dividida em arquivos menores e as linhas longas  foram quebradas em linhas menores, uma por registro.

Se o link estiver quebrado ou indisponível, mande um email para (alsdias@yahoo.com.br).

Essa alteração tem dois objetivos:
a) facilitar a edição do arquivo pois do contrário o editor fica pesado, lento.
b) facilitar também a localização de erros em eventuais mensagens de erro geradas pelo compilador do SGDB, pois percorrer um registro por linha é mais prático do que super extensas linhas, além de deixar o editor mais leve.


Se desejar, você pode executar as partes como se fossem um único arquivo criando um script que as referencie. É uma operação simples de inclusão de caminhos (paths).


Alternativa à Atualizaçao da Base de Dados

Em muitos sites encontrei a reclamação da dificuldade de atualizar a base pois o arquivo mdb estaria criptografado e só permite consultas manuais pela interface.

Nem tanto, você pode decodificar o arquivo mdb fazendo uma leitura binária e ter acesso à informação. Depois é só utilizar o famoso Ctrl+F (find) do seu editor, e lá está o que você deseja. Depois é só Ctrl+C e Ctrl+V.

O executável é um pequeno aplicativo em C(BinReader.tar.gz)  que faz este serviço para que se possa atualizar a base.

Basta digitar "BinReader.exe path_do_mdb".
O pequeno programa, embora simples, vai gerar um arquivo texto de leitura direta, apesar de "sujo", mas a informação pertinente é legível.

É um código simples, criado rapidamente para atender consultas que ficariam exclusivas pela interface gráfica, mas que transformadas em texto podem ser percorridas também por qualquer programa, ou manualmente, colhendo-se a informação complementar desejada.

NOTA:
Se houver link quebrado, mande um email para (alsdias@yahoo.com.br).