Marcio Garcia

A quick setup to upload files using SpringMVC.

Dependencies

Usando o Maven, o primeiro passo é incluir duas dependencias: commons-io and commons-fileupload:

Application Context

Segundo passo é configurar o application context para fazer uso de multiparts:

Controller

Terceiro passo: criar o seu controller. note the existe um parametro do tipo: MultipartFile.

View

E o último passo: sua JSP.

Recentemente eu precisei de trabalhar em um projeto onde toda a comunicação entre o frontend e o backend era feita através de requisições HTTP. A princípio consideramos utilizar um Servlet com alguns helpers que mapeava os parâmetros de URL para um Map e internamente esse Map era “injetado” em todas as classes de recurso.

Era uma solucão a ser considerada, mas como essa era a primeira idéia que o time teve, resolvemos descartá-la.

Por uma requisição do cliente, tinhamos que utilizar Maven e Spring e isto era ponto fechado. As demais bibliotecas eram por nossa conta (e risco).
Surgiu então a segunda idéia de utilizar RESTful simplesmente para facilitar o trabalho entre o mapeamento dos parâmetros vindos da URL com o código.

Pesquisamos a primeira Lib, Jersey já quer esta é a implementação padrão do JSR-311 e também pesquisamos a API do Restlet.
Resolvemos nos contrapor a ideologia de rejeitar a primeira opção a fim de conseguir novos recursos.
Ambos frameworks possuem aspectos únicos e muito bem documentados. Cada uma com suas particularidades, por exemplo no Restlet é necessário criar uma classe com as rotas (uma classe que extende a classe Application).

Mas os principais motivos que nos levou a decidir a utilizar o Jersey foram:

1. Ser a implementação modelo da especificação
2. Menos burocracia na implementação dos resources
3. Integração quase que natural com o Spring para a injeção de classes nos resources.

Este “walk through” tem o objetivo de exemplificar como criar uma aplicação simples utilizando as ferramentas: Spring, Maven e Jersey de forma prática.

Setup

1. Incluir o repositório do jersey-spring no pom.xml



2. Incluir as dependencias das libs: jersey spring


3. Configurar web.xml

It’s time do code!

1. Configuração do Spring (applicationContext.xml)
Crie o arquivo applicationContext.xml no diretório META-INF de sua aplicação. Este código informa ao engine do Spring para que o pacote com.mng.jerseydemo esteja disponível para a injeção de dependencias. Segue o modelo do arquivo:

2. Criação do primeiro resource.

Neste trecho de código existem algumas anotações, entre elas:


1. @Path
Este é o padrão da URL que será tratado pela classe. Pode ser informado variáveis utilizando o modelo: {nomeDaVariavel}. Por exemplo: @Path(”/user/{username}/{password}”).

2. @Autowired
Injeta um objeto do tipo informado na váriavel.

3. @GET
Responde as requisições do tipo GET, existem ainda: @POST, @PUT e @DELETE que podem ser utilizadas da mesma maneira que o @GET

4. @Produces
Informa o tipo de retorno do método. Esta anotação pode ser informada tanto no método quanto na classe, junto com o @Path. Informando na classe o tipo de retorno será propagado para todos os métodos que não tenham um @Produces específico.

5. @PathParam
Traduz as variáveis mapeadas na URL para um objeto. Este será mapeado para uma variável informada na assinatura do método.

Acessando

Para acessar o recurso recém criado voce pode utilizar o próprio browser (Chrome ou Firefox), com eles fica fácil de simular o GET. No entanto, se você está no mundo X (Linux, Unix ou mesmo Mac) faça bom uso do cUrl. De forma rápida e prática este comando é simples de ser utilizado.
Através do parametro “-X” especificando o método que deverá ser enviado é possível testar a maior parte dos serviços:

E com o parâmetro -F você pode especificar os parâmetros (@QueryParam) do método post.

• Project Template

Project Template (Archetype)	Purpose
maven-archetype-archetype	Create your own project template (archetype).
maven-archetype-j2ee-simple	Creates a J2EE project (EAR), with directories and subprojects for the EJBs, servlets, etc.
maven-archetype-mojo	Create your own Maven 2 plugins.
maven-archetype-quickstart	Simple Java project, suitable for JAR generation. Maven 2 default.
maven-archetype-site	Documentation-only site, with examples in several formats. You can run this archetype on top of an existing Maven 2 project to add integrated documentation.
maven-archetype-webapp	Creates a web application project (WAR), with a simple Hello World JSP.

Usage:

