Um bean é uma classe Java com nomes de métodos que seguem as diretrizes do Java Bean (também chamadas de padrões de design) para propriedades , métodos e eventos. Portanto, qualquer método público da classe de bean que não faça parte de uma definição de propriedade é um método de bean. No mínimo, uma classe Java, mesmo com uma propriedade como o único membro (é claro, é necessário acompanhar o getter e o setter públicos), um método público como o único membro ou apenas um método de registro de ouvinte de eventos públicos é um bean Java. Além disso, a propriedade pode ser propriedade somente leitura (possui um método getter, mas não setter) ou propriedade somente gravação (possui apenas um método setter). O Java bean precisa ser uma classe pública para estar visível a qualquer ferramenta ou contêiner do beanbox. O contêiner deve ser capaz de instanciar; portanto, também deve ter um construtor público. A especificação JavaBeansnão exige que um bean tenha um construtor público de zero argumentos, explícito ou padrão, para que um contêiner o instancie. Se você pudesse fornecer um arquivo (com extensão .ser) contendo uma instância serializada, uma ferramenta beanbox poderia usar esse arquivo para instanciar um bean protótipo. Caso contrário, o bean deve ter um construtor público de zero-args, explícito ou padrão.
Depois que o bean é instanciado, a API do Java Bean (java.beans. *) Pode examiná-lo e chamar métodos nele. Se nenhuma classe implementando a interface BeanInfo ou estendendo uma implementação BeanInfo, classe SimpleBeanInfo, estiver disponível, a introspecção envolve o uso de reflexão (introspecção implícita) para estudar os métodos suportados por um bean de destino e, em seguida, aplicar padrões de design simples (as diretrizes) para deduzir de a esses métodos, quais propriedades, eventos e métodos públicos são suportados. Se uma classe que implementa a interface BeanInfo (para um bean Foo, deve ser nomeado FooBeanInfo) está disponível, a API ignora a introspecção implícita e usa métodos públicos (getPropertyDescriptor (), getMethodDescriptors (), getMethodDescriptors (), getEventSetDescriptors ()) dessa classe para obter o em formação. Se uma classe estendendo SimpleBeanInfo estiver disponível, dependendo de qual dos métodos públicos SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) são substituídos, ele usará esses métodos substituídos para obter informações; para um método que não seja substituído, o padrão será a introspecção implícita correspondente. Um bean precisa ser instanciado de qualquer maneira, mesmo que nenhuma introspecção implícita seja realizada nele. Assim, a exigência de um construtor público zeri-args. Mas, é claro, a interface Serializable ou Externalizable não é necessária para ser reconhecida. No entanto, a especificação do Java Bean diz: 'Também gostaríamos que fosse "trivial" para o caso comum de um Bean minúsculo que simplesmente quer ter seu estado interno salvo e não quer pensar nisso ". Portanto, todos os beans devem implementar a interface Serializable ou Externalizable. No geral, A especificação JavaBeans não é rígida e rápida sobre o que constitui um bean. "Escrever componentes JavaBeans é surpreendentemente fácil. Você não precisa de uma ferramenta especial e não precisa implementar nenhuma interface. Escrever beans é simplesmente uma questão de seguir certas convenções de codificação. Tudo o que você precisa fazer é fazer com que sua classe pareça um bean - ferramentas que usam beans poderão reconhecer e usar seu bean ". Trivialmente, até a classe a seguir é um Java Bean,
public class Trivial implements java.io.Serializable {}
Digamos, um construtor de bean possui alguns parâmetros. Suponha que alguns sejam tipos simples. O contêiner pode não saber quais valores atribuir a eles; mesmo que isso aconteça, a instância resultante pode não ser reutilizável. Pode fazer sentido apenas se o usuário puder configurar (especificar valores) digitando anotações ou arquivos de configuração xml como nos beans Spring. E suponha que alguns parâmetros sejam de classe ou de interface. Novamente, o contêiner pode não saber quais valores atribuir a ele. Pode fazer sentido apenas se o usuário puder configurar (especificar objetos específicos) digitando anotações ou arquivos de configuração xml. No entanto, mesmo no Spring (via arquivos de configuração xml), atribuir objetos específicos (com nomes de string) a argumentos do construtor (atributo ou elemento dos argumentos do construtor) não é tipicamente seguro; é basicamente como injeção de recurso. Fazer referências a outros beans Spring (chamados de colaboradores; via elemento em um elemento de argumento do construtor) é basicamente injeção de dependência e, portanto, tipicamente seguro. Obviamente, uma dependência (bean colaborador) pode ter um construtor com parâmetros injetados; essas dependências injetadas podem ter um construtor com parâmetros e assim por diante. Nesse cenário, em última análise, você precisaria de algumas classes de bean (por exemplo, MyBean.class) que o contêiner possa instanciar simplesmente chamando new MyBean () antes de poder construir os outros beans colaboradores via injeção de dependência nos construtores - portanto, o requisito para os beans para ter o construtor público zero-args. Suponha que, se um contêiner não suportar injeção de dependência e / ou não permitir atribuir valores de tipo simples ao construtor por meio de algumas anotações ou arquivos de configuração xml, como no Spring, construtores de bean não devem ter parâmetros. Mesmo um aplicativo Spring beans precisaria de alguns beans para ter um construtor público de zero-args (por exemplo, em um cenário em que seu aplicativo Spring não possui bean com apenas tipos simples como argumentos do construtor).
Os beans gerenciados JSF são executados em um contêiner da web. Eles podem ser configurados com a anotação @ManagedBean ou com um arquivo de recurso de configuração de aplicativo managed-bean.xml. No entanto, ele suporta injeção apenas por injeção de recursos (não tipesafe); não é adequado para injeção em construtores. A especificação JSFrequer que os beans gerenciados tenham um construtor público de argumento zero. Além disso, diz: “A partir da versão 2.3 desta especificação, o uso do recurso de bean gerenciado, conforme especificado nesta seção, é fortemente desencorajado. Uma solução melhor e mais coesa integrada para resolver o mesmo problema é usar CDI (Injeção de Dependência e Contexto), conforme especificado no JSR-365. "Em outras palavras, os beans gerenciados CDI a serem usados, que oferecem injeção de dependência segura em construtores semelhante Spring beans. A especificação CDI adota a especificação Managed Beans, que se aplica a todos os contêineres da plataforma JEE, não apenas à camada da Web. Portanto, o contêiner da Web precisa implementar a especificação CDI.
Aqui está um extrato da especificação do Managed Bean
“Beans gerenciados são objetos gerenciados por contêineres com requisitos mínimos, também conhecidos sob o acrônimo“ POJOs ”(Plain Old Java Objects) ... eles podem ser vistos como uma versão aprimorada da plataforma Java EE do modelo de componente JavaBeans encontrado na plataforma Java SE ... O leitor não sentirá falta de que o Managed Beans tenha um precursor no recurso homônimo encontrado na tecnologia JavaServer Faces (JSF) ... O Managed Beans, conforme definido nesta especificação, representa uma generalização daqueles encontrados no JSF; em particular, o Managed Beans pode ser usado em qualquer lugar em um aplicativo Java EE, não apenas em módulos da web. Por exemplo, no modelo de componente básico, o Managed Beans deve fornecer um construtor sem argumento, mas uma especificação que se baseia no Managed Beans, como CDI (JSR-299), pode relaxar esse requisito e permitir que o Managed Beans forneça aos construtores assinaturas mais complexas, desde que sigam algumas regras bem definidas ... Um Bean Gerenciado não deve ser: uma classe final, uma classe abstrata, uma classe interna não estática . Um Managed Bean pode não ser serializável, diferentemente de um componente JavaBean comum. ” Portanto, a especificação para Managed Beans, também conhecida como POJOs ou POJO beans, permite a extensão como no CDI.
A especificação CDI redefine os beans gerenciados como: Ao executar no Java EE, uma classe Java de nível superior é um bean gerenciado se atender aos requisitos:
• Não é uma classe interna. • É uma classe não abstrata ou está anotada em @Decorator. • Não implementa javax.enterprise.inject.spi.Extension. • Não está anotado em @Vetoed ou em um pacote anotado em @Vetoed. • Possui um construtor apropriado: a classe possui um construtor sem parâmetros ou a classe declara um construtor anotado como @Inject.
Todas as classes Java que atendem a essas condições são beans gerenciados e, portanto, nenhuma declaração especial é necessária para definir um bean gerenciado. Ou
se for definido como um bean gerenciado por qualquer outra especificação Java EE e se
• Ele não é anotado com uma anotação de definição de componente EJB ou declarado como uma classe de bean EJB em ejb-jar.xml.
Ao contrário dos beans Spring, ele não suporta construtores com tipos simples, o que pode ser possível se oferecer suporte à configuração com arquivos de configuração xml, como no Spring ou em qualquer anotação.
Os EJBs são executados em um contêiner EJB. Sua especificaçãodiz: "Um componente do bean de sessão é um Bean Gerenciado". "A classe deve ter um construtor público que não aceita argumentos", diz o bean de sessão e o bean acionado por mensagens. Além disso, ele diz: "A classe do bean de sessão é não é necessário para implementar a interface SessionBean ou a interface serializável. " Pelo mesmo motivo que os beans JSF, como a injeção de dependência EJB3 é basicamente a injeção de recursos, os beans JSF não suportam construtores com argumentos, ou seja, via injeção de dependência.No entanto, se o contêiner EJB implementar CDI, “Opcionalmente: a classe pode ter um construtor adicional anotado com a anotação Inject ", diz para o bean de sessão e o bean acionado por mensagens porque:" Um EJB empacotado em um archive de bean CDI e não anotado com a anotação javax.enterprise.inject.Vetoed é considerado um CDI ativado feijão."