Esse erro acontece que nas libs do JBoss já existe a mesma biblioteca. Quando é feito o deploy, ou executado standalone, esse erro acontece. Não adianta remover a lib do classpath da aplicação. Pode ater dar certo mas, se sua aplicação depende dela, talvez os testes automatizados não sejam executados corretamente.

Para solucionar esse problema em uma aplicação web simples, é necessário informar ao JBoss que essa lib é necessária para o projeto. Para isso, é só incluir a linha abaixo no arquivo MANIFEST.MF: Dependencies: org.dom4j. No momento do deploy o JBoss ler esse arquivo para tentar encontrar diretivas utilizadas para gerenciar o ClassLoader da aplicação e gerenciar a dependência de módulos.

Espero ter ajudado.

Nesse caso, a melhor ferramenta é a nossa cachola. Encontrei nesse blog um número repleto de dicas para solucionar os problemas de Anti-Pattern que utilizamos no dia-dia. Desde dicas de performance até soluções para determinados problemas. Vale a pena dar uma olhada. Odi’s Blog.

Recentemente, foi disponibilizada a relase 2 do versão 7 do AS, porem, a questão a ser tratada é a reformulação da estrutura do produto em comparação com as versões anteriores. O time de desenvolvimento praticamente refez todo o core do servidor, modificando desde a estrutura de carregamento das classes (classe loadin) até a forma de gerenciamento de dependência.

A interface de administração, apesar de não ser o forte deles, está mais limpa e direta. Através dele é possível ter total informação do que está instalado no servidor, datasources, módulos, dependências,  web services, etc. Lembro que no JBoss 5/6 havia uma interface que mostrava os webservices que estavam disponíveis na aplicação. Nessa versão, esse tipo de informação está disponível na própria interface de administração.

- VELOCIDADE AO SUBIR

Alguns pontos que se destacaram logo a primeira vista, entre esses, o mais perceptível é a velocidade que o JBoss é iniciado. Ao verificar os detalhes, me deparei na principal mudança ocorrida no núcleo do servidor. Ele está trabalhando inteiramente com OSGI, ou seja, no momento do boot o servidor sobe apenas os módulos necessários para tal. Esses elementos são lidos no arquivo de configuração domain.xml ou standalone.xml respectivamente.

Isso justifica o fator da velocidade de carregamento. Porém, quando for necessário incluir mais um módulo que sua aplicação necessite, um REST ou um Web Service tradicional por exemplo, será necessário editar o arquivo de configuração para que o módulo seja incluso.

- OS MÓDULOS

Essa informação está bem explícitas nos arquivos de configuração das instâncias, logo na primeira sessão está presente as extensões necessárias para o funcionamento da instância. Mais embaixo, quase no fim do documento, estão os módulos.

Os drivers de conexão JDBC são também tratados como módulos. Portanto, para utilizar um driver de conexão com um determinado banco de dados, será necessário incluí-lo como um módulo e importa-lo do projeto. Isso é feito criando uma hierarquia de diretórios, adicionar o jar do driver no diretório main, conforme o padrão, e criar um documento de descrição do módulo em questão, como o exemplo abaixo:

- INSTÂNCIA

A versão 7 suporta uma característica muito útil que para organizar as aplicações. O conceito de instância. Quem já trabalhou com o Oralce Application Server (hoje em dia Web Ligic) e com o WebSphere sentia bastante falta desse conceito no JBoss para efetuar configurações específicas de uma aplicação específica.

No primeiro momento, a opção por executar o jboss no modo standalone, mesmo em ambiente de produção, torna-se a melhor opção pelo fato da facilidade, ou melhor, ser um processo parecido como o que tinha nas versões anteriores.  Isso não quer dizer que não funcione, pelo contrário, funciona perfeitamente, tanto que temos aplicações rodando com essa configuração.

Acredito que, além da quantidade de recursos existentes nessa nova versão, uma outra característica que vem implícita com o servidor de aplicação, mesmo nas versões anteriores, é a simplicidade. A curva de aprendizado para configurar e disponibilizar um servidor de aplicação JBoss é bem baixa.