mvn archetype:create
  -DgroupId=[your project's group id]
  -DartifactId=[your project's artifact id]
  -DarchetypeArtifactId=maven-archetype-webapp

• Maven Commands

mvn clean	Cleans out all Maven-2-generated files.
mvn compile	Compiles Java sources.
mvn test-compile	Compiles JUnit test classes.
mvn test	Runs all JUnit tests in the project.
mvn package	Builds the JAR or WAR file for the project.
mvn install	Installs the JAR or WAR file in the local Maven repository (use this if you have multiple interdependent local projects).

Origem: java.net

Mais uma da série Maven2, desta vez com EJBs.

Não são raras as vezes que desenvolvendo projetos que precisem de um pouco mais de robustes e controle de transações utilizem EJB’s.

Geralmente aplicações backend (utilizem EJBs) e frontend (consomem EJBs) ficam empacotados no mesmo arquivo EAR, por tanto, o codigo do bean e as interfaces de conexão entre os EJBs e o cliente ficam no mesmo pacote, até então nada de errado, nada de estranho.

No entanto, participando de uma aplicação que será consumida por clientes de forma remota, mas interna a empresa, algumas alternativas aparecem com prós e contras:

WebService

Prós: fácil de integrar com a grande maioria das aplicações que rodam na empresa, seja Delphi, VB, .Net e o próprio Java.

Contras: muito lento se comparado com modelos nativos.

Modelos nativos

Prós: hand-shake e troca de informação entre aplicações rápido.

Contra: fortemente acoplado, a aplicação deve saber se comunicar com a aplicação servidora de forma nativa.

Algums vezes WebService pode ser a melhor solução em se tratando de integração de aplicações de diferentes linguagens, por exemplo Java e .Net.

Em uma cenário em que existe uma aplicação cliente e uma aplicacao servidora em java não existe razão para conectar as aplicações através de WebService, a melhor opção neste caso seria RMI-IIOP.

Não é muito elegante e muito menos seguro entregar para o desenvolvedor da aplicação cliente um pacote JAR com todo o codigo (mesmo que compilado) incluindo a implementação do Bean.

Para isso, o Mave2 utiliza um plugin que gera um pacote JAR apenas com as interfaces necessárias para integracao das partes, de forma fácil e simples.

• Passo 1:

Inclua o trecho de código no pom dos EJBs:

<build>
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-ejb-plugin</artifactId>
  <configuration>
    <generateClient>true</generateClient>
    <ejbVersion>3.0</ejbVersion>
    <clientExcludes>
      <clientExclude>br/com/mangar/ps/adm/business/dao/**/*</clientExclude>
      <clientExclude>br/com/mangar/ps/adm/business/util/**/*</clientExclude>
      <clientExclude>**/*Bean.class</clientExclude>
    </clientExcludes>
  </configuration>
</plugin>
</build>

Com esse código será gerado um pacote JAR como mesmo nome do pacote com os beans incluindo -client ao nome deste, que conterá todas as classes do pacote de EJB, exceto as classes do pacote dao, do pacote util e os Beans

• Passo 2

Para gerar o pacote, basta informar na linha de comando:

mvn ejb:ejb

Mais informações podem ser encontradas em: Maven EJB Plugin

Depois de muito relutar, nao teve jeito, tive que ceder a um “sisteminha de controle de build” e foi o Maven,
nunca me soou bem ter uma aplicação que definisse quais os diretórios e padrões eu deveria utilizar no
desenvolvimento de uma aplicação assim como a utilização de PMD e Checkstyle sempre foram, e de certo modo continuam sendo, uma burocracia desnecessária e um inibido de criatividade do desenvolvedor, mas isso já é papo para outro post.

Para mim nunca fez sentido “embutir” uma ferramenta a mais no processo de desenvolvimento que não agregasse valor algum
para o desenvolvedor do sistema, mas estudando e utilizando o Maven percebi que realmente, “criatividade” na mão de desenvolvedor
é uma arma, algumas vezes (quase sempre) deve ser definido o padrão de diretórios para recursos, classes, arquivos de configurações,
conteúdo web e etc….

Vejamos alguns passos para utilizar essa ferramenta:

• 
  

  Instalando

Simples, rápido e indolor, va no site do projeto e faça o download do binario: http://maven.apache.org/download.html
Feito isso, descompacte o conteúdo e crie uma variável de ambiente chamada: M2_HOME apontando para este diretório,
altere a variável de ambiente: “Path” incluindo no final: ;%M2_HOME%\bin

Abra uma linha de comando e digite:

mvn --version

se a resposta for algo do tipo:

Maven version: 2.0.5

Perfeito, o primeiro passo está dado, Maven2 instalado e funcionando.

• 
  

  Criando projetos

O Maven cria uma estrutura de diretorios de acordo com o tipo do projeto, este pode ser direcionado para projeto web,
projeto EJB (business) ou apenas um jar, por defautl ele cria uma estrutura de diretorio JAR, para isso, va na linha
de comando e digite:

mvn archetype:create -DgroupId=mangar.corp -DartifactId=mangar-jar

groupId = nome do pacote que será criado no repositorio
artifactId = nome do projeto

existem mais alguns parametros que podem ser informados na linha de comando para criar uma arvore de diretorios para determinados
tipos de projetos, uma delas é:

-DarchetypeArtifactId=maven-archetype-webapp

este criará uma estrutura para um projeto web, com WEB-INF.

A estrutura criada será:

mangar-jar

   |-- pom.xml
       `-- src
           `-- main
           |   `-- java
           |       `-- App.java
           `-- test
               `-- java
                    `-- AppTest.java

Se vc criou uma estrutura jar mas na verdade precisa de uma estrutura web, nao se desespere!
Crie o diretorio, dentro do diretorio main: webapp e webapp\WEB-INF, crie tbem o arquivo web.xml dentro do WEB-INF,
e altere o arquivo pom.xml a tag packaging de jar para war.

• 
  

  pom.xml

É aqui que mora todo o segredo do Maven, este é o arquivo onde ficam todos os segredos, dependencias, empacotamento,
relatorios e todas as mágicas que o Maven pode fazer por você.

No começo temos:

<groupId>mangar.corp</groupId>
 <artifactId>mangar-jar</artifactId>
 <packaging>jar</packaging>
 <version>1.0-SNAPSHOT</version>

A tag <version> e a <packaging> sao duas que tambem podem ser informadas na linha de comando quando criado o repositorio
do projeto, mas por default, estes valores apresentados sao os padroes caso nao seja mencionado.

Maiores detalhes sobre esse arquivo vc pode encontrar nos sites: maven.apache.org, onjava entre outros.
Vou apresentar aqui alguns parametros que precisei.

• 
  

  Compilando o código com a versão 1.5 do JDK

Na maquina já existia uma VM 1.5 instalada no entando, nao sei por causa de que, meu codigo que compilava perfeitamente
no Eclipse, nao estava rolando via maven (estava usando enum e generics), entao, garimpando na WEB descobri os seguintes
parametros que devem ser incluidos no pom.xml:

<build>

  <plugins>

    <plugin>

      <groupId>org.apache.maven.plugins</groupId>

      <artifactId>maven-compiler-plugin</artifactId>

      <configuration>

        <source>1.5</source>

        <target>1.5</target>

      </configuration>

    </plugin>

  </plugins>

</build>

A tag <build> é unica no arquivo, assim como a <plugins> dentro da <build>, mas a tag <plugin> pode ser incluido de acordo com os
plugins necessários com a fase de build exigir.

• 
  

  Uso de bibliotecas (agregando para o desenvolvedor)

Chegamos na hora boa, a hora que o desenvolvedor vai deixar de apenas cumprir regras sem um ganho de fato.
Em um projeto web, nao é raro utilizar struts, por acaso vc sabe a dependencia entre o pacote struts.jar com os demais pacotes?
Eu tbem nao! Mas o Maven sabe!
Apenas informando que o projeto tem dependencia com struts e qual a versao deste, o maven vai trazer para o repositorio local
todas as dependencias necessárias, para isso, inclua no seu pom:

<dependencies>

  <dependency>

    <groupId>struts</groupId>

    <artifactId>struts</artifactId>

    <version>1.2.9</version>

  </dependency>

<dependencies>

A tag: <dependencies> é unica para todo o pom, já as <dependency> pode se multiplicar de acordo com a necessidade.
Com esse trecho de codigo o maven fará o downlod da lib do struts 1.2.9 incluindo todas as dependencias.

• 
  

  Repositórios

Como dito na sessao anterior o maven baixa as bibliotecas do repositorio remoto para o repositorio local, por definicao o
repositorio padrao remoto é o: http://repo1.maven.org/maven2/ este contem uma quantidade de bibliotecas muito grande, ainda
assim algumas mais especificas ou versoes mais novas podem nao estar atualizadas, por tanto, vc pode incluir alguns repositorios.

Uma das maneiras de incluir um novo repositorio é incluir o codigo no arquivo pom.xml:

<repositories>

  <repository>

    <id>galaxy</id>

    <url>http://galaxy.andromda.org/maven2</url>

  </repository>

</repositories>

A tag <repositories> é unica no pom, a tag <repository> pode ser repetida para incluir os repositorios desejados, inclusive o repositorio
do JBoss.

O repositorio local por definicao é criado dentro do diretorio “home” do usuario, no windows: %Documents and Settings%\%Usuario logado%\.m2\repository
Mas pode ser alterado, para isso, copie o arquivo settings.xml que fica em: %M2_HOME%\conf para o %Documents and Settings%\%Usuario logado%\.m2
localize a linha: <settings> insira logo a baixo : <localRepository>c:/m2</localRepository>
Isso mudara o diretorio do seu repositorio.

• 
  

  Executando

Com tudo isso feito, agora é hora de vermos o Mvn em ação, na linha de comando vá para o diretorio onde está localizado o arquivo pom.xml e digite:

mvn clean install

Executado a primeira vez este comando fará o downlad de todas as bibliotecas associadas direta e indiretamente ao projeto, compulara o projeto,
executará os testes, empacotará o projeto e o instalará no repositorio local.

outros comandos:

clean = limpa o diretorio de target, que o maven usa como stage para a geracao do pacote com os binarios da aplicacao
package = compila o projeto e gera o pacote (war, jar, ….)
compile = apenas compila o projeto, gerando a saida no diretorio target.
site = compila, empacota o projeto e gera o site do projeto