quarta-feira, 5 de setembro de 2018

Entenda o funcionamento das transações do Entity File Manager

Entity file manager é um recurso que permite persistir entidades em arquivos estruturados. Ele foi desenvolvido com a finalidade de dar suporte à persistência de dados no BRCache.

Transações


Uma transação é uma coleção de operações que desempenha uma função lógica única. Ela tem que ter as seguintes propriedades:

  • atomicidade: todas as operações contidas na transação são tratadas como uma única unidade. Todas as operações são feitas ou nada é feito.
  • consistência: uma transação concluída deixa o sistema em um estado interno consistente.
  • isolamento: em um ambiente de múltiplas transações, uma não interfere na outra.
  • durabilidade: os resultados das transações são armazenadas permanentemente no sistema.

O entity file Manager permite que transações confirmadas possam ser efetivadas em paralelo com transações em execução. Também favorece a redução das operações de I/O, pois ele permite atualizações em lote. Todas as operações de inserção e atualização são executadas em um arquivo temporário num primeiro momento e depois em segundo plano no arquivo original.

Insert/Update


As transações confirmadas são gravadas no arquivo recoverylogX e os dados das entidades também são gravadas no arquivo temporário. Elas são inseridas sempre no final do arquivo. Este método reduz o I/O em updates, pois toda atualização também é uma inserção e pode ser feito em lote. No momento em que não existir nenhum transação sendo processada, o arquivo temporário é sincronizado com o arquivo original.


Select


Quando um arquivo está envolvido em uma transação, a pesquisa sempre ocorre primeiro no arquivo temporário e depois no arquivo original. A pesquisa ocorre sempre primeiro no arquivo temporário, porque nele ficam armazenadas as alterações feitas pelas transações anteriores depois da última sincronização com o arquivo original.


Efetivando as transações


Quando o arquivo recoverylogX atinge o seu tamanho máximo, ele é fechado e enviado para um processo paralelo que aplica as alterações no arquivo original. O arquivo temporário é sincronizado com o arquivo original somente quando não houver transações ativas.


terça-feira, 4 de setembro de 2018

Entity file manager (subprojeto do BRCache)



Entity file manager é um recurso que permite persistir entidades em arquivos estruturados. Ele foi desenvolvido com a finalidade de dar suporte à persistência de dados no BRCache. Ele basicamente é composto pelas classes EntityFileManager, EntityFile, EntityFileAccess e EntityFileTransactionManager.

1. EntityFileManager


A classe EntityFileManager provê todos os recursos necessários para a manipulação de entidades. Ela trabalha em conjunto com EntityFileAccess para armazenar as entidades no arquivo e EntityFileTransactionManager para manter a consistência. 
Para cada operação de inserção, atualização e seleção, é necessário que sempre tenha uma transação explicita.
São providas somente instâncias da EntityFile associadas a uma transação. As operações executadas nela são delegadas ao EntityFileTransactionManager que faz as o necessárias para manter a consistência do arquivo.

2. EntityFile


A classe EntityFile provê recursos que permitem manipular um tipo específico de entidade. Com ela é possível inserir, atualizar, apagar e selecionar uma entidade. Ao inserir uma entidade, o EntityFile envia uma requisição ao EntityFileTransactionManager solicitando que a entidade seja incluída no arquivo. Depois de inserida, é obtida uma identificação única. A identificação indica a posição da entidade dentro do arquivo.
Na atualização, o EntityFile envia uma requisição ao EntityFileTransactionManager solicitando que ela  seja atualizada no arquivo. Então ocorre seu bloqueio, atualização e posterior liberação após o fim da transação.
A exclusão de uma entidade é, em síntese, uma atualização. A operação vai depender do EntityFileAccess. Este pode apenas inserir um entidade vazia ou também mapear a lacuna para uma posterior inserção.
Na seleção, o EntityFile envia uma requisição ao EntityFileTransactionManager solicitando a entidade e ele devolve a entidade ou null que pode ser obtido diretamente do arquivo ou de um outro local temporário. O bloqueio nesse caso é opcional.

