jeveaux.com » Eclipse

Usando Working Sets no Eclipse

jeveaux — Tue, 30 Jun 2009 03:34:00 +0000

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

Crie, modifique ou remova qualquer working set.

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Um exemplo completo com JAAS

jeveaux — Wed, 25 Feb 2009 19:31:04 +0000

Devido ao um dos últimos posts deste blog, sobre utilização de JAAS com JDBC Realm e a grande procura por exemplos mais completos, com login e logout, por exemplo, resolvi melhorar um pouco a aplicação e disponibiliza-la para download.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Autenticação e Autorização: JAAS com JDBC Realm

jeveaux — Wed, 14 Jan 2009 00:53:32 +0000

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

A infra-estrutura (servidor e banco de dados)

O ponto chave para a configuração do JDBC Realm é o banco de dados (tabelas de usuário e grupos). Criaremos o schema com o SQL a seguir. Basicamente são apenas duas tabelas: usertable e grouptable.

A configuração do schema no realm será feita adiante e este exemplo está simples desta forma apenas para ficar o mais claro possível na configuração do realm. Certamente no seu caso você já terá suas tabelas de usuários e grupos e para usá-los basta fazer a configuração do realm de acordo com a sua realidade, alterando os valores das propriedades de configuração.

1
2
3
4
5
6

CREATE DATABASE learn_jaas;
USE learn_jaas;
CREATE TABLE usertable(userid VARCHAR(10) PRIMARY KEY, password VARCHAR(32) NOT NULL);
CREATE TABLE grouptable(userid VARCHAR(10), groupid VARCHAR(20) NOT NULL, PRIMARY KEY (userid, groupid));
ALTER TABLE grouptable ADD CONSTRAINT FK_USERID FOREIGN KEY(userid) REFERENCES usertable(userid);
COMMIT;

E agora vamos inserir alguns usuários e grupos para os testes, conforme o SQL abaixo. Os usuários serão: user, guest e admin e os grupos serão: users, e admins. Reparem que os grupos estão no plural, enquanto os usuários estão no singular. Este é um importante detalhe, a seguir, na configuração das roles usaremos os grupos para aplicar as regras e não os usuários.

1
2
3
4
5
6

INSERT INTO usertable VALUES ('user', 'user');
INSERT INTO grouptable VALUES ('user', 'users');
INSERT INTO usertable VALUES ('guest', 'guest');
INSERT INTO grouptable VALUES ('guest', 'users');
INSERT INTO usertable VALUES ('admin', 'admin');
INSERT INTO grouptable VALUES ('admin', 'admins');

Com o banco de dados pronto ainda precisamos de um passo antes do realm, precisaremos criar agora o Connection Pool e o DataSource para este banco de dados. O JNDI Name deste DataSource será usado na criação do realm, portanto, este passo é essencial para o funcionamento do exemplo. Entretanto, como o foco aqui não é a criação do DataSource, darei apenas o JNDI Name conforme usei no exemplo: learn-jaas-jdbc.

Agora só precisamos criar o realm, o nome usado para ele será learn-jaas-realm. No console do glassfish vamos em: Configuration >> Securiy >> Realm >> New. As propriedades deverão ser preenchidas de acordo com a imagem e a tabela abaixo (se o seu schema for diferente é só ajustar os valores):

Propriedade	Valor
jaas-context	jdbcRealm
datasource-jndi	learn-jaas-jdbc
user-table	usertable
user-name-column	userid
password-column	password
group-table	grouptable
group-name-column	groupid
digest-algorithm	none

A aplicação

Com a infra-estrutura necessária criada e funcionando, partiremos para a aplicação. Este será um ponto bem simples, a aplicação não terá nada além de 4 páginas JSP, web.xml e sun-web.xml. No Eclipse, criaremos um Dynamic Web Project usando o glassfish como servidor (JavaEE 5). As páginas citadas anteriormente ficarão dispostas conforme o projeto abaixo:

Em cada página index.jsp dos diretórios admin, public e users há um dizer assim: “Welcome Admin!”; “Welcome Guest!”; “Welcome User!”; respectivamente. E em /index.jsp há apenas os links para as demais páginas. Estes diretórios serão protegidos posteriormente.

O próximo passo consiste na criação das roles em nossa aplicação. Este costuma ser o ponto onde os iniciantes se confundem muito, por isso houve aquela distinção entre os nomes dos usuários e os grupos anteriormente. A criação das roles é livre, podemos criá-las como bem entendermos, o único ponto de atenção aqui é que a role é associada ao grupo, ou seja, uma role será aplicada para todos os usuários de um determinado grupo.

Então, em WEB-INF/sun-web.xml criaremos as roles associadas com os seus respectivos grupos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

user-role>

admins>

users>
>

admin-role>

admins>
>

guest-role>

admins>

users>

guests>
>

As roles foram criadas com o sufixo -role apenas para ficar bem claro que são roles e não usuários ou grupos. Vejam que as roles estão associadas aos grupos e não aos usuários.

Este é um momento onde aplicaremos as regras hierárquicas e organizacionais da empresa, repare que o grupo admins aparece em todas as roles, afinal de contas, não queremos barrar ao administrador do sistema o acesso às páginas públicas ou de usuários, certo?

Próximo passo: Configuração do web.xml! A configuração da autenticação em si não passa de 4 linhas de xml, informaremos o tipo (método) de autenticação (pode ser none, basic, form e digest/certificate) e qual o nome do realm associado:

1
2
3
4

BASIC>

learn-jaas-realm>
>

O que precisaremos agora é, com base nas roles, criar as regras de acesso na aplicação. Elas podem ser feitas de várias formas e como podemos usar URL Pattern para definir onde a regra será aplicada, faremos isso por diretórios, combinando os diretórios com as roles (admin, user e guest):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

paginas admnistrativas>

/admin/*>

GET>

POST>
>

admin-role>
>
>

paginas para usuários>

/users/*>

GET>

POST>
>

user-role>
>
>

paginas para visitantes>

/public/*>

GET>

POST>
>

guest-role>
>
>

Repare que o código ficou grande, mas é muito repetitivo. Os pontos de atenção são o elemento url-pattern, onde é gerada a regra para onde as restrições serão aplicadas e, principalmente, o elemento role-name, onde definimos qual a role está associada com aquela regra. Mais uma vez repare que a regra de acesso é associada à role, já a role, por sua vez está associada com um grupo, que por sua vez está associado com um usuário.

Agora é só fazer o deploy e executar o projeto. Lembre-se das senhas (ou consulte no banco de dados) e faça o teste de acesso em cada página.

Para facilitar disponibilizei o projeto para download, basta clicar aqui. (por algum motivo alheio a minha compreensão o wordpress não deixou o nome do arquivo igual ao original, então, baste colocar um ponto antes do ‘tar’, deve ficar project-to-learn-jass.tar.gz)

Eclipse 3.4 Ganymede

jeveaux — Sat, 28 Jun 2008 21:22:33 +0000

Esta semana foi anunciado o lançamento de um novo release do Eclipse, a versão 3.4, chamada agora de Ganymede.Vide Ganymede Moon, Ganymede Myth (um herói) e agora também Eclipse Ganymede, uma escolha legal para o Eclipse (pelo fato do herói :D).

Esta release anual do projeto Eclipse é chamada, por eles, de Annual Release Train. Isso devido ao fato de ser um lançamento coordenado de 23 (vinte e três) projetos que, juntos, compõem o Eclipse e mais de 18 milhões de linhas de código. Um bom exemplo de organização e disciplina.

Eu ainda não consegui migrar todos os meus projetos para o Eclipse, na verdade não abri a minha workspace principal com o Eclipse Ganymede ainda. Não, não é medo de dar algum problema, é que ainda não pude fechar o meu Eclipse Europa pra fazer isso, mas não passará deste final de semana. Em tempo, algumas coisas já consegui mudar para o Ganymede e já pude desfrutar de algumas novidades.

Dentre as coisas realmente novas as que eu mais gostei, e que com certeza serão as que mais impactarão no meu dia-a-dia do desenvolvimento são:

Aplicar formatação apenas nas linhas alteradas: Seguindo no menu Window> Preferences e depois em Java > Editor > Save Actions e habilitar a opção Format edited lines e pronto, dá próxima vez que você alterar alguma classe e usar a auto-formatação apenas as linhas que você alterou serão formatadas.
Drag & Drop no Outline View: Agora para cuidar da organização do código tudo pode ser feito através da View Outline apenas arrastando e soltando. Isso eu gostei muito.

Além destas muitas outras novidades acompanham esta release. A lista completa pode ser vista na página oficial da release e também no Eclipse Zone, que publicou uma notícia com muitas outras descobertas além destas que citei, vale a pena a leitura.

Migrando do Netbeans para o Eclipse

jeveaux — Tue, 10 Jun 2008 14:55:41 +0000

Há alguma semanas comecei a usar o Netbeans profissionalmente num dos projetos aqui da empresa. Já comentei sobre isso algumas vezes aqui no blog: aqui, aqui e aqui. Experiências com ferramentas novas (às vezes nem tão novas, afinal eu já conhecia o Netbeans há muito tempo, só não usava no trabalho) é sempre algo que gosto muito pois sempre rola muito aprendizado, melhora nossa visão e criticidade sobre uma série de pontos, e por aí vai.

E com o Netbeans não foi diferente, aprendi um pouco mais sobre detalhes da IDE, alguns atalhos, algumas manhas, também vivenciei alguns dos problemas que eu já conhecia e acabei por descobrir e sofrer com alguns outros novos. Após migrarmos para a versão 6.1 alguns novos problemas foram cruciais para a decisão da migração, como os mais importantes:

CVS
Com muita freqüência (principalmente com JSPs) o Netbeans não mostra o que há de novo ou modificado no repositório. É muito comum alguém fazer um commit de uma nova JSP, por exemplo, outra pessoa fazer um Show Changes e está JSP não aparecer na lista para o update. Às vezes conseguimos resolver fazendo direto um Update no projeto inteiro, mas não é sempre que funciona. Mesmo quando funciona há o inconveniente de estar fazendo um update às cegas, sem saber ao certo o que está vindo do repositório. Quando não funciona eu tenho que procurar o cara que colocou a JSP no projeto, pedir pra ele remover e inserir de novo, até funcionar.
Indexing
Sabe aqueles problemas horríveis que só acontecem de vez em quando ou que só acontecem com uma pessoa X ou Y? Pois é, depois da atualização do Netbeans, ~~algumas estações~~ praticamente todas as estações começaram a ter um problema desta espécie. Ao abrir a IDE perdia-se em média 3 minutos aguardando a conclusão da indexação do conteúdo do projeto, e não, nosso projeto não é um mega projeto. E isso não acontecia com todas as pessoas da equipe, apenas com alguns sortudos contemplados.

Como estes problemas impactam diretamente no ambiente de desenvolvimento como um todo e na integração da equipe não tivemos outra alternativa que não fosse a migração, e obviamente a IDE escolhida não poderia ser diferente, optamos pelo Eclipse :D

O processo de migração em si foi bem simples e não houve nenhum tipo de trauma. Não utilizamos ferramentas ou kits de migração, nada disso, tudo correu de forma de simples e convencional, porém muito funcional e útil.

A migração

Nosso ambiente no Netbeans era composto por dois projetos, que chamarei pelo nome fantasia de jujuba. Este era o nosso projeto web. E também tínhamos o projeto jujuba-ejb.

Como os nomes dos projetos não refletiam bem o que deve ser o projeto real do cliente nós aproveitamos a migração para arrumar isso. Então criamos num Eclipse um Enterprise Application Project chamado doceria e nele dois módulos: doceria-web e doceria-ejb, simples assim.

O primeiro passo foi conferir todas as dependências. Nesta momento vale um ponto para o Netbeans, bastaria associar o projeto a dependência desejada (jersey, pra REST, por exemplo) e pronto, tudo é feito para que o projeto compile e a API fique a sua disposição e o mesmo é feito durante o build e deploy, empacotando todas as dependências. Mas fizemos no Eclipse, pega-se os JARs, copia no web-inf/lib para o projeto web e pega-se os outros JARs, coloque-os no projeto ejb e configure se estes deverão fazer parte do EAR ou do JAR do EJB. Pronto, agora estão configuradas as dependências.

O restante foi super simples. O deploy dos dois projeto é feito no JBoss, configurar isso no Eclipse é completamente normal, apenas criamos um novo servidor no Eclipse, utilizando a instalação local do JBoss, depois bastou associar o projeto doceria ao JBoss e tudo já estava funcionando, aliás, por enquanto ainda era nada, pois os fontes ainda não haviam sido migrados.

A migração dos fontes foi a parte mais antiquada, porém a mais fácil, bastou copiar diretamente no sistema de arquivos:

Para o projeto web:

cd /home/jeveaux/development/java/workspace/doceria-web/src

cp -r /home/jeveaux/development/java/workspace/jujuba/src/java/* .

```
cd ../WebContent
```

cp -r /home/jeveaux/development/java/workspace/jujuba/web .

E para o projeto EJB

cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule

cp -r /home/jeveaux/development/java/workspace/jujuba-ejb/src/java/* .

cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule/META-INF

cp /home/jeveaux/development/java/workspace/jujuba-ejb/src/conf/ejb-jar.xml .

E pronto, foi isso, sem stress e sem complicações. Agora o projeto foi totalmente migrado para o Eclipse e está completamente funcional, igualzinho quando estávamos utilizando o Netbeans.