Bruno Pereira

Com a minha mudança de alocação da Globo.com para a Globosat, continuo trabalhando bastante com integração de aplicações, mas agora com um ferramental e paradigmas diferentes.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

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!

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!

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!

Eu já há um bom tempo utilizo o Linux como ambiente de trabalho em casa, e felizmente, há mais de 6 meses já tenho o prazer de usar Linux aqui na Globo.com também. Uma das coisas que me incomodava um pouco quando comecei a usar o Eclipse no Linux era a aparência do mesmo. O Eclipse por default no Linux não fica com uma interface muito legal, dependendo das fontes que você esteja usando no seu ambiente gráfico.Já há bastante tempo eu utilizo como a Tahoma tamanho 9 como fonte principal no KDE e também no Eclipse. Esta fonte me agrada bastante e com ela eu considero bem mais agradável o uso do Eclipse, comparando com as fontes padrão que vêm configuradas no Linux. Esta semana saiu um post no Planet Eclipse falando deste mesmo assunto, e eles mostraram uma configuração de fonte que o pessoal do JBoss utiliza para trabalhar.

Eu baixei as fontes Liberation que eles usam e fiz um teste aqui para ver se gostava ou não da aparência. Realmente essa fonte que eles usam é bem legal, e eu cheguei a ficar em dúvida se mantinha a Tahoma ou se mudava para Liberation. Claro que esta é uma decisão de gosto pessoal, cada um tem suas preferências, e eu por enquanto estou mantendo Tahoma, pois já estou bastante acostumado e satisfeito com ela.

Para que vocês possam ver a diferença, seguem abaixo dois screenshots do Eclipse rodando aqui no Kubuntu, o primeiro delas com o uso da Tahoma 9 como fonte do Eclipse e fonte do editor Java e o segundo com o uso da Liberation Sans tamanho 10 (o tamanho 9 aqui estava com a largura estranha para algumas letras).

E aí, de qual vocês gostaram mais?? Eu não consigo me decidir sobre qual fica mais interessante pra mim, então estou mantendo o time vencedor com Tahoma.
OBS: A renderização das fontes varia de um sistema operacional pro outro, e no Eclipse no Windows eu não gosto da aparência da fonte Tahoma, e mantenho as configurações de fontes padrão do Eclipse no Windows, pois elas são satisfatórias pra mim (e afinal de contas, eu quase não uso Windows, não faz muita diferença… hehehe).

Update: Para melhorar MUITO o espaçamento das linhas no package explorer, navigator e outras views estilo Árvore, recomendo a criação do arquivo .gtkrc-2.0 no seu diretório home, com o seguinte conteúdo (experimente este conteúdo primeiro, e então modifique o que achar interessante) :

style "gtkcompact" {
font_name="Sans 8"
GtkButton::default_border={0,0,0,0}
GtkButton::default_outside_border={0,0,0,0}
GtkButtonBox::child_min_width=0
GtkButtonBox::child_min_heigth=0
GtkButtonBox::child_internal_pad_x=0
GtkButtonBox::child_internal_pad_y=0
GtkMenu::vertical-padding=1
GtkMenuBar::internal_padding=0
GtkMenuItem::horizontal_padding=4
GtkToolbar::internal-padding=0
GtkToolbar::space-size=0
GtkOptionMenu::indicator_size=0
GtkOptionMenu::indicator_spacing=0
GtkPaned::handle_size=4
GtkRange::trough_border=0
GtkRange::stepper_spacing=0
GtkScale::value_spacing=0
GtkScrolledWindow::scrollbar_spacing=0
GtkExpander::expander_size=10
GtkExpander::expander_spacing=0
GtkTreeView::vertical-separator=0
GtkTreeView::horizontal-separator=0
GtkTreeView::expander-size=8
GtkTreeView::fixed-height-mode=TRUE
GtkWidget::focus_padding=0
}
class "GtkWidget" style "gtkcompact"
style "gtkcompactextra" {
xthickness=0
ythickness=0
}
class "GtkButton" style "gtkcompactextra"
class "GtkToolbar" style "gtkcompactextra"
class "GtkPaned" style "gtkcompactextra"


Just beginning 2008, I went to a new area, new team at Globo.com. There are several promising projects for this year, and this team switch will make it easier for me to properly evaluate and judge what I consider the 2 leading Java web frameworks nowadays.Like I said here, on my spare time I (try to) develop a lawyer application which uses Apache Wicket as its web framework. One of the projects I’m now working at Globo.com uses Java Server Faces. This should be a great opportunity to finally go deeply on both frameworks and see in which cases each one is better than the other. Based on what i have already studied and used of both, i do have some opinions that may or may not change several months from now.