O JBoss apresentou um servidor de aplicação robusto e simples de utilizar. Acredito que com essa ultima versão deixou muito dos seus usuários otimistas, mesmo com as mudanças drásticas realizadas em sua estrutura.

]]> http://www.nelsonalone.com.br/2012/01/22/jboss-7-reformulacao-completa/feed/ 0 http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/ http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/#comments Mon, 26 Sep 2011 15:08:18 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=595

(More)…]]> A equipe de desenvolvimento do Twitter disponibilizou nessa segunda a ultima versão do storm. Pra quem não conhece, assim como eu a duas horas atrás, é uma API do Twitter, desenvolvida pela BackType, utilizada para solucionar problemas de processamento em tempo real com tolerância a falhas.

Referências abaixo:

Artigo na Infoq: Link

Repositório no GitHub: Link

Wiki: Link

Um objeto persistente, para o hibernate, é uma entidade que contem relacionamentos com outras entidades que juntos formam uma relação. Em diversas situações, na maioria das vezes no mundo real, essa relação se torna complexa quando existe a necessidade de relação com outras entidades, somado com o numero enorme de dados relacionados. Existem várias formas de obter essas esses dados relacionados, uns que permitem obter todo o conjunto de dados relacionados ao carregar o objeto (eager), outro no momento que a relação é obtida (lazy). Outras alternativas podem ser utilizadas em conjunto, como, as consultas nomeadas atreladas ao carregamento do objeto. Porém, apenas obter a lista de desses informações não é suficiente para a aplicação, fazendo com que o desenvolvedor utiliza consultas mais elaboradas com HQL ou criteria.

A forma como o framework monta as consultas é na maioria das vezes genérica e pouco intuitiva, fazendo com que o desenvolvedor opte por utilizar o SQL nativo, ou portar a consulta para uma Stored Procedure para construir uma consulta mais elaborada. É uma estratégia plausível quando a aplicação necessita de desempenho mas, isso tiraria a principal vantagem do framework; o acesso as relações que são representadas pelo relacionamento entre os objetos. Existe uma maneira muito simples de executar uma consulta SQL mantendo o relacionamento entre os objetos.

Para o framework, os objetos persistentes são de extrema importância. Quando o framework é executado pela primeira vez, ele adiciona uma série de funcionalidade nos objetos persistentes que permite realizar as operações em suas relações. A maneira com que o framework realiza essa tarefa é pela Instrumentação de código. A instrumentação nada mais de uma técnica de incluir alterações do código do programa mesmo após a sua compilação. O conceito pode ser semelhante com Reflexão e AOP, mas existem particularidades que tornam os conceitos bem distintos. Por ser um assunto muito pesquisado e com referencias em abundância, é um assunto para ser tratado outra hora. No hibernate, isso é feito através da lib ASM, que é um extenso conjunto de utilidade que permitem a plicar esse conceito nas classes escritas em linhagem Java.

Bom, para que o framework compreenda que o resultado de uma consulta SQL possa ser vinculado a um objeto é necessário que o retorno corresponda aos atributos do objeto, sendo que o objeto possa ser reconhcido pelo motor de consulta. Ex:


List<ClasseQualquer> planos = new ArrayList<ClasseQualquer>();
String queryStr = queryUtils.findValue(nome_da_query); //obtem a string de consulta
Query query = entityManager.createNativeQuery(queryStr, ClasseQualquer.class);

Obtendo um objeto Query configurado como acima, é possível realizar operações como essas abaixo:


List dados = instanciaObjetoQualquer.getDadosParticulares();

Esse simples macete pode ajudar bastente para obter objetos, que necessitem manter o acesso aos objetos relacionados, através de consultas bem elaboradas e com o desempenho do SQL.

Em resumo, o fato foi devido a necessidade de priorizar o relase 7 (JDK 7), por ser o maior relase da plataforma,  e pela baixa utilização da IDE para projetos RoR.

Segue a fonte AQUI.

Os assuntos abordados vão dês dos fundamentos da criação de objetos até paralelismo. No decorrer do texto é possível encontrar afirmações como “Não faça isso” para as práticas não recomendadas e em seguida a maneira correta de se fazer.

