Mensagens enviadas por: derlon

@PessoALL,

andei pesquisando sobre o Spring / Spring 3 reconhecer a Annotation @Inject (e tb a @Named) e, pelo o q observei, devemos baixar (e adicionar no Classpath) o javax.inject-x.x.x.jar file.

Eu executei este mesmo procedimento, porem não consegui fazer o das referidas @s (tão pouco é reconhecido o pacote javax.inject).

Será q preciso fazer + alguma coisa??! Plz, help me/us!!!

Flavio machine wrote:Entendi o hibernate pode fazer o seu próprio poll de conexões, mas não usa um data source.

Na verdade, um "pool de conexões" implica(só pode ser criado) num DataSource, este podendo ser definido tanto localmente na sua App. como num Container Java.
Inclusive, estes "Poolled-DataSource"s realmente implementam a interface 'javax.sql.DataSource'. O Hibernate é naturalmente compatível com algumas dessas implementações: C3P0, DBCP, Proxool; sem falar na nativa do Hibernate, q a Hibernate não se cansa de indicar para não ser usada em Produção, por não ser robusta, etc..
Vide: é natural!!

Mas, por enquanto eskeça tudo isto.

Flavio machine wrote:O spring faz uma integração entre o hibernate e o data source ai você vai usar o pool de conexões do servidor e não do hibernate.

A proposta (boa a princípio) do Yury é definir 1 DataSource (Local) via Spring para podermos fazer Testes, inclusive de Performance/Carga (DataSource de Container: 1 Pool com determinada qtd. de conexões), simulando o Ambiente real de Produção. Para isso, ele definine 1 DataSource usando a Implementação C3P0; só q isso ele propõe a abordagem de settar a configuração do cpds (usando 1 ".PropertyPlaceholderConfigurer")via arquivo 'jdbc.properties'. (O problema é q isto traz 1 efeito colateral: a configuração de conexão (acesso ao BD) acaba ficando definida em 2 lugares; veja só a ambiguidade: sempre q vc, p/ acaso precise mundar qq coisa na confg, p/ex. a senha (ou ainda, o NomeDeAcesso), vai ter q fazer isso em 2 lugares, no 'jdbc.properties' e tb na PU do 'persistence.xml'. (Até este ponto, todo seu Caso de Unit Test tem q estar "passando", p/menos com o DataSource local! Ah, já ia me eskecendo: configure a Injeção de Dependencias via XML mesmo; faça sua aplicação (UnitTest) funcionar o + simples possível, mas p/- faça funcionar.

)
Pois bem, a partir daí este 'dataSource' é injetado em um ".LocalContainerEntityManagerFactoryBean".

Mas, de todo jeito, quando vc for definir 1 applicationContext para Produção, invariavelmente, vai ter q definir o 'dataSource', só q, desta vez, vai ter q recuperá-lo(do Container) via JNDI.

Flavio machine wrote:Porquê vc acha melhor eu tentar no tomCat ?

Simples, pq vc pode seguir a Documentação do TomCat, q é muito simples e objetiva, isso sem falar q deve chover de Tuts em portugues do TomCat. Sem mencionar, q o TomCat é muito + fácil de configurar e Starta bem + rápido q o JBoss.

Flavio machine wrote:Tenho interrese nas dicas sim. Vamo lá.
Obrigado

Bom, o basicão é isso aí... Se tiver dúvidas, problemas.. é só postar!!

@Flavio, apenas 1 mal-entendido. :/ no problm!

@kubanacan,
Me parece q vc não teve 1 sacada do o q o Spring é e pq q ele serve.
No seu setUp vc adiciona 1 'persistence.xml', mas no Spring vc insiste numa configuração Hibernate puro.

Em vez de usar JBoss, tente primeiro com o TomCat, seguindo suas Instruções de como definir 1 DataSource no Container Java.

Em todo caso, se vc quer ter sucesso no q precisa e decidir seguir algumas dicas q posso te passar é muito provável q vc chegue lá...

Se tiver a fim, é só avisar,

]o['s,

Por acaso vc tah testando (a gente)?!

..

..ou, vc tah me tirando?!

Então, (atendendo a pedidos

) continuando o exemplo (JUnit no topo do Business-Core): Aki está o 'persistence.xml':

<persistence ... >
  <persistence-unit name="agendaJPA2-corePU" transaction-type="RESOURCE_LOCAL">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    
    <properties>
      <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/agenda"/>
      <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
      <property name="javax.persistence.jdbc.user" value="root"/>
      <property name="hibernate.connection.password" value=""/>
      <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/>
    </properties>
  </persistence-unit>
  <persistence-unit name="agendaJPAds-corePU" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    
    <jta-data-source>jdbc/agendaDS</jta-data-source>
    <properties/>
  </persistence-unit>
</persistence>

(Obs.: substitua todos "agenda" pelo nome da sua Base de Dados.) Agora o 'appTestContext.xml' (deve ser adicionado o'.LocalEntityManagerFactoryBean' postado anteriormente):
O 'applicationContext.xml' p/ ser usado p/ Aplicação em Produção (inclusive se vc deseja configurar o Transacional explicitamente no Spring usando a abordaem da JTA API):

<beans xmlns=... >

    <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
		<property name="environment">
			<props>
				<prop key="java.naming.factory.initial">com.sun.jndi.fscontext.RefFSContextFactory</prop>
				<prop key="java.naming.provider.url">file:/</prop>
			</props>
		</property>
	</bean>

    <bean id="jndiDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiTemplate">
              <ref bean="jndiTemplate"/>
        </property>
        <property name="jndiName">
              <value>java:/comp/env/jdbc/agendaDS</value>
        </property>
    </bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        
       <property name="dataSource" ref="jndiDataSource"></property>
       <property name="persistenceUnitName" value="agendaJPAds-jarPU" />
       <property name="jpaPropertyMap">
          <map>
            <entry key="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
            <entry key="hibernate.transaction.flush_before_completion" value="true"/>
            <entry key="hibernate.transaction.auto_close_session" value="true"/>
            <entry key="hibernate.current_session_context_class" value="jta"/>
            <entry key="hibernate.connection.release_mode" value="auto"/>
          </map>
       </property>
        
       <property name="persistenceUnitPostProcessors">
          <list>
             
             <bean class="JtaPersistenceUnitPostProcessor">
                <property name="jtaMode" value="true"></property>
                <property name="jtaDataSource" ref="jndiDataSource"></property>
             </bean>
          </list>
       </property>
        
       <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="showSql" value="true" />
                <property name="generateDdl" value="false" />
                
                <property name="databasePlatform" value="org.hibernate.dialect.MySQL5Dialect" />
            </bean>
       </property>
    </bean>

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
       <property name="transactionManagerName" value="java:/TransactionManager"></property>
       <property name="autodetectUserTransaction" value="false"></property>
    </bean>

<tx:annotation-driven/>
    
    
    <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
    
    
    <bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

<import resource="appObjetos.xml" />
</beans>

Obs.: a implementação da Classe "JtaPersistenceUnitPostProcessor", pode ser obtida no link fornecido anteriormente.
Agora o "appObjetos.xml" (usado por ambos 'app*Context.xml's):

<context:annotation-config/>
	    <context:component-scan base-package="domain.srvcFacade,domain.repository" use-default-filters="false">
            <context:include-filter type="annotation" expression="org.springframework.stereotype.Service"/>
            <context:include-filter type="annotation" expression="org.springframework.stereotype.Repository"/>
	        
	    </context:component-scan>
    <bean id="usuario" class="domain.model.Usuario" scope="session" />
    
    <bean ... >
</beans>

Eventualmente 1 DAO seguindo o padrão: O 'Domain Service': E finalmente o Caso de Teste 'UsuarioServiceFcdTest.java': voi la

public class UsuarioServiceFcdTest {
    
    private ApplicationContext context;
    UsuarioServiceFcd usuarioServiceFcd;
 /*...*/
        System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.fscontext.RefFSContextFactory");
        System.setProperty(Context.PROVIDER_URL, "file:/"); // change provider url to a platform specific path
        Context registry = new InitialDirContext();
        // create a new connection pool data source, read the properties
        // file
        // and bind it to a name
        ComboPooledDataSource cpds = new ComboPooledDataSource();
        Properties dsProperties = new Properties();
        FileInputStream cpdsPropFile = new FileInputStream("C:/..**pathDirSeuProjeto**../test/jdbc.properties");// myconnection.properties created in step1
        dsProperties.load(cpdsPropFile);
        try {
            cpds.setDriverClass(dsProperties.getProperty("driverClass"));
        } catch (PropertyVetoException ex) {
            Logger.getLogger(UsuarioServiceFcdTest.class.getName()).log(Level.SEVERE, null, ex);
        }
        cpds.setUser(dsProperties.getProperty("user"));
        cpds.setDescription("java:/comp/env/jdbc/agendaDS" + " Data Source"); //replace MYCONNECTIONKEY with the key you wish to use for lookup
        cpds.setPassword(dsProperties.getProperty("password"));
        cpds.setJdbcUrl(dsProperties.getProperty("jdbcUrl"));
        cpds.setIdleConnectionTestPeriod(1800);
        cpds.setMaxIdleTime(3000);
        cpds.setMaxStatements(50);
        cpds.setMaxPoolSize(5);
        cpds.setInitialPoolSize(3);
        cpds.setAcquireIncrement(5);
        cpds.setMinPoolSize(2);
        cpds.setTestConnectionOnCheckin(true);

Connection conC3PO = cpds.getConnection();
        if (conC3PO != null){
            System.out.println(" Success ; ;"); //Success
        // ...
                registry.rebind("java:/comp/env/jdbc/agendaDS", cpds); //datasource
                // "closing" a connection sends it back to the pool
                conC3PO.close();
        } else {
        //Something wrong
        }

InitialContext ic = new InitialContext();
        //    ic.createSubcontext("java:");
        //    ic.createSubcontext("java:/comp");
        //    ic.createSubcontext("java:/comp/env");
        //    ic.createSubcontext("java:/comp/env/jdbc");
            // Construct DataSource = /* ...*/
        //    ic.bind("jdbc/agendaDS", datasource);

//    Context webContext = (Context)ic.lookup("java:/comp/env");
        DataSource datasource2 = (DataSource)ic.lookup("java:/comp/env/jdbc/agendaDS"); //DataSource datasource2 = (DataSource)webContext.lookup("jdbc/agendaDS") 
    //
        try {
             System.out.println("DB Schema/Catalog is " + datasource2.getConnection().getCatalog().toString() ); //*StartedUp JNDI.
            Connection con = datasource2.getConnection(); // ds.getConnection("genius", "abracadabra")
            System.out.println("Ds Context name is " +  con.getCatalog().toString() );//datasource2.getConnection() *StartedUp JNDI.datasource2.getConnection().
            //con.setAutoCommit(false);
            //PreparedStatement pstmt = (PreparedStatement)con.prepareStatement( //
            //                            "SELECT * FROM usuario"); // NAME, NAME, TITLE TITLEPERSONNEL WHERE DEPT = ?
            ////pstmt.setString(1, "SALES");
            //ResultSet rs = pstmt.executeQuery();
            String sQry = "SELECT * FROM usuario"; //any sQry
            Statement stmt = (Statement)con.prepareStatement(sQry);
            ResultSet rs = stmt.executeQuery(sQry); // sQry

System.out.println("(testando) Buscando dados..."); // Sales Department:
            while (rs.next() ) {
                    String name = rs.getString("NoME");
                    String title = rs.getString("login");
                    System.out.println(name + "  ; ;" + title);
            }
            rs.close();
            stmt.close();
            con.close();
        } catch (SQLException ex) {
            Logger.getLogger(UsuarioServiceFcdTest.class.getName() ).log(Level.SEVERE, null, ex);
            throw new SQLException("SQLException: " + ex.getMessage() );
        }
    //    System.out.println("JNDI Context name is " + JNDIUnitTestHelper.getJndiName() );//*StartedUp JNDI.
        context = new ClassPathXmlApplicationContext("appTestContext.xml"); // applicationContext // *2 <- pode alternar quando estiver c/ o ambiente funcionando.
        usuarioServiceFcd = (UsuarioServiceFcd)context.getBean("usuarioServiceFcd");
  /*...*/
    @Test
    public void gravar() {
        
        System.out.println("gravar usuário");
        
        Usuario result = usuarioServiceFcd.gravar(usuarioTeste);
        try {
            assertNotNull(result.getIdUsuario() );
        } catch (AssertionError e){
            fail("Falhou a gravação de usuário! Falha: " + e.getMessage() );
        }
    }

*2

<- ah e, a propósito, use a ferramenta de geração de JUnit Test's do netBeans e implemente seus testes a gosto (claro, sempre implemente os Testes Unitários antes de implementar qq funcionalidade)TDD!!!

(Vc ficou me devendo a versão do seu netBeans. Aproveita e me passa a do Hibernate (presumo 3.5+) e o seu Spring (q parece ser a 3.x+: pq tentou usar @Resource).)
Clareou 1 pouco?!!

Flavio machine wrote:Cara valeu pela força, eu tive dando uma estudada e é oque meu chefe me pediu, para estabelecer uma conexão global e nao local pelo oque eu olhei na sua forma vc usa uma forma de conexão local, <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean" > , ai eu vi umas configurações no pdf reference que vem junto do spring para fazer uma conexão global, então fiz o seguinte.

Flavio, o 'LocalEntityManagerFactoryBean' cria 1 EntityManagerFactory usando a conexão padrão de sua PU, sendo q esta conexão pode ser definida tanto por acesso direto como referenciando 1 DataSource (q. por sua vez, é 1 recurso global do seu container). No seu caso, não importa qual EntityManagerFactory vc use, se ela referencia a sua PU (<persistence-unit name="TotalsatCommonTestPU" transaction-type="JTA"> ) e essa PU já referencia 1 DataSource (<jta-data-source>jdbc/_financeiro</jta-data-source> ): isto, por si só, já significa q a Factory de EntityManager cria 1 EntityManager usando 1 recurso global (o DataSource de seu Container) e isso usando o Transacional JTA.
Mas, tudo bem! Se ainda quer obter o DataSource através de configuração explicita no Spring: sem problema. Obs.: apenas ouvi dizer q quando vc injeta o 'dataSource' no ".LocalContainerEntityManagerFactoryBean" e a sua aplicação se tornar larga escala "pode ser" q ela fique 1 pouco + lenta. Mas, funcionando, é o q importa (p/- no 1º momento). Entretanto, percebo algumas coisas q são potenciais problemas:

Flavio machine wrote:
<bean id="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" />

Aki vc alterou o nome padrão (transactionManager) do ".JtaTransactionManager" para "txManager". Se não o referenciou explicitamente no <tx:annotation-driven/> pode ser q haja algum problema na parte transacional.

Flavio machine wrote:
<context:annotation-config /> <bean id="dao" class="com.br.totalsat.dao.Dao" /> // Porém quando coloco essa tag <context:component-scan base-package="com.totalsat.control"> ta exception, mas ela não seria obrigatória para eu injetar o dao ?

Veja bem, vc deve injetar os seus Repositorys (no seu caso, DAOs) nos respectivos DomainServices. Isto geralmente era/é feito de forma declarativa no applicationContext.xml assim: O annotation-config /> e "component-scan" devem ser usados quando, em vez de via XML, vc deseja fazer Injeção de Dependencias via Java Annotations. Por exemplo, assim:
Creio q vc deve ter se equivocado no 'base-package="com.totalsat.control" '. No meu exemplo, inicialmente eu consegui fazer funcionar (como vc pode observar) configurando o base-package como "domain"(o qual é o pacote base dos SubPacotes 'srvcFacade' e 'repository'). (Esse pacote 'control' se refere ao FrontController, ou a 1 tipo de "Gerenciador", algo +/- como 1 DomainService??!)

Flavio machine wrote:Meu percistence ta ´so assim .. <persistence-unit name="TotalsatCommonTestPU" transaction-type="JTA"> ... Me dao ta assim .. @PersistenceContext(name="persitenceFinaceiro") public void setEntityManager(EntityManager entityManager) { ...

Vc declara sua PU como 'persistence-unit name="TotalsatCommonTestPU" ' e referencia como "persitenceFinaceiro". Aconselho fortemente evitar essa ambiguidade, pq, mesmo q sua aplicação funcione, qq 1 q for ver o código não vai saber se ela usa a PU "TotalsatCommonTestPU" ou a PU "persitenceFinaceiro".

Flavio machine wrote:.. public class Test { @Resource private Dao dao; ...Seguinte esas é uma aplicação de teste, quando funcionar agente vai trabalhar em cima.

Boa idéia. *2 Aliás, melhor ainda

se vc encapsulasse o Domínio (Fluxo, Lógica e Regras de Negócio), Infra e Perisistência num Projeto JavaSE "Business-Core" (ou, de preferencia: Biblioteca de Classes) empacotado em um .JAR, q poderia servir várias Aplicações Cliente (apresentações), sendo importado por estas. Daí, vc poderia fazer JUnit Testes no topo dos DomainServices (neste testes, vc poderia testar a Persistencia e o recurso Transacional)

Flavio machine wrote:
Agora pelo menos quando eu faço o deploy na esta mais dando exception, o problema é que quando eu dou um save ele ta dando nullPointer
Abrigado pela força vou dar uma olhada no link quq vc me passou.

O problema é que os casos de JUnit Testes não estão exatamente no mesmo contexto q os "Spring beans" (Objetos do Domínio (da Aplicação) instanciados e gerenciados pelo Spring). Este contexto dever ser criado usando outra abordagem (algo como: context = new ClassPathXmlApplicationContext("applicationContext.xml" ); ). Para esta finalidade é desejável definir 1 'persistence.xml' com 2 PU (1 com conexão configurada diretamente, pois vc não vai estar no Contexto Java Web/EE, e outra PU acessando realmente o DataSource q deve ser usando em Produção); e vc tb teria q manter 2 'applicationContext.xml's: 1 p/ a App em Produção e o outro para Teste (p/ex.: 'appTestContext.xml'). A vantagem disto é q vc pode fazer os testes totalmente independente de Container!!

Então, (atendendo a pedidos

) continuando o exemplo (JUnit no topo do Business-Core): ('persistence.xml') *1 <- mudei de idéia: vou colocar o exemplo em outro post pq este aki já está longo D+ (e tb p/ organização)!

Flavio,
(P/ 1 exemplo, 1º me fala a versão do seu netBeans.)

Bem, aparentemente vc não teve ainda 1 insight de p/ q q servem e como funcionam o ".LocalEntityManagerFactoryBean" o ".LocalContainerEntityManagerFactoryBean".
Se vc obteve suas Classes de Domain Model (Entidades de Negócio) via Engenharia Reversa usando a tool do netBeans, a partir de seu Banco de Dados, e, pelo q vc falou, usando o GlassFish, provavelmente (e se o seu Projeto Java é Web) ela gerou 1 Peristence Unit refenciando 1 DataSource definido no Container (Se vc estivesse usando o TomCat, vc teria q definir este DataSource "na unha" lá no Context.xml; mas isto já "era outros 500" :o)

(Uma dica: sempre q vc criar/definir 1 DataSource declare seguindo o seguinte padrão: nomebasededadosDS )

Muito bem, se o seu DataSource estiver funcionando bem, vc pode criar um EM com a conexão "configurada"/definida na Peristence Unit do 'persistence.xml', usando o LocalEntityManagerFactoryBean +- assim:

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean" >  
        <property name="jpaVendorAdapter">
            
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="showSql" value="true"/>
                <property name="generateDdl" value="false"/>
                <property name="databasePlatform" value="org.hibernate.dialect.MySQL5Dialect" />
            </bean>
        </property >
        <property name="jpaProperties">
            <props>
              
                <prop key="hibernate.c3p0.initialPoolSize">10</prop>  
                <prop key="hibernate.c3p0.min_size">5</prop>
                <prop key="hibernate.c3p0.max_size">15</prop>
                <prop key="hibernate.c3p0.timeout">300</prop>  
                <prop key="hibernate.c3p0.max_statements">50</prop>
                <prop key="hibernate.c3p0.idle_test_period">3000</prop>  
            </props>
        </property>
     </bean>

Obs.: o 'LocalContainerEntityManagerFactoryBean' é outra opção q só deve ser usado caso vc deseja fazer o LookUp do DataSource via JNDI -> isto configurado diretamente no applicationContext do Spring.
(Se tiver + alguma dúvida, é só avisar!

))

[Editado]P.S.: ah, caso queira configurar a transação via JTA e ver boas ideias em: http://springtips.blogspot.com/2008/06/spring-entitymanagerfactory-in-jta-and.html(Spring entityManagerFactory in jta and non-jta modes).

Se vc quer implementar via JPA, pq q vc não acessa direto via o DataSource definido no 'persistence.xml'??!

Ah ninja, deixa eu adivinhar, vc não está usando netBeans, né?!!

E a 310-085, ainda não saiu (quando vai sair)??!

Kalimdor wrote:...public List getCarimbosPorOrgaoProcesso(String idOrgaoProcesso, Integer codigoGenero){ ... ...

@Kalimdor,
Na verdade, vc está perdendo o melhor da Criteria (tendo em vista q não existe outra Abordagem + OO q Criteria).
Vc poderia passar os próprios Objetos|Classes como Parâmetro, assim:e daí adicionar as Critérias necessárias e só partir p/ abraço!!!

(muito provavelmente vc não vai nem precisar desses Alias's (conforme for o Mapeamento)! :O)

...

garcia-jj wrote:Derlon, há dois bons artigos que podem acrescentar na discução sobre lazy-load, dtos e afins.
http://community.jboss.org/wiki/HibernateinaLayeredArchitecture
http://community.jboss.org/wiki/RemoteLazyLoading

A conclusão q tiramos disso é q o DTO (e uma grande parte dos outros Padrões do catálogo J2EE Core-Patterns) só foi "inventada" para melhoria de performance (para "suprir uma deficiência da" "API do EJB").

Muito espírito crítico para saber avaliar cada um dos patterns. Muitos são inúteis em alguns casos, mas úteis noutro. O pior que conheci um projeto em EJB 2.1 que usava TODOS os patterns. E sabe que ficou bem elegante? No caso desse projeto era mesmo necessário usar aquilo tudo, mas hoje em dia com EJB3 eu não faria assim.

@carlos maia,

Muito importante isto: em Java a String por padrão (da JVM) é 1 Objeto Imutável.
Então, os testes q v6 fizeram "podem" estar furados..
Explico: se a sua Classe tiver qualquer Atributo, q é 1 Objeto de outra Classe, (q não seja Imutável), na verdade, no Objeto de origem, pode estar contendo a mesma referencia do AtributoObjeto, no Objeto de destino, entende??!
Uma solução realmente efetiva seria fazer a combinação de 2 técnicas|padrões: o Defensive copying com o Copy constructors
Desta forma o State das suas Classes Entidades de Negócio estará mais seguro, mesmo elas transitando no Front-End!!

Espero ter contribuido...

raf4,

Vc não vai acreditar: agora 1 simples #{telaRetorno} funcionou.
Acho q o lance era q eu tava confiando d+ no HotDeploy do JBoss.
(Stop, c/ FullDeploy e Start fizeram as mudanças finalmente terem efeito.

)

Mas, vlws mesmo... muito obrigado p/ contribuição

Tá Resolvido!!

Pessoal do Web, e aê blz??!!

Será q poderiam me ajudar: Tô com 1 probleminha em JSF. O seguinte: Estou numa página (com 1 grid), mas q precisar fazer uma pesquisa em outra página (1 tipo de pesquisar "extendido"). Nesta Tela preciso selecionar um Pedido, selecionar o seu Id e então retornar para Tela original (chamadora). Na 'SessionBean1' tem um atributo chamado 'retorno'; o problema é q o init() de todo PageBean chama o método 'limpaSessao()' q limpa todos os atributos da SessonBean1. Na Tela de Pesquisar Pedido vou colocar um Botão 'Selecionar' q só poderá ser renderizado somente se a Página chamadora for a tal Tela de Origem.
Então na Tela de Origem estou tentanto passar o atributo destar forma Existe alguma forma de recuperar este atributo "telaRetorno" na Tela de Pesquisar Pedido via EL-Expression Language??!
Ou sugerem outra abordagem??! Gente, já quebrei a cabeça.. me ajudem, por favor,

Derlon

PaduaAlves wrote:Pessoal, nem sei se posso tirar essa dúvida aqui pq ela é relativa apenas a banco de dados. De qualquer modo, lá vai: gostaria de saber se tem com ocriar um usuário no postgres com permisão apenas de select e que possa comentar as tabelas do banco. Tentei dar a permissão de comment através do comando GRANT mas não deu certo. Se alguém souber uma forma eu agradeço.

Oi PaduaAlves,
Por incrivel q pareça, comentário em Tabelas e Campos (ou Colunas, como alguns preferem) realmente é (alteração de) Estrutura. Então, esse tal Documentador fatalmente teria q ter privilégio (não só de consultar, mas) de Alterar Estrutura.
Mas, o q não impede de o Documentador simplesmente pedir para o AD (ou diretamente p/ o DBA) via solicitação formalizada, sakou?!!

Notícias, artigos e o maior fórum brasileiro sobre Java