Bruno Pereira

I gave up using m2eclipse with Eclipse Ganymede. That’s not premature. I tried my best to figure out a way to use the plugin in a reliable way. However, that’s over now, I quit!

The plugin would be great and extremely useful if it worked. Really, I’d love to have this plugin as an everyday tool, helping me deliver software. It offers a very productive way to work with Maven in Eclipse, except that it brakes Eclipse in such an unbearable way that I cannot afford to think about using it anymore.

Initially I was using m2eclipse with an external Maven installation, instead of the embedded one. With this setup, I was facing many (and I mean MANY) NullPointerExceptions doing some Maven stuff in the IDE. It was impossible to work with that much errors, so I tried using the embedded Maven installation.

Initially it seemed like I was gonna be able to work without problems, but I was wrong. Instead of all the NullPointerExceptions, now Eclipse itself would crash hard when I used the POM editor. Adding a dependency, adding a new build plugin. I was frequently having Eclipse crashes doing this stuff.

I first thought that it could be just an issue in the “graphical” POM editor, so I tried using the simple XML editor. The errors kept occuring, and I got mad.

I could live with this problem if my Eclipse crashed 2 or 3 times a day. I’d gladly restart it, and keep working. However, facing Eclipse crashes every 5-10 minutes can make you crazy before you deliver any piece of software.

I am a man of faith, so I’ll try using it with Eclipse Europa and with minimal features, to see if it hangs on. I use this setup at work, and although it doesn’t work perfectly, at least it stands a whole day without crashing.

Maven is such a widespread Java tool. It’s far from unanymous among developers, but it’s a very valuable tool for me. I think it deserves much better tooling support, so I hope this Ganymede mess is fixed someday. But maybe the Eclipse ecosystem got so complex that it’s becoming impossible to keep everything stable.

I’ve tried using Netbeans before, but I couldn’t be nearly as productive as I am with Eclipse. So please Eclipse, please don’t let me down!

Li recentemente uma matéria que fez um estudo interessante sobre a situação atual do uso de algumas das principais distribuições Linux. O estudo não utilizou uma metodologia exatamente científica, mas as conclusões não deixam de ser válidas.

O estudo observa uma tendência de que o Ubuntu seja cada vez mais a cara do Linux. Na verdade parece que a “marca” Ubuntu está com um progresso muito mais vigoroso do que a “marca” Linux, e provavelmente em breve a “marca” Ubuntu será a mais forte das duas.

Eu particularmente acho isso muito bom. Durante muitos anos o percentual de uso das principais distribuições Linux foi muito pulverizado. Havia uma gama enorme de opções, e não havia uma concentração tão forte em torno de nenhuma delas. É verdade que o Red Hat teve uns momentos muito bons até a versão 9 (última versão gratuita), mas depois que eles mudaram o modelo comercial, perderam muitos usuários caseiros.

Com a concentração em torno do Ubuntu/Kubuntu, acho que as chances de sucesso do Linux no desktop de usuários comuns aumentam muito. Um facilitador muito importante no rápido crescimento do Windows foi que muitas pessoas o conheciam, e então eram capazes de orientar novos usuários e ajudar na solução de problemas de forma rápida. Isso é muito mais fácil quando se tem um sistema operacional e interfaces de usuário com o mesmo padrão.

Se tivéssemos a grande maioria dos usuários Linux usando Ubuntu/Kubuntu, ficaria muito mais fácil que novos usuários tivessem facilidade em encontrar ajuda. Isso diminuiria muito as barreiras de entrada no uso do Linux em computadores caseiros por pessoas leigas.

É claro que continuarão existindo outras distribuições, mas com um foco direcionado em públicos específicos, ou finalidades específicas. Não há nada de errado em ter muitas opções, mas a adoção do Ubuntu como padrão facilitaria muito as coisas.

