A IBM aplicou toda sua tecnologia e experiência no desenvolvimento
de um servidor de aplicação que é uma versão extendida do Apache Gerônimo: WebSphere Application Server Community Edition.
Essa versão prima pela simplicidade e eficiência em um ambiente
onde você pode criar, implementar, integrar e hospedar suas
aplicações sem custo algum.
Criado sobre Apache Geronimo, o servidor de aplicação Community Edition da IBM utiliza as últimas inovações da comunidade de código aberto, incluindo Apache Tomcat. Você pode usar o WebSphere Application Server Community Edition para desenvolver e hospedar suas aplicações para fins comerciais e pessoais.
O WebSphere Application Server CE simplifica a criação de aplicativos menos críticos de nível departamental com custo mais baixo, baseado em servidor de Aplicativo Java EE Open Source.
Link download: http://www.servidordeaplicacao.com.br/opensource?d=3
Acesse este link e saiba tudo .
Simples e Funcional
Informações técnicas sobre desenvolvimento de software.
org.apache.myfaces.custom.aliasbean.AliasBean
A Tag aliasBean permite criar um nome temporarário para um Bean existente. Ele se torna visível somente à tags filhas do AliasBean.
É como se fosse uma simulação de um novo escopo interno para o JSP, com ele você consegue fazer com quem um pequeno trecho do seu código se comporte com algumas funcionalidades que você teria costumeiramente apenas em uma página nova. Em alguns casos tu conseguirás substituir trechos que podem ser colocados em subViews. Já falamos aqui de alguns pontos importantes em como as subviews são tratadas pelo framework e da alocação limitada que existe automaticamente dependendo da forma como o viewstate esta configurado para as páginas. Neste caso você tanbém poderá utilizar o AliasBean como forma de delegar funções específicas à ela e contidas no seu ALIAS ou temporário Bean.
Veja um exemplo retirado da especificação do MyFaces Tomahawk for JSF 1.1:
<t:aliasBean alias="#{holder}" value="#{aliasTest1}"" >
<f:subview id="simulatedIncludedSubform1">
<h:outputLabel for="name" value="Name:"/>
<h:inputText id="name" value="#{holder.name}"/>
</f:subview>
</t:aliasBean>
Comentários originais desta Tag que citamos aqui:
The aliasBean tag allows you to create a temporary name for a real bean. The temporary name exists (is visible) only to the children of the aliasBean.
One use of this feature is to pass "parameters" from an including page to an included one. The included page can use any name it desires for beans it needs to reference, and the including page can then use aliasBean to make those names refer to the beans it wishes to "pass" as parameters.
Suppose you have a block of components you use often but with different beans. You can create a separate JSP page (or equivalent) containing these beans, where the value-bindings refer to some fictive bean name. Document these names as the required "parameters" for this JSP page. Wherever you wish to use this block you then declare an alias component mapping each of these "parameters" to whatever beans (or literal values) you really want to apply the block to, then use jsp:include (or equivalent) to include the reusable block of components.
Note, however, that AliasBean does not work for component bindings; JSF1.1 just has no mechanism available to set up the alias during the "restore view" phase while the bindings of its children are being re-established, and then remove the alias after the child bindings are done.
As a special case, if this component's direct parent is an AliasBeansScope then the alias (temporary name) is active until the end of the parent component, rather than the end of this component.
FONTE ORIGINAL: http://myfaces.apache.org/tomahawk-project/tomahawk/tagdoc/t_aliasBean.html
É como se fosse uma simulação de um novo escopo interno para o JSP, com ele você consegue fazer com quem um pequeno trecho do seu código se comporte com algumas funcionalidades que você teria costumeiramente apenas em uma página nova. Em alguns casos tu conseguirás substituir trechos que podem ser colocados em subViews. Já falamos aqui de alguns pontos importantes em como as subviews são tratadas pelo framework e da alocação limitada que existe automaticamente dependendo da forma como o viewstate esta configurado para as páginas. Neste caso você tanbém poderá utilizar o AliasBean como forma de delegar funções específicas à ela e contidas no seu ALIAS ou temporário Bean.
Veja um exemplo retirado da especificação do MyFaces Tomahawk for JSF 1.1:
<t:aliasBean alias="#{holder}" value="#{aliasTest1}"" >
<f:subview id="simulatedIncludedSubform1">
<h:outputLabel for="name" value="Name:"/>
<h:inputText id="name" value="#{holder.name}"/>
</f:subview>
</t:aliasBean>
Comentários originais desta Tag que citamos aqui:
The aliasBean tag allows you to create a temporary name for a real bean. The temporary name exists (is visible) only to the children of the aliasBean.
One use of this feature is to pass "parameters" from an including page to an included one. The included page can use any name it desires for beans it needs to reference, and the including page can then use aliasBean to make those names refer to the beans it wishes to "pass" as parameters.
Suppose you have a block of components you use often but with different beans. You can create a separate JSP page (or equivalent) containing these beans, where the value-bindings refer to some fictive bean name. Document these names as the required "parameters" for this JSP page. Wherever you wish to use this block you then declare an alias component mapping each of these "parameters" to whatever beans (or literal values) you really want to apply the block to, then use jsp:include (or equivalent) to include the reusable block of components.
Note, however, that AliasBean does not work for component bindings; JSF1.1 just has no mechanism available to set up the alias during the "restore view" phase while the bindings of its children are being re-established, and then remove the alias after the child bindings are done.
As a special case, if this component's direct parent is an AliasBeansScope then the alias (temporary name) is active until the end of the parent component, rather than the end of this component.
FONTE ORIGINAL: http://myfaces.apache.org/tomahawk-project/tomahawk/tagdoc/t_aliasBean.html
JAXB E O MALDITO NS2
Se você precisou atribuir um namespace a um xml sendo que o marshall precisa ser feito sem declaração de "xmlns:ns2" não tem santo que faça o JAXB remover isso, andei pesquisando bastante e devido à pressa para solucionar o problema achei 2 soluções que não são as melhores, porém resolvem o problema.
1: Remover o nodo do XML ns2 no parse:
# NodeList elements = doc.getElementsByTagName("infNFe");
# Element el = (Element) elements.item(i);
# String id = el.getAttribute("Id");
# // aqui ocorre a remoção do atributo...
# doc.getDocumentElement().removeAttribute("xmlns:ns2");
# ((Element)
# doc.getDocumentElement().getElementsByTagName("NFe").item(0))
# .setAttribute("xmlns", "http://www.portalfiscal.inf.br/nfe");
#
# Create a DOM XMLSignatureFactory that will be used to
# generate the enveloped signature.
#
# Reference ref = fac.newReference("#" + id, fac.newDigestMethod(
# DigestMethod.SHA1, null), transformList, null, null);
Um exemplo completo do código em:
http://www.guj.com.br/posts/list/83758.java
Aqui uma gambiarra que foi usada até que se resolvesse da maneira acima:
// passa-se o file a ser re-formatado como string
public void ajustaXml(File file) throws Exception {
FileReader reader = new FileReader(file);
BufferedReader leitor = new BufferedReader(reader);
leitor.read();
String vlr = "";
StringBuffer vlrFile = new StringBuffer();
String line = leitor.readLine();
while(line != null) {
vlrFile.append( line );
line = leitor.readLine();
}
vlr = vlrFile.toString();
if (vlr.indexOf("ns2:") > -1) {
vlr = vlr.replaceAll("ns2:", "");
}
if (vlr.indexOf(":ns2") > -1) {
vlr = vlr.replaceAll(":ns2", "");
}
leitor.close();
reader.close();
FileWriter writer = new FileWriter(file);
PrintWriter saida = new PrintWriter(writer);
saida.print( "<" + vlr);
writer.close();
saida.close();
}
Ambas maneiras acima resolvem o problema do ns2, e servem para remover o ns2 do jaxb, se alguem tiver uma solução melhor favor comentar.
Assim que eu resolver de forma correta esse problema postarei aqui a resposta.
Abraço
Conforme prometido.. segue solução abaixo:
SOLUÇÃO CORRETA, SEM GAMBIARRAS (Setando um name space preferido) :
SIm, há solução de personalizar os namespaces, no link:
http://blogs.sun.com/enterprisetechtips/entry/customizing_jaxb
Você encontra a solução.
Você precisa criar uma classe que estenda NamespacePrefixMapper vide:
[code]NamespacePrefixMapper m = new PreferredMapper();
marshal(jc, e, m);
public static class PreferredMapper extends NamespacePrefixMapper {
@Override
public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
return "mappedNamespace" + namespaceUri;
}
}[/code]
Depois no seu marshaller voce seta:
[code]final Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");
marshaller.setProperty("com.sun.xml.internal.bind.namespacePrefixMapper",
new NamespacePrefixMapperImpl("http://www.isotc211.org/2005/gmd"));[/code]
Abraço
1: Remover o nodo do XML ns2 no parse:
# NodeList elements = doc.getElementsByTagName("infNFe");
# Element el = (Element) elements.item(i);
# String id = el.getAttribute("Id");
# // aqui ocorre a remoção do atributo...
# doc.getDocumentElement().removeAttribute("xmlns:ns2");
# ((Element)
# doc.getDocumentElement().getElementsByTagName("NFe").item(0))
# .setAttribute("xmlns", "http://www.portalfiscal.inf.br/nfe");
#
# Create a DOM XMLSignatureFactory that will be used to
# generate the enveloped signature.
#
# Reference ref = fac.newReference("#" + id, fac.newDigestMethod(
# DigestMethod.SHA1, null), transformList, null, null);
Um exemplo completo do código em:
http://www.guj.com.br/posts/list/83758.java
Aqui uma gambiarra que foi usada até que se resolvesse da maneira acima:
// passa-se o file a ser re-formatado como string
public void ajustaXml(File file) throws Exception {
FileReader reader = new FileReader(file);
BufferedReader leitor = new BufferedReader(reader);
leitor.read();
String vlr = "";
StringBuffer vlrFile = new StringBuffer();
String line = leitor.readLine();
while(line != null) {
vlrFile.append( line );
line = leitor.readLine();
}
vlr = vlrFile.toString();
if (vlr.indexOf("ns2:") > -1) {
vlr = vlr.replaceAll("ns2:", "");
}
if (vlr.indexOf(":ns2") > -1) {
vlr = vlr.replaceAll(":ns2", "");
}
leitor.close();
reader.close();
FileWriter writer = new FileWriter(file);
PrintWriter saida = new PrintWriter(writer);
saida.print( "<" + vlr);
writer.close();
saida.close();
}
Ambas maneiras acima resolvem o problema do ns2, e servem para remover o ns2 do jaxb, se alguem tiver uma solução melhor favor comentar.
Assim que eu resolver de forma correta esse problema postarei aqui a resposta.
Abraço
Conforme prometido.. segue solução abaixo:
SOLUÇÃO CORRETA, SEM GAMBIARRAS (Setando um name space preferido) :
SIm, há solução de personalizar os namespaces, no link:
http://blogs.sun.com/enterprisetechtips/entry/customizing_jaxb
Você encontra a solução.
Você precisa criar uma classe que estenda NamespacePrefixMapper vide:
[code]NamespacePrefixMapper m = new PreferredMapper();
marshal(jc, e, m);
public static class PreferredMapper extends NamespacePrefixMapper {
@Override
public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
return "mappedNamespace" + namespaceUri;
}
}[/code]
Depois no seu marshaller voce seta:
[code]final Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");
marshaller.setProperty("com.sun.xml.internal.bind.namespacePrefixMapper",
new NamespacePrefixMapperImpl("http://www.isotc211.org/2005/gmd"));[/code]
Abraço
Aprenda a adicionar BIRT Reporting a aplicações usando RichFaces
"Learn how to add BIRT Reporting to JSF Applications using RichFaces"
Pessoal, vai acontecer um webcast ao vivo no dia 9 de fevereiro. Pode ser bem produtivo, é uma iniciativa Exadel.
Confira mais detalhes no link abaixo:
http://www.actuate.com/be/info/techexadelwsem/
Nos "vemos" lá.
Pessoal, vai acontecer um webcast ao vivo no dia 9 de fevereiro. Pode ser bem produtivo, é uma iniciativa Exadel.
Confira mais detalhes no link abaixo:
http://www.actuate.com/be/info/techexadelwsem/
Nos "vemos" lá.
Manuseando a propriedade NUMBER_OF_VIEWS_IN_SESSION
Mais um post referente à Java Server Faces e relacionado ao anterior sobre a propriedade javax.faces.STATE_SAVING_METHOD.
É importante saber que existe um limite de Views a serem mantidos em Session, esse número de views, inclui qualquer tela que seja submetida simultâneamente em uma mesma sessão. Importante: Subviews tanbém contam (e como).
Para resolver este problema, em casos onde você precisa que sua sessão dure bastante tempo e com muitas views a serem guardadas, você pode ampliar este número (o padrão é 20), segue um exemplo de configuração que pode ser incorporada no seu web.xml:
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>200</param-value>
<description>Only applicable if state saving method is "server" (= default).
Defines the amount (default = 20) of the latest views are stored in session.
</description>
</context-param>
No exemplo acima foi definido o número de 200 views, porém use com prudência essa propriedade, economize objetos em sessão e ganhe performance em sua aplicação.
É importante saber que existe um limite de Views a serem mantidos em Session, esse número de views, inclui qualquer tela que seja submetida simultâneamente em uma mesma sessão. Importante: Subviews tanbém contam (e como).
Para resolver este problema, em casos onde você precisa que sua sessão dure bastante tempo e com muitas views a serem guardadas, você pode ampliar este número (o padrão é 20), segue um exemplo de configuração que pode ser incorporada no seu web.xml:
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>200</param-value>
<description>Only applicable if state saving method is "server" (= default).
Defines the amount (default = 20) of the latest views are stored in session.
</description>
</context-param>
No exemplo acima foi definido o número de 200 views, porém use com prudência essa propriedade, economize objetos em sessão e ganhe performance em sua aplicação.
javax.faces.STATE_SAVING_METHOD pode resolver problemas
Após algum tempo sem escrever no blog, venho aproveitar a ocasião para descrever uma experiência que tive durante a resolução de um problema.
A maioria dos desenvolvedores que utiliza o framework JavaServerFaces acaba adotando por regra determinar a propriedade STATE_SAVING_METHOD como client, deixando a validação da renderização dos componentes no cliente ( cria-se um input hidden com o nome de ViewState ), é possível também deixar que essa responsabilidade fique no servidor de aplicações, definindo assim a propriedade com o valor "server".
Basta verificar a seguinte configuração em seu web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
Caso exista algum problema de validação na estrutura do seu código ( jspx, jsp, jsf ), e a propriedade server estiver definida, será possível que a validação ocorra em linha, ou seja, antes de renderizar a página o servidor irá fazer todas as validações necessárias ( se existe tal propriedade ou metodo, se existe mais de 1 componente com mesmo id, se seus conversores estao definidos de maneira correta, etc ), pois bem, muitas dessas validações são feitas indiferentemente do que se define no "saving_method", porém em alguns casos o "client" pode falhar.
Ex: Caso você tenha utilizado jstl para fazer alguma verificação dos componentes, ex:
<c:choose>
<c:when> test="${meuMBean.minhaCondicao}"
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:when>
</c:otherwise>
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:otherwise>
</c:choose>
Obs: Veja que o ID é o mesmo, isso não pode.
Nesses casos, a validação client pode falhar. Muitos poderão dizer que o motivo é essa mistura do JSTL com JSF, porém em muitos casos se faz necessária, além de que você nunca sabe o que foi escrito no código antes de dar manutenção no mesmo, e pode ser que pensem diferente de você, portanto é preciso estar preparado para todos os casos. Outro argumento à favor é o fato de ser permitida essa adição, então se é permitida, logo é possível que ocorra e se o código funcionar assim, poderá causar erros inexplicáveis na aplicação, pois no momento em que for para o server, a validação irá falhar (e pode falhar de forma intermitente, digo isso como experiência propria que tive em uma aplicação).
Pois bem, adicionando em sua aplicação a propriedade SERVER, esse trecho de código acima, será rejeitado sempre, não deixando que nenhuma execução problemática ocorra.
Nota: Utilizei neste projeto myfaces1.1.7, tomahawk 1.9 e trinidad-api-1.0.11.jar
A maioria dos desenvolvedores que utiliza o framework JavaServerFaces acaba adotando por regra determinar a propriedade STATE_SAVING_METHOD como client, deixando a validação da renderização dos componentes no cliente ( cria-se um input hidden com o nome de ViewState ), é possível também deixar que essa responsabilidade fique no servidor de aplicações, definindo assim a propriedade com o valor "server".
Basta verificar a seguinte configuração em seu web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
Caso exista algum problema de validação na estrutura do seu código ( jspx, jsp, jsf ), e a propriedade server estiver definida, será possível que a validação ocorra em linha, ou seja, antes de renderizar a página o servidor irá fazer todas as validações necessárias ( se existe tal propriedade ou metodo, se existe mais de 1 componente com mesmo id, se seus conversores estao definidos de maneira correta, etc ), pois bem, muitas dessas validações são feitas indiferentemente do que se define no "saving_method", porém em alguns casos o "client" pode falhar.
Ex: Caso você tenha utilizado jstl para fazer alguma verificação dos componentes, ex:
<c:choose>
<c:when> test="${meuMBean.minhaCondicao}"
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:when>
</c:otherwise>
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:otherwise>
</c:choose>
Obs: Veja que o ID é o mesmo, isso não pode.
Nesses casos, a validação client pode falhar. Muitos poderão dizer que o motivo é essa mistura do JSTL com JSF, porém em muitos casos se faz necessária, além de que você nunca sabe o que foi escrito no código antes de dar manutenção no mesmo, e pode ser que pensem diferente de você, portanto é preciso estar preparado para todos os casos. Outro argumento à favor é o fato de ser permitida essa adição, então se é permitida, logo é possível que ocorra e se o código funcionar assim, poderá causar erros inexplicáveis na aplicação, pois no momento em que for para o server, a validação irá falhar (e pode falhar de forma intermitente, digo isso como experiência propria que tive em uma aplicação).
Pois bem, adicionando em sua aplicação a propriedade SERVER, esse trecho de código acima, será rejeitado sempre, não deixando que nenhuma execução problemática ocorra.
Nota: Utilizei neste projeto myfaces1.1.7, tomahawk 1.9 e trinidad-api-1.0.11.jar
ATOM É O MENOR PROCESSADOR FEITO PELA INTEL
Saiu no Informativo Geral: http://www.informativogeral.com.br/?post=ATOM-O-MENOR-PROCESSADOR-DA-INTEL.
Confira esta matéria completa sobre este revolucionário processador. Com palavras dos próprios executivos da intel, responsáveis pela coordenação geral do seu desenvolvimento. Uma tecnologia de várias décadas que vem evoluindo com o passar dos anos.
Confira esta matéria completa sobre este revolucionário processador. Com palavras dos próprios executivos da intel, responsáveis pela coordenação geral do seu desenvolvimento. Uma tecnologia de várias décadas que vem evoluindo com o passar dos anos.
Assinar:
Postagens (Atom)