3. EntityFileTransactionManager


A classe EntityFileTransactionManager é responsável por manter a consistência dos arquivos após sua alteração. Ele recebe as requisições do EntityFile e as processa. A forma como o processamento de tais requisições é feita, vai depender da implementação utilizada.
O EntityFileTransactionManager pode gerar dois tipos de logs. O recoverylog que permite recuperar as transações após parada abrupta da aplicação e o binlog que tem a função de permitir a replicação das operações em outra aplicação.
Os dois logs possuem o seguinte formato:

****************************************************************
|             |              corpo             |               |
****************************************************************
|             |              |                 |               |
| ml (8 bytes)| nt (8 bytes) | t (nt - nl - 8) | chk (8 bytes) |
|             |              |                 |               |
****************************************************************
  • ml: marcação da transação. Ele indica um novo registro e seu valor é o ponteiro obtido após sua leitura no arquivo;
  • nt: apontamento para o próximo registro do log ou final do arquivo;
  • t: dados da transação, tem o tamanho (nt-nl-8) bytes;
  • chk: conjunto de 8 bytes usado para validar o corpo do registro.
Os dados da transação (t) tem o seguinte formato:

**********************************************************************
|        |         |         |         |         |         |         |
|   st   |   to    |   id    |    i    |   flg   |    ef   |   efd   |
|(1 byte)|(8 bytes)|(8 bytes)|(1 bytes)|(1 bytes)|(1 bytes)|(n bytes)|
|        |         |         |         |         |         |         |
**********************************************************************
  • st: status da transação;
  • to: timeout original da transação;
  • id: identificação da transação;
  • i: isolamento da transação;
  • flg: flags que indicam se a transação foi confirmada, cancelada e iniciada;
  • ef: indica a continuidade ou o fim da lista de EntityFile utilizados na transação. O valor -1 indica o final da lista;
  • efd: dados do EntityFile manipulado na transação.
Os dados do EntityFile na transação tem o seguinte formato:

****************************************************************
|           |                                        |         |
| cabeçalho |                   dados                |   eof   |
| (n bytes) |                 (n bytes)              |(n bytes)|
|           |                                        |         |
****************************************************************
  • cabeçalho: cabeçalho do EntityFile. O tamanho é o mesmo do cabeçalho original;
  • dados: lista das entidades manipuladas na transação;
  • eof: indicação do final do EntityFile. O tamanho é o mesmo do eof original.

3.1 AsyncRecoveryTransactionLog



A classe AsyncRecoveryTransactionLog é a implementação padrão do recovery log. Permite que transações confirmadas possam ser efetivadas em paralelo com transações em execução. Também favorece a redução das operações de I/O, pois ele permite atualizações em lote. Todas as operações de inserção e atualização são executadas em um arquivo temporário num primeiro momento e depois em segundo plano no arquivo original.
Uma transação confirmada é gravada no arquivo recoverylogX e as alterações dela também são gravadas no arquivo temporário. 
Quando o arquivo recoverylogX atinge o seu tamanho máximo, ele é fechado e enviado para um processo paralelo que aplica as alterações no arquivo original. O arquivo temporário é sincronizado com o arquivo original somente quando não houver transações ativas.
Em caso de parada abrupta da aplicação, o log de transação pode ser cortado na última transação válida. Isso é possível porque as transações são registradas de forma sequencial no arquivo e sua estrutura permite avaliar a integridade da transação. Este corte não ocorre de forma automática e precisa ser autorizado antes da aplicação ser iniciada. É possível definir como padrão o corte do arquivo de log. 

4. EntityFileAccess


A classe EntityFileAccess provê recursos que permitem manipular diretamente o arquivo. Ele é responsável por gravar e ler os dados das entidades. A estrutura do arquivo é definida pelo EntityFileAccessHandler que codifica e decodifica o cabeçalho e as entidades em dados.