Uma coisa que eu não consigo entender é o que fazem algumas montadoras de computadores no Brasil. Já cansei de ver computadores com Linux à venda em supermercados e lojas em geral. Isso é legal de se ver. Porém, cada fabricante diferente (e são vários) usa uma distribuição diferente, e pouco comum. Isso com certeza dificulta muito o aprendizado de novos usuários Linux, e o que acaba acontecendo é que as pessoas mais humildes compram cópias piratas do Windows e instalam em suas máquinas que vieram com Linux.

Será que não seria mais fácil a Itautec, Positivo, CCE, etc etc etc, simplesmente usarem o Ubuntu/Kubuntu e customizarem só uma ou outra coisinha? Porque instalar umas distribuições que ninguém nunca viu, e que dificultam muito mais a vida dos usuários?

Será que isso é para conseguir vender suporte? Se for, acho que isso é um tremendo tiro no pé, pois as empresas correm um enorme risco de que as pessoas nem comprem os seus produtos ou então simplesmente troquem o Linux que veio instalado por um Windows piratão.

O sucesso do Linux no desktop do povão pode ser muito ajudado pelo sucesso do Ubuntu, então eu fico muito feliz com o crescimento vigoroso que este vem tendo. Só torço para que as montadoras de PCs nacionais acordem e passem a disponibilizar o Ubuntu em vez de umas distribuições sem-vergonha que ninguém conhece e que ninguém vai usar.

Ajude o Linux e o Open Source no Brasil. Use e divulgue uma distribuição que até o nosso presidente saiba falar! Ubuntu!

This Saturday I installed Kubuntu 8.10 (Intrepid Ibex) on my home desktop, and finally got my hands on KDE 4.1.

This is not the first time I tried KDE 4, as I had installed Kubuntu 8.04 (Hardy Heron) with KDE 4 several months ago, but I didn’t like it by that time. Kubuntu 8.04 had a version with KDE 4.0, but at that version, KDE 4 looked more like a new concept than a “real deal” window manager. KDE 4.0 was released to gather feedback and to help developments on top of it. It wasn’t meant to be used by end users, so I sticked with rock solid KDE 3.5 for some more time.

Well, with KDE 4, we now have the real deal. Although it took me a couple of hours to do the mental shift from the previous version to this new one, I’m now enjoying it a lot. Regarding usability, the most noticeable feature consists in the “Plasmoids“, which are desktop widgets. These widgets are very similar to those present in Windows Vista, except that they don’t weigh a ton like its Vista brothers. Actually, KDE 4 performance seems to be similar to KDE 3, which is nice, since it’s better than Gnome’s and much better than Vista’s. KDE performance is similar to Windows XP desktop, so it runs pretty well in any machine built in the last 5 or 6 years.

In the picture below, you can see that I’m using some Plasmoids, like the Notes, the folder view (featuring my Desktop content) and a useful Dictionary plasmoid. I could think of several useful plasmoids, like Wikipedia and calendar plasmoids, and I’m pretty sure they’ll be avaiable some time from now. There are many plasmoids already avaiable at KDE-look, but from what I could see they’re still mostly beta and need a bit more work. But it’s indeed promising.

If you’re already a KDE user, I definitely recommend you take a look at this new version of the window manager. If you’re still a Gnome user, waste no time and get yourself a KDE desktop! :)  If you’re not using Linux yet, well… nevermind.

Yesterday the JSR-311 (Java API for RESTFul Web Services - JAX-RS) was finally approved!

I’m using Jersey (the JSR’s reference implementation) for more than 6 months and I was anxious to have the specification approved.

In my team we’re currently using Jersey 0.7 in production, and were waiting for the JSR to be approved to analyse the final version of its implementations. Now we’ll wait for both Jersey and JBoss RESTEasy to release their final versions and we’ll analyse both to see which one we’ll use in our RESTFul services.

If anyone wants to give me good reasons to use either one of the implementations, now it’s the perfect time! I’m hearing…

After some extra effort today, I did manage to get WSO2 Registry working in JBoss 4.0.5

The huge amount of jdbc error messages in the server logs were not actually errors. JBoss datasources have a configuration element called <track-statements>. When this option is turned on, JBoss logs massively when there are Statements or ResultSets that are left open. The application server closes the Statements and the ResultSets, and shows many many logs indicating this. The log messages I was seeing were not errors in the Registry, they were only JBoss warnings.