First, a little background. When i was studying to pass the SCWCD exam, I saw enough of tag libraries to get really sick of them JSTL, Struts 1.x Taglib, Expression Language, etc etc etc. Every new taglib was a new syntax to learn, and the result of using taglibs to implement complex web pages is the famous tag soup. Not being a purist, although I don’t like scriptlets in general, I do think that in some cases they produce much cleaner code than the heavy use of taglibs.

Having said that, let’s start talking about JSF. Being a standard technology backed by Sun, and present on Java EE 5 specifications, you know that you’re gonna find plenty of support by development tools, many examples on the web and an already mature community of users to help you. JSF offers a huge set of components ready to use, and many of them are very pretty and easy to use. In my case, we’re using JBoss Tools + Rich Faces, and the Eclipse plugins avaiable here are just awesome.

Most of the web applications I have worked until now used Struts 1.x, and although Struts is by far the most successful Java web framework til now, developing with JSF is reasonably easier and more pleasant. However, even considering the clear evolution of JSF over Struts 1.x, I still qualify both within the same paradigm. That is, both have a massive dose of non-markup code in their views, and if you’re gonna work with them, you better have your spoon ready to dig into the tag soup Ok, ok, JSF offers very nice components and manages a lot of the work that was left to the developer in the old times, such as managing the application state and offering a beautiful presentation layer without requiring the direct manipulation of javascript. But you’re still going to have your view layer full of taglibs, coding in a special syntax (the custom tags syntax) that will make it tough to track for problems when they happen within the tag soup. You better have a magical spoon to manipulate it

Rather new in the Java web frameworks field is the very innovative Apache Wicket project. Wicket allows Java programmers to focus on what they do best: write Java code. No taglibs, how refreshing! Wicket also uses componentized development, and it isolates the view from your model in the best manner I have seen til now in Java frameworks. It does not seem so intuitive in the beginning, because you code for a web application in a similar way as you would code a Swing application. Specifically the component’s event handling code in Wicket reminds me a lot of the approach used in Swing applications.

Being a new framework that went out of the Apache incubation just several months ago, you can’t expect great tooling support at this point. Drag and drop tools to design screens? Forget about it! Component options similar to JSF ones? You’re not gonna find it either. However, Wicket has a very active community and it’s evolving fast. The second book on Wicket will be avaiable in a few months and the number of users and successful implementations is growing steadily. The set of avaiable components is growing and it’s becoming much easier to find support in their forums.

As I said, I’m far from an expert in both frameworks, and I hope this year I’ll have a long enough exposure to them and probably in a few months I’ll have more valuable opinions. Something I think about is that perhaps knowing Wicket and JSF well can be really useful, because it doesn’t seem like we have a “one size fits all” choice here. Wicket seems great for a company to base its developments and have good and maintainable code that will be easy to build over for several years. JSF certainly can offer that too, but i find it tough to consider taglib code as easy to maintain. However, JSF offers such great components that even a Java developer like me with no talent to create good looking pages is able to generate a very decent user interface.

I’ll confess I have a natural preference for Wicket since the beginning, but I promise I’ll try to evaluate these 2 options without any passion during this year and later this year I’ll post again telling my conclusions (if any)

My friend Bairos provides me a Subversion repository and a Trac server, and I use both for personal projects.In my job, our issue tracker is JIRA, and I’m using it with Mylyn for several months. However, just recently i started using Mylyn with Trac, in a project I’m developing at home. The Trac server I’m using doesn’t have the XmlRpc plugin, so I’m not able to use Mylyn’s rich task editor with this server, and I faced some problems using the web task editor inside Eclipse on Linux.

Every time i tried to open the task editor, i was getting the following error message: “Could not create Browser page: XPCOM error -2147221164″. I’m not going to detail my analysis of this error, but I was able to fix it installing the packages xulrunner and xulrunner-gnome-support (I’m not sure if both are needed, though).

From my google searches, I could see that this error happens with a lot of applications on Linux, so probably several people using the Trac Connector with the web task editor on Linux faced the same problem. I hope this tip can help.

Just for the records, my environment here is: MEPIS Linux 7.0, Eclipse 3.3.1 with WTP, JDK 1.6.0_03 32 bits, Mylyn 2.2 and Trac 0.10.4