quinta-feira, 16 de agosto de 2018

Nova versão do Brutos Framework liberada!



Liberada a versão 2.0 rc3 do Brutos Framework. O dowload da nova versão pode ser feita na página de download e as alterações estão descritas no changelog.

O Brutos Framework é um controlador MVC desenvolvido em Java. Projetado para reduzir a complexidade do desenvolvimento web, com mapeamento configurável, resolução de vista, bem como suporte ao upload e download de arquivos. Podendo ser configurado usando XML, anotações e CoC.

Quais as vantagens em utilizá-lo?


  • leve;
  • baixo acoplamento;
  • produtivo;
  • geração de componentes testáveis;
  • suporte avançado de mapeamento;
  • fácil aprendizado.


Obtendo o pacote


Os pacotes de liberação estão hospedados no sistema de arquivos da SourceForge em formato ZIP. 
Cada pacote contém jars, exemplos, código fonte e entre outros. Seu download pode ser feito a partir da url http://sourceforge.net/projects/brutos/files/brutos/.

Repositório de artefatos Maven


  • brutos-core: artefato principal, necessário para construir aplicações usando o Brutos APIs nativo.
  • brutos-annotation: artefato opcional que permite a construção de aplicações usando anotações. Este artefato depende do brutos-core.
  • brutos-web: artefato opcional que permite a construção de aplicações web. Este artefato depende do brutos-core.

O repositório oficial do Brutos Framework é http://www.brutosframework.com.br/maven/2.

Como configurá-lo?


Registrar o listener no web.xml



Atenção: Se estiver sendo usado um container que suporte a especificação Servlet 3.0, o registro do ContextLoadListener não será necessário. Ele é automaticamente registrado. 

Registrar o filtro no web.xml



Atenção: Se estiver sendo usado um container que suporte a especificação Servlet 3.0, o registro do BrutosRequestFilter não será necessário. Ele é automaticamente registrado. 

Opções de configuração


  • Anotações
  • XML
  • CoC (Convenção sobre configuração)

Principais anotações


  • @Controller: indica um controlador;
  • @Action: indica uma ação;
  • @RequestMethod: associa uma ação a um determinado método HTTP;
  • @ResponseStatus: define o status HTTP da resposta de uma ação;
  • @ResponseError: define o status HTTP da resposta quando é lançada uma exceção;
  • @AcceptRequestType: indica os formatos de requisição suportados por uma ação;
  • @ResponseType: indica os formatos de resposta suportados por uma ação;
  • @Any: especifica o mapeamento de polimorfismo;
  • @View: define a vista de uma ação;
  • @Basic: especifica o mapeamento básico de um bean;
  • @Intercepts: especifica um interceptor.


terça-feira, 22 de maio de 2018

Exemplo de Brutos MVC com Spring (Brutos 2.0 + Spring 5.0.6)


Exemplo de Brutos MVC com Spring. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-spring

sábado, 19 de maio de 2018

Exemplo de formulário com senha. (Brutos + Bootstrap 4 + Hibernate Validator + Weld)


Exemplo de formulário com senha. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-password-form


quinta-feira, 17 de maio de 2018

Enviando um formulário com múltiplas linhas para um List com Brutos MVC (Brutos + Bootstrap 4)


Enviando um formulário com múltiplas linhas para um List com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-multiple-row-form


quarta-feira, 16 de maio de 2018

Exemplo de post de formulário em Map com Brutos MVC (Brutos + Bootstrap 4 + Weld)


Exemplo de post de formulário em Map com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-value-key-map-form


terça-feira, 15 de maio de 2018

Exemplo de dropdown box com Brutos MVC (Brutos + Bootstrap 4 + Hibernate Validator + Weld)


Exemplo de dropdown box com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-dropdown-box

segunda-feira, 14 de maio de 2018

Exemplo de uso do hibernate com Brutos MVC (Brutos + Bootstrap 4 + Hibernate + Weld + MySQL)