All our datasources in my team have this option turned on, and we always take care to close the ResultSets and Statements in all our applications. But since the server closes the ResultSets and Statements, I can live with the way the Registry does

I had to do some things to get the Registry working in JBoss. First, I had to remove the log4j the Registry had packed inside its war file. Our JBoss servers use the Unified Classloader, for several years already. This setup was there before I even joined the company, and it’d complicated to change this now, because it’d make us modify several applications. Not being able to change the Classloader, the log4j packed inside the Registry (1.2.13) would conflict with the one present in JBoss itself (1.2.8), so I had to remove it from the Registry’s war. The application worked just fine using log4j 1.2.8, so it’s ok to do this.

After fixing this, I had to enable Java 1.5 code in the jsps. JBoss by default does not allow Java 1.5 code in the jsps, and to modify this, I had to uncomment the code below inside JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/conf/web.xml:

<init-param>
<param-name>compilerSourceVM</param-name>
<param-value>1.5</param-value>
</init-param>

This init-param belongs to <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>, and solves the jsp compilation problem.

Well, that’s what I had to do to make WSO2 Registry work in JBoss. Most of the problems I faced were not Registry’s fault, so I’m sorry for having a wrong impression after some setup problems this week.

I’m currently integrating WSO2 Registry in our architecture and once I finish, I’ll document our architecture here, so that other people can see what uses we’re making of the product.

Well, as I said recently, we want to use a registry to keep URIs of our services and also some configurations that are currently in properties files.

After looking better at WSO2 Registry, I figured out how to do what I need with the product. I had a very short time to evaluate properly WSO2 Registry and Mule Galaxy before my last post, but after another evaluation of them, I concluded I can use them in this case.

Last week I developed a Java client to consume my publications from WSO2 Registry. It wasn’t much fun to develop, because I had to make it compatible with JDK 1.4. This prevented me from using their client API, which runs only on JDK 1.5 and above.

Since I had to use JDK 1.4, I used XStream for my Java <-> XML mappings. Not being able to use the Registry’s Java client, I also had to consume data from their AtomPub API. I used Apache Abdera 0.3 for this task, which was their last version supporting JDK 1.4 (through retroweaver).

So far so good. Last week I had a prototype client consuming stuff from the Registry, so I moved on to some other tasks. Well, today I started integrating the Registry in my application. That meant moving from Tomcat 6 to JBoss 4.0.5. And that’s when I got in trouble.

Unfortunately I hadn’t seen this page before. It turns out that the only application server they have tested enough is Tomcat. And not any Tomcat, only Tomcat 6. Since their distribution format is a .war file, I never would think they support only Tomcat. In their download page it says: “This distribution includes the Webapp module with relevant JAR files and other resources to be deployed in the servlet container, providing a Web UI and an APP interface.”

Well, I’m probably just dumb. They didn’t say “a servlet container“. They said “the servlet container“. This certainly means “the servlet container we support, which is Tomcat 6″. But this is not written there, so dumb people like me will be subject to mistakes.

“Heck, this is open source, I’m gonna make it work on JBoss!”. This was my first thought. And then I started setting up the Registry in JBoss, right after lunch today.

The first thing I noticed is that the Registry packs a newer version (1.2.13) of log4j than the one present in JBoss (1.2.8). This shouldn’t be a problem, but anyone who has experienced some of the JBoss Classloader Hell knows that it’s not a wise decision to bring a newer version of log4j inside your application if you’re going to run on JBoss. This is not a Registry fault, so I gladly fixed the problem by removing the log4j they had packed inside the .war file.

After fixing this, I was gettings errors trying to open the Registry’s index page on JBoss. I quickly found out that their jsps had scriptlets using JDK 1.5 code, and JBoss was not able to compile the jsps. This was easy to fix by uncommenting a init-param in the web.xml in the Tomcat module inside JBoss. However, the amount of scriplets inside their pages was the first symptom that something didn’t smell right.