Joshua Bloch é um dos desenvolvedores das principais APIs do Java, entre elas está as collections e math e assert. Hoje em dia ele assumiu o cargo de Chief Java Architect na Google. Mais detalhes aqui.

No desenho tradicional do GOF ele aparece como um elemento agregado do Builder, possibilitando a criação na forma separada. Mas o padrão Builder cumpre um papel importante no “jeitão” das libs contidas na JVM. Um exemplo disso é o fato de Utilizar o tradicional System.out.println() ou o System.gc() que são processos de iniciação estáticos.

De acordo com o item 2 do Effective Java 2nd Edicition do Joshua Bloch, “Static factories and constructors share a limitation: they do not scale well to large numbers of optional parameters”. Segundo Bloch, a solução para isso está na construção de métodos státicos associados aos tipos genéricos para construir os objetos de forma elegante como abaixo:

Rectangle rec = new Rectangle.Builder().opacity(5.0).height(1.2).build();

Quando se faz muitos testes unitários, a maioria das vezes torna-se necessário construir objetos, ou mocks, que representam um estado fictício para a execução dos demais testes. E frequentemente utilizamos o método tradicional, com os construtores:

Usuario usuario = new Usuario("Nelson","Alone",new Date(),"alone","alone",new Departamento(),new Filial());

É uma forma tediosa de iniciar objetos quando temos vários atributos que precisamos preencher para utilizá-lo no procedimento de teste. Portanto, o Builder pode agilizar esse processo da seguinte forma

Para exemplificar a utilização do Builder com métodos genéricos e de classes internas, inicialmente vamos preparar a construção de duas classes tradicionais, Rectangle e Chape. Utilizaremos classes internas para a construção dos objetos internamente. Isso faz com qua a instancia da classes possa ser feita através da classes interna e do método builder para finalização do processo:

public class Shape {

	private final double opacity;

	protected static abstract class Init<T extends Init<T>> {
		private double opacity;
		protected abstract T self();

		public T opacity(double opacity) {
			this.opacity = opacity;
			return self();
		}
	}

	public static class Builder extends Init<Builder> {
		protected Builder self() {
			return this;
		}
	}

	protected Shape(Init<?> init) {
		this.opacity = init.opacity;
	}

}

public class Rectangle extends Shape {
	private final double height;

	protected static abstract class Init<T extends Init<T>> extends Shape.Init<T> {

		private double height;

		public T height(double height) {
			this.height = height;
			return self();
		}

		public Rectangle build() {
			return new Rectangle(this);
		}

	}

	public static class Builder extends Init<Builder> {
		protected Builder self() {
			return this;
		}
	}

	protected Rectangle(Init<?> init) {
		super(init);
		this.height = init.height;
	}

}

Exemplo para construção:

Rectangle rec = new Rectangle.Builder().opacity(5.0).height(1.2).build();

Já ajudou bastante. A cada atributo incluso é retornado uma instância do construtor para a inclusão posterior, sendo finalizado pelo método build(). Porém, é necessário o acoplamento da classes interna para a preparação do Builder ara a sua utilização. Essa solução pode solucionar o problema, mas vamos fazer diferente.

Agora, temos um jeito mais elegante de construer objetos sem o auxílio direto da classe interna Builder. Utilizaremos o método estático builder para auxiliar no processo, como abaixo:

public class Shape {

	private final double opacity;

	public static abstract class Builder<T extends Builder<T>> {
		private double opacity;

		protected abstract T self();

		public T opacity(double opacity) {
			this.opacity = opacity;
			return self();
		}

		public Shape build() {
			return new Shape(this);
		}
	}

	public static class Builder2 extends Builder<Builder2> {
		public Builder2 self() {
			return this;
		}
	}

	public static Builder<?> builder() {
		return new Builder2();
	}

	protected Shape(Builder<?> builder) {
		this.opacity = builder.opacity;
	}

}

public class Rectangle extends Shape {
	private final double height;

	protected static abstract class Builder<T extends Builder<T>> extends Shape.Builder<T> {

		private double height;

		public T height(double height) {
			this.height = height;
			return self();
		}

		public Rectangle build() {
			return new Rectangle(this);
		}

	}

	public static class Builder2 extends Builder<Builder2> {
		protected Builder2 self() {
			return this;
		}
	}