Exemplo de uso do hibernate com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-hibernate-mysql


sábado, 12 de maio de 2018

Exemplo de uso de JTA com Brutos MVC (Brutos + Weld + Hibernate + narayana + Tomcat)


Exemplo de uso de JTA com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-jta-cdi-hibernate


http://www.brutosframework.com.br/

Exemplo de uso de polimorfismo com Brutos (Brutos + Weld).


Exemplo de polimorfismo com Brutos MVC. O código fonte dos exemplos estão hospedados no GitHub.

Código fonte: https://github.com/brandaof/brutos-polymorphic-mapping


http://www.brutosframework.com.br/

quarta-feira, 9 de maio de 2018

Brutos framework 2.0 RC2 liberado


O Brutos framework é um controlador MVC desenvolvido em Java. Projetado para reduzir a complexidade do desenvolvimento web com mapeamento configurável, resolução de vista, suporte ao upload e download de arquivos. Podendo ser configurado usando XML, anotações e suas convenções de configuração. 

Destaques da versão 2.0 RC2:

  • incluída a anotação @DetachedName;
  • resolvido o problema de parâmetros com regex que contém '{';
  • alterada a forma da resolução de vista;
  • alterado o prefixo da vista de /WEB-INF para /WEB-INF/views;
  • incluído Type.toString(Object);
  • incluído suporte a coleções simples;
  • incluído a anotação @RequestMethod;
  • incluído suporte ao mapeamento de resultado de ação;
  • incluído a anotação @ResponseStatus;
  • incluído a anotação @ResponsError e @ResponsErrors;
  • descontinuado o ControllerResolver;
  • action resolver assume o papel do ControllerResolver;
  • o valor default do Enum passou a ser AUTO;
  • incluído type default para classe concreta no @Any;
  • alterado o atributo view-resolved para resolved-view em controller, action e throw-safe;
  • incluído o atributo rendered em controller, action e throw-safe;
  • incluído lazy-load em property controller, property action, constructor-arg, parameter action;
  • descontinuado o escopo controller;
  • alterada as opções de MappingTypes de SIMPLE e COMPLEX para VALUE e OBJECT;


http://www.brutosframework.com.br/

quinta-feira, 20 de outubro de 2016

BRCache vs. Memcached Benchmark



Em experimento realizado, o BRCache demonstrou ser mais rápido que o Memcached.
O experimento está disponível no repositório de arquivos do SourceForge (https://sourceforge.net/projects/brcache/files/).

O experimento


No experimento somente foi considerado o armazenamento em memória. A instância de cada servidor foi configurada para consumir no máximo 8GB. Os métodos testados foram o de escrita e leitura. Nenhum cliente foi utilizado. Foram criados métodos que geram as solicitações e processam as respostas.
O experimento foi dividido em duas etapas. A primeira etapa escreve os dados no cache. Cada registro tem um tamanho fixo de 1k. São utilizados grupos de 50 até 300 clientes, com 50 de frequência. Cada cliente faz 50 registros únicos. Cada agrupamento de clientes é executado três vezes e o resultado com menor tempo médio de resposta é considerado. A segunda etapa lê os dados do cache. Cada leitura tem um tamanho fixo de 1k, gerado na primeira etapa. São utilizados grupos de 50 até 300 clientes, com 50 de frequência. Cada cliente lê 50 registros únicos. Cada agrupamento de clientes é executado três vezes e o resultado com menor tempo médio de resposta é considerado.

O hardware


O cliente e o servidor foram executados na mesma máquina com a seguinte configuração:

  • processador Intel(R) Core(TM) i3-2100  (3.10GHz 64bits)
  • 16GB de memória.

O servidor de cache


O experimento foi feito com a versão 1.4.5 64bit do Memcached e a versão 1.0 beta 4 do BRCache sobre Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode).

A configuração de arranque


Para o experimento, o servidor Memcached foi iniciado usando os parâmetros de linha de comando m igual a 8000 e t igual a 8.