After fixing the jsp problem, I configured the Registry to connect to MySql through a JBoss datasource. I then could open their index page and even use some features. However, when I started checking the server logs I was shocked. A huge amount of errors in jdbc operations. I had no clue of what was going wrong, because the UI was apparently working normally and the database was being manipulated.

Well, since it’s an open source product, I promptly checked out their code and started looking for problems. Most errors occured in simple jdbc operations like the creation of a prepared statement. The application logs were not very helpful, and I couldn’t figure out where the problem was.

However, something scared me a lot. Between the zillions of jdbc errors, I saw JBoss screaming for help, saying that the PreparedStatements were left open. I went to look at their jdbc code, and it definitely needs care. There were a LOT of jdbc operations inside try/catch blocks, where they treated SQLExceptions. I didn’t see the finally blocks closing the PreparedStatements and the ResultSets. This explains JBoss’s complaints about the PreparedStatements.

After several hours trying to use WSO2 Registry inside JBoss and looking at their code, I must say I am VERY discouraged to put anything in production right now using the product.

I just downloaded Mule Galaxy and now I’m gonna try to integrate it in my application. A very good sign is that they say I can use it with ANY servlet container, including Tomcat and Jetty. I think it’ll be a successful effort, but it’s hard to say anything after my problems with WSO2 Registry today.

But knowing Dan Diephouse’s work for several years, I’m pretty confident in this new attempt. I’ll post the results later this week.

Como eu havia falado, esta terça-feira eu me apresentei no evento do aniversário do CEJUG.

Foi uma ocasião muito legal. Além de conhecer a rapaziada do grupo, eu também conheci a cidade de Fortaleza e já voltei para casa querendo retornar mais vezes ao Ceará. Do CEJUG eu conheci o Rafael Carneiro, Silveira,  Milfont, Tarso, Rafael “Foquinha” Ponte, Handerson, Igo, René, Paulo, Tales, Marum e mais alguns que eu esqueci o nome

Como eu já esperava o pessoal me recebeu muito bem e foi muito bacana conhecê-los pessoalmente. Além disso, já sou agora conhecedor de uma vasta gama de termos genuinamente cearenses :)  Diabéisso maxo!

Além de conhecer o pessoal do CEJUG, também tive a oportunidade de conhecer o Maurício Leal e o Kohsuke, ambos da Sun. Ambos são muito simpáticos e me passaram uma idéia legal de bastante coisa que está rolando na Sun.

O Kohsuke é também provavelmente o cara de mais prestígio técnico que já conheci, pois é nada menos que o criador do Hudson e um dos principais responsáveis pelo JAXB e pelo Glassfish v3. Inclusive uma das coisas mais marcantes da participação dele no evento foi trazer a todos o desejo de conhecer melhor o Glassfish e acompanhar as grandes novidades prometidas para esta nova versão. Uma das coisas que mais me interessou é a arquitetura modular com o Osgi. Eles estão apostando no Osgi junto com o Eclipse, e isto me trouxe a curiosidade de conhecer mais detalhes da tecnologia.

Bom, para destacar ainda mais a hospitalidade do pessoal, eles ainda me deram uma cesta recheada de ítens característicos cearenses. Gostei bastante dos presentes e quem quiser degustar a mais pura Ypioca aqui no Rio é só falar comigo

O evento em si foi bem legal e ainda teve uma banda animando o intervalo. Os coitados deram o azar de tocar logo na hora que o povo foi correndo comer, mas quem ficou assistindo curtiu bastante

Depois das palestras, bastante gente foi na confraternização e a bagunça lá foi até depois de meia-noite.

Para finalizar, eu gostaria de agradecer a todo o pessoal da organização lá em Fortaleza e também ao Gaúcho e ao Hildeberto por fazerem um evento tão legal e continuamente levar o CEJUG às cabeças. Esse tipo de comunidade traz uma enorme força ao mercado de software nacional e seria excelente que tivéssemos outros grupos com tanta energia como o do Ceará. Agradeço muito pela oportunidade e deixo meus parabéns à comunidade de software cearense!