	public static Builder<?> builder() {
		return new Builder2();
	}

	protected Rectangle(Builder<?> init) {
		super(init);
		this.height = init.height;
	}

}

Exemplo para construção:

Rectangle rec = Rectangle.builder().opacity(14.45).height(478.41).build();

Ficou mais aceitável e, ao mesmo tempo, menos acoplável. Internamente, temos mais código, mas facilita bastante a construção do objeto caso tenha um número grande de parâmetros.

Faça download dos fontes,  execute os teste e veja como fica em uma solução mais complexa.

[]s

Desenvolvedores de software estão sempre criando elementos que agilizem as tarefas que de desenvolvimento e dos clientes pelo qual trabalham, na maioria das vezes, tentando fazer com que suas empresas obtenham maior velocidade em suas rotinas administrativas aumentando sempre o ponto motivacional, o lucro. Muitas vezes, os clientes não conhecem a dimensão e nem a complexidade que compõe o produto que solicitou e atribui prazos horrendos para um produto simplesmente pelo fato de não conhecer as nuancias que essa atividade depende. Aí está a motivação de tornar, pelo menos, a maioria das atividade que compõe o desenvolvimento de software automáticas, simples, intuitivas e ao mesmo tempo divertidas.

A motivação para isso resulta na criação de builds automatizados, integração contínua, track lists, bug track e etc. Em muitas situações, esses elementos não são suficientes, já que, mesmo com um grande aparato para apoio na atividades, não não estão livres de erros. Erros sempre vão acontecer, suas dimensões dependerão do tamanho e complexidade do produto a ser entregue e da experiência que a equipe tem com projetos. Nessas situações pegunta-se, o que podemos fazer para aumentar a velocidade de desenvolvimento de nossas aplicações. Evangelistas responderiam freneticamente que as linguagens dinâmicas preencheriam essa lacuna e resolveriam esse problema.

• Linguagens Dinâmicas

As linguagens dinâmicas não são bem uma novidade para os desenvolvedores mais experientes. Há muito tempo tornaram-se peça chave para os desenvolvedores de software que optam por automatizar suas tarefas, adicionar funcionanlidades a conteúdos estáticos e até mesmo estar no núcleos dos software mais complexos. Entre as mais conhecidas estão JavaScript, PHP, Python e Ruby com as principais opções nesse segmento. Quando se fala em Web o que vem na ponta da língua são essas soluções. Mas, será que essas linguagens podem preencher todos os tipos de necessidades. Acredito que não. Sou completamente a favor do programador poliglota e conhecedor dos mais numerosos itens do seu canivete suíço e em conjunto com metodologias ágeis o desenvolvedor pode aflorar muitas de suas habilidades.

Ruby foi um dos principais expoentes desse movimento que cresce cada vez mais. Uma linguagem dinâmica, funcional, elegante e com um grau de orientação a objetos altíssimo vem tomando o interesse, não só dos novos desenvolvedores, mas também dos desenvolvedores experientes vindos de outras linguagens. Screencasts que ensinam a desenvolver CRUDs com uma velocidade considerável estão aos montes nos blogs e YouTube.

Com o excelente trabalho dos evangelistas na divulgação do produto, sendo ajudados pela velocidade da informação em conjunto com a difusão da substituição das linguagens tradicionais no segmento enterprise, as empresas estão notando o potencial do conjunto. O potencial é visível, mas o investimento feito nas linguagens que conhecemos hoje como também na plataforma, certamente são a principal barreira para esse fator. Barreira justificável quando se trata de desempenho, maturidade e, principalmente do apoio que teriam ao negócio.

Sabemos que recentemente a Oracle, uma das principais colaboradoras da plataforma Java, comprou a SUN Microsistem co

m o objetivo de agregar mais valor ao seu portfólio de aplicações enterprise. Muitos das peças chaves da SUN saíram em decorrência, principalmente, da filosofia acadêmica natural da universidade de Stanford que, até o momento, era uma das principais colaboradoras da empresa. Tendo em vista esse histórico, a aquisição da Sun pela Oracle teve um impacto negativo não só aos seus funcionários como também em toda comunidade ao redor dos produtos da empresa. Nesse momento, a facilidade que a linguagem Java oferecia e a questão de ser multiplataforma estava em descrédito, principalmente pelo fato das novas features adicionadas no Java 5 (Annotations, Varargs, Boxing e Generics) que os desenvolvedores torciam o nariz temendo o aumento da complexidade da linguagem.

A alternativa a outras linguagens fez com que muitos desenvolvedores voltassem os olhos para outras alternativas e, entre essas, as linguagens que hoje estão se tornando as mais populares, como:Ruby e Python. Python tem um histórico de sucesso para os desenvolvedores que utilizam o Linux. Muita coisa do Goolge foi feito com Python, elem do mais, a gigante fez com que a linguagem fosse a primeira a ter suporte no Google App Engine.

Ruby ainda não foi adotada pela Google, mas é um nome quente quando se trata de comunidade ao redor dela. Criada no Japão por Matz com o objetiva de ser melhor que Pearl, teve muita popularidade principalmente por ser mais flexível e com um nível elevado de orientação a objetos. Particularmente, gosto muito da linguagem Ruby. Acho interessante o fator escrever fazer mais com pouco código. Principalmente quando se trata do Rails.

• A linguagem/plataforma Java

Dei enfase, de forma não tanto comprativa com java, devido as circunstancias do que está acontecendo após a compra da SUN pela Oracle. Esse fato, deixou uma onda de boatos sobre a plataforma Java ao ponto de deixar qualquer cético em dúvida sobre as direções tomadas pela oracle. A saída do Gosling, Schwartz e as indefinições como o que vai acontecer com o OpenOffice e o Mysql provocou uma grande dúvida na estratégia da Oracle relacionado ao vinculo de mercado desses produtos. Notícias recentes apontam uma postura enérgica sobre o JCP que foi muito criticada pela comunidade, porém, bem aceita pelos desenvolvedores.

A questão, pode ser uma especulação, é de tornar o Java cada vez mais comercial, enterprise e profissional. Não me recordo se a Oracle obteve uma empresa com uma grande comunidade por trás de um produto como é o Java. Talvez seja uma estratégia de mercado de agrupamento de produtos em forma de pacotes comerciais. Ou o pior, o fazer o que Jobs fez quando voltou para Apple; enxugar a quantidade de produtos objetivando um único foco e com qualidade.

A questão é que: Uma linguagem, plataforma, seja o que for não morre de um dia para o outro. Existe muita coisa que foi feito sobre a plataforma que não pode ser descartada. O investimento, feito na época pela SUN, no aprimoramento e formação de profissionais certificados, não só na linguagem, mas também na plataforma SOLARIS, foi muito alto e resultou em um gerando número de pessoas que tem pelo menos uma certificação nos produtos da SUN. Acredito a poeira vai baixar e que a plataforma, pode ser que não a linguagem, serão um dos pontos fortes de investimento, não só da Oracle, mas também de outras empresas e da comunidade.

Muitos vão dizer: O pessoal da Thoughtworks publicou um artigo afirmando que não utilizarão a linguagem Java nos seus projetos daqui pra frente, pensarão em Java apenas como VM. Eles tem voz forte no mercado, ditam tendencias. Pode ser que isso se intensifique porque já está acontecendo. Java está perdendo popularidade no mundo open source, portém, no mundo corporativo ela é muito requisitada.

]]> http://www.nelsonalone.com.br/2010/11/02/como-anda-o-java/feed/ 0 http://www.nelsonalone.com.br/2010/10/29/oracle-compara-linha-por-linha-copias-feitas-pelo-google/ http://www.nelsonalone.com.br/2010/10/29/oracle-compara-linha-por-linha-copias-feitas-pelo-google/#comments Fri, 29 Oct 2010 14:31:40 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=489

(More)…]]> O Blog Beetween The Lines publicou uma nota informando em detalhes, linha por linha, sobre a cópia que a Google fez dos fontes de JVM para a plataforma Android. A informação é bem evidente.

Como é possível notar, nessa classe existe poucas diferenças como número de chaves, quantidade de parâmetros e nomes de variáveis.

Existem mais detalhes no blog do autor, inclusive os documentos redigidos pela empresa referente ao feito.