memcached -m 8000 -t 8

O servidor BRCache foi iniciado usando os parâmetros de linha de comando server e XX:ParallelGCThreads igual a 8.

java -server -XX:ParallelGCThreads=8 -jar brcache-server-1.0-b4.jar

As configurações adicionais do cache


O Memcached não necessitou de configurações adicionais e o BRCache foi configurado como se segue abaixo:

port=9090
max_connections=1024
swapper_thread=2
memory_access_type=unsafe
timeout_connection=1024
reuse_address=false
data_path=/mnt/brcache
nodes_buffer_size=1024m
nodes_page_size=1k
nodes_swap_factor=0.1
index_buffer_size=512m
index_page_size=1k
index_swap_factor=0.1
data_buffer_size=4000m
data_page_size=8k
data_block_size=1k
data_swap_factor=0.1
write_buffer_size=16k
read_buffer_size=16k
max_size_entry=128m
max_size_key=64
transaction_support=false



O cálculo


A quantidade de operações por segundo foi obtida com a fórmula: ops = (1000000000*i)/t, onde:


  • t: tempo total, em nano segundos, que o agrupamento de clientes demora para executar todas as operações.
  • i: quantidade total de operações executadas pelo agrupamento de clientes.
  • 1000000000: constante que representa um segundo em nano segundos.



Resultado


O método de escrita do BRCache demonstrou ser mais rápido que o Memcached ao passo que a quantidade de clientes aumentava. Demonstrada pela curva ascendente do gráfico abaixo.

Escritas por segundo

O método de leitura do BRCache é tão rápido quanto o do Memcached. Demonstrado pelo entrelaçamento das linhas do gráfico abaixo.
Foram feitos testes usando milissegundo como unidade de tempo. Nesse caso, os resultados demonstraram que o BRCache foi mais rápido em ambos os métodos. Isso sugere que a diferença de performance, no caso do método de leitura, está na base de nano segundos.

Leituras por segundo

Variação nos resultados


Foram feitos inúmeros testes e a performance de ambos os servidores variaram para mais ou menos de 70.000 operações por segundo. Chegando a passar de 200.000 mil operações por segundo. Fazendo uma análise preliminar, essa variação se deve a sensibilidade do experimento e ao modo como os dados trafegam, mesmo o cliente e o servidor estando em uma mesma máquina, Por exemplo, o laço da linha 67, do método de leitura, em ambos clientes variavelmente foi executado mais de uma vez.


Conclusão

Mesmo se tratando de uma versão beta, o BRCache demonstrou ser tão ou mais rápido que a última versão estável do Memcached. Outros experimentos ainda serão feitos.

domingo, 21 de agosto de 2016

Named-Lock version 1.0 B2 was released

Named-Lock version 1.0 B2 was released
see more http://namedlock.brandao.org/.

1. Quick Reference.


The named-lock is a utility for acquiring named locks.


1.1 Named factory.


Main class


public class Test {

    public static void main(String[] args) throws InterruptedException{
        NamedLockFactory lockFactory = new NamedLockFactory();
        
        System.out.println("start test");

        Lock lock = lockFactory.getLock("lock_name");
        lock.lock();
        try{
            Task task = new Task(lockFactory);
            task.start();
            Thread.sleep(1000);
            System.out.println("1");
        }
        finally{
            lock.unlock();
        }

        Thread.sleep(1000);
        System.out.println("end test");
        
    }

}

Task class


public class Task extends Thread{

    private NamedLockFactory lockFactory;

    public Task(NamedLockFactory lockFactory){
        this.lockFactory = lockFactory;
    }

    public void run(){

        Lock lock = lockFactory.getLock("lock_name");
        lock.lock();
        try{
            System.out.println("2");
        }
        finally{
            lock.unlock();
        }

    }

}


output:
start test
1
2
end test


1.2 Named lock.



NamedLock namedLock = new NamedLock()
Serializable refLock = namedLock.lock("lock_name");
try{
   // manipulate protected state
}
finally{
  namedLock.unlock(refLock, "lock_name");
}


quinta-feira, 11 de agosto de 2016

jBRGates version 1.1 B1 was released


jBRGates version 1.1 B1 was released
see more http://jbrgates.brandao.org/.

1. Quick Reference.


The jBRGates is a lightweight library for serializing beans, maps, collections, arrays and Enum to Json and back again to beans.


1.1. Convert Java object to JSON.


The method JsonContext.encode(Object) convert a java object to json object.

 Ex:
     double[] javaObject = new double[]{1.0,25.0};
     JsonContext context = new DefaultJsonContext();
     String jsonObject = context.encode(javaObject);
     
 Output:
 [1.0, 25.0]

 Ex2:

     MyObject javaObject = new MyObject();
     javaObject.filed1 = 12L;
     javaObject.field2 = "Test";
     
     JsonContext context = new DefaultJsonContext();
     String jsonObject = context.encode(javaObject);
     
 Output:
 {"field1": 12, "field2": "Test"}

 Ex3:

     MyObject javaObject = new MyObject();
     javaObject.filed1 = new Date();
     javaObject.filed2 = MyEnum.VALUE1;
     
     JsonContext context = new DefaultJsonContext();
     String jsonObject = context.encode(javaObject);
     
 Output:
 {"field1": "2016-08-06T12:30:00.000Z", "field2": "VALUE1"}

1.2. Convert JSON to Java object.


The method JsonContext.decode(String) convert a json object to java object.

 Ex:
     String jsonObject   = "[1.0, 25.0]";
     JsonContext context = new DefaultJsonContext();
     double[] javaObject = context.decode(jsonObject, double[].class);
     

 Ex2:

     String jsonObject   = "{\"field1\": 12, \"field2\": \"Test\"};
     JsonContext context = new DefaultJsonContext();

     MyObject javaObject = context.decode(jsonObject, MyObject.class);


2. jBRGates Dependency.


<dependency>
    <groupId>org.brandao</groupId>
    <artifactId>jbrgates</artifactId>
    <version>1.1-b1</version>
</dependency>

domingo, 31 de janeiro de 2016

terça-feira, 21 de julho de 2015

Mapeamento de polimorfismo com @Any no Brutos MVC

O mapeamento de polimorfismo, introduzido na versão 2.0, é uma solução que permite a um entidade ser mapeada para mais de um tipo. É implementado com a anotação @Any. Este tipo de mapeamento requer que, além do mapeamento da entidade, seja informado o metabean, uma variável que contém o identificador da entidade associada. Pode ser usado em um bean nas propriedades ou nos argumentos de um construtor e em um controlador nas propriedades ou nos parâmetros de uma ação.


@Target({ElementType.METHOD,ElementType.PARAMETER,ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Any {

 Basic metaBean() default @Basic;
 Class metaType() default String.class;
 EnumerationType metaEnumerated() default EnumerationType.ORDINAL;
 String metaTemporal() default BrutosConstants.DEFAULT_TEMPORALPROPERTY;
 MetaValue[] metaValues() default {};
 Class metaValuesDefinition() default MetaValuesDefinition.class;
 
}


  • metaBean(): variável que contém os metadados.
  • metaType(): tipo da variável que contém os metadados.
  • metaEnumerated(): usado quando o metadado for uma enumeração.
  • metaTemporal(): usado quando o metadado for uma data.
  • metaValues(): associa um valor a um bean.
  • metaValuesDefinition(): Permite em tempo de execução associar um valor a um bean.

Abaixo um exemplo de uso da anotação @Any em uma propriedade de um bean.

public class TestBean{

    @Basic(bean="property")
    @Any(
        metaBean=@Basic(bean="property_type")
        metaValues={
            @MetaValue(name="Decimal", target=DecimalProperty.class),
            @MetaValue(name="Set", target=SetProperty.class)
        }
    )
    private Property property

    ...
}

Abaixo um exemplo de uso da anotação @Any em um construtor de um bean.

public class TestBean{

    public TestBean(
        @Basic(bean="property")
        @Any(
            metaBean=@Basic(bean="property_type")
            metaValues={
                @MetaValue(name="Decimal", target=DecimalProperty.class),
                @MetaValue(name="Set", target=SetProperty.class)
            }
        )
        Property property){
        ...
    }

}

Abaixo um exemplo de uso da anotação @Any em uma propriedade de um controlador.

@Controller("/test")
public class TestController{

    @Basic(bean="property")
    @Any(
        metaBean=@Basic(bean="property_type")
        metaValues={
            @MetaValue(name="Decimal", target=DecimalProperty.class),
            @MetaValue(name="Set", target=SetProperty.class)
        }
    )
    private Property property

    ...
}

Abaixo um exemplo de uso da anotação @Any em uma ação.

@Controller("/test")
public class TestController{

    @Action("/")
    public void testAction(
        @Basic(bean="property")
        @Any(
            metaBean=@Basic(bean="property_type")
            metaValues={
                @MetaValue(name="Decimal", target=DecimalProperty.class),
                @MetaValue(name="Set", target=SetProperty.class)
            }
        )
        Property property){
        ...
    }

}

Um exemplo da vida real seria um cenário de venda, onde um operador turístico vende diferentes serviços.
O exemplo irá permitir registrar um serviço aéreo ou de hospedagem por transação.

Dowload link: http://sourceforge.net/projects/brutos/files/brutos/2.0/examples/2.0-RC1/polymorphic-mapping.zip/download

Source code: http://sourceforge.net/p/brutos/code/HEAD/tree/trunk/examples/polymorphic-mapping/


Diagrama das entidades da aplicação.


Durante cada transação de venda, apenas um serviço será vendido. Podendo ser um serviço de hospedagem ou aéreo.

Classes

public class SaleTransaction {

 private Long id;

 @Transient
 private Date date;

 private Long price;

 @Any(
  metaBean = 
   @Basic(bean = "serviceType"),
  metaType=
   String.class,
  metaValues = {
   @MetaValue(name = "air", target = AirService.class),
   @MetaValue(name = "hosting", target = HostingService.class) 
  }
 )
 private Service service;

 //gets e sets
 ...

}
SaleTransaction.java

A anotação @Any indica que a propriedade service receberá uma instâncias da AirService, se o parâmetro serviceType for igual a "air", ou HostingServices, se o parâmetro serviceType for igual a "hosting".

public interface Service {

 void setPrice(Long value);
 
 Long getPrice();
 
 String getServiceType();
 
}
Service.java

public abstract class AbstractService 
 implements Service{

 protected Long price;
 
 public void setPrice(Long value) {
  this.price = value;
 }

 public Long getPrice() {
  return this.price;
 }

}
AbstractService.java

public class AirService extends AbstractService{

 private String airplane;
 
 private String seat;
 
 @Temporal("yyyy-MM-dd hh:mm")
 private Date departureDate;
 
 @Temporal("yyyy-MM-dd hh:mm")
 private Date arrivalDate;

 public String getAirplane() {
  return airplane;
 }

 //gets e sets
 ...
 
}
AirService.java

public class HostingService extends AbstractService{

 private String hotel;
 
 @Temporal("yyyy-MM-dd")
 private Date checkin;
 
 @Temporal("yyyy-MM-dd")
 private Date checkout;
 
 private String mealPlan;
 
 private String room;

 //gets e sets
 ...
 
}
HostingService.java

@Controller("/sales")
@Action(value="/new", view=@View("new"))
@RequestScoped
public class SalesController {

 @Inject
 @Transient
 private SalesMemoryEntityAccess salesMemoryEntityAccess;
 
 @Action("/save")
 @Result("entity")
 public SaleTransaction save(@Basic(bean="entity") 
  SaleTransaction entity){
  this.salesMemoryEntityAccess.save(entity);
  return entity;
 }

 ...
 
}
SalesController.java


View


<form method="POST"
  action="${pageContext.servletContext.contextPath}/sales/save">
  <table>
   <tbody>
<tr>
     <td>Id</td>
     <td>${entity.id}</td>
    </tr>
<tr>
     <td>Price</td>
     <td><input type="text" name="entity.price"
      value="${entity.price}"></td>
    </tr>
<tr>
     <td>Service type</td>
<!-- campo do metaBean serviceType -->
     <td><select id="serviceType" name="entity.service.serviceType"
      onchange="javascript:showServiceDataundefined)">
       <option ${entity.service.serviceType == 'air'? "selected " : ""} value="air">Air</option>
       <option ${entity.service.serviceType == 'hosting'? "selected " : ""} value="hosting">Hosting</option>
     </select></td>
    </tr>
<!-- inicio do formulário do serviço aéreo -->
<tr id="air">
     <td>
      <table width="100%">
       <tbody>
<tr>
         <td>Airplane</td>
         <td><input type="text" name="entity.service.airplane"
          value="${entity.service.serviceType != 'air'? null : entity.service.airplane}"></td>
        </tr>
<tr>
         <td>Departure date</td>
         <td><input type="text" name="entity.service.departureDate"
          value="<fmt:formatDate value="${entity.service.serviceType != 'air'? null : entity.service.departureDate}" pattern="yyyy-MM-dd hh:mm" />"></td>
        </tr>
<tr>
         <td>Arrival date</td>
         <td><input type="text" name="entity.service.arrivalDate"
          value="<fmt:formatDate value="${entity.service.serviceType != 'air'? null : entity.service.arrivalDate}" pattern="yyyy-MM-dd hh:mm" />"></td>
        </tr>
</tbody>
      </table>
</td>
    </tr>
<!-- inicio do formulário do serviço de hospedagem -->
<tr id="hosting">
     <td>
      <table width="100%">
       <tbody>
<tr>
         <td>Hotel</td>
         <td><input type="text" name="entity.service.hotel"
          value="${entity.service.serviceType != 'hosting'? null : entity.service.hotel}"></td>
        </tr>
<tr>
         <td>Checkin</td>
         <td><input type="text" name="entity.service.checkin"
          value="<fmt:formatDate value="${entity.service.serviceType != 'hosting'? null : entity.service.checkin}" pattern="yyyy-MM-dd" />"></td>
        </tr>
<tr>
         <td>Checkout</td>
         <td><input type="text" name="entity.service.checkout"
          value="<fmt:formatDate value="${entity.service.serviceType != 'hosting'? null : entity.service.checkout}" pattern="yyyy-MM-dd" />"></td>
        </tr>
<tr>
         <td>Mealplan</td>
         <td><input type="text" name="entity.service.mealPlan"
          value="${entity.service.serviceType != 'hosting'? null : entity.service.mealPlan}"></td>
        </tr>
<tr>
         <td>Room</td>
         <td><input type="text" name="entity.service.room"
          value="${entity.service.serviceType != 'hosting'? null : entity.service.room}"></td>
        </tr>
</tbody>
      </table>
</td>
    </tr>
</tbody>
   <tfoot>
<tr>
     <td><c:if test="${!empty entity.id}">
       <input type="hidden" name="entity.id" value="${entity.id}">
      </c:if> <input type="submit" value="Submit"></td>
    </tr>
</tfoot>

  </table>
</form>


http://www.brutosframework.com.br/

domingo, 5 de julho de 2015

Brutos Framework 2.0 RC1 Released

The Brutos Application Framework is MVC controller developed in Java. Designed to reduce the complexity of web development, with configurable mapping, view resolution as well as support for uploading and downloading files. Can be configured using XML, annotations and CoC.

Highlights of the 2.0 RC1 release: 

  • added support to polymorphic mapping. 
  • Bean Validation is the default validator provider. 
  • CDI is the default object provider. 

http://www.brutosframework.com.br/