Newsgroup: it.comp.java
Titolo: seam VS java

Nell'aggiornarmi sto tentando di fare un pò di selezione per evitare 
imparare technologie destinate alla morte (cosa molto comune in 
informatica) anche perchè le risorse mentali e di tempo non sono infinite.
Ho dato una occhiata a Seam ed a Spring. Da una occhiata superficiale mi 
sembra che Spring crei + problemi di quelli che risolve...
Chi di voi ha esperienza sui framework?
Opinioni?
Secondo voi quale sarà adottato.
Saluti
Olindo

 ha scritto nel messaggio 
news:9_fGj.32756$q53....@tornado.fastwebnet.it...

Entrambi nel futuro ed entrambi nel presente.
Comunque faccio notare che Seam e Spring non sono in diretta concorrenza, in 
quanto semmai Spring concorre con EJB e non  con Seam che non e' altro che 
un framework di integrazione tra EJB e JSF (ma non solo) per le applicazioni 
web.
Comque sono curioso: quali sono i problemi che crea? 

 Olindo
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 varie.
Non lo sapevo, questa potrebbe essere una buonissima notizia per me.. 


Il 2 e' una meraviglia
maven
webservices embedden negli ejb
richfaces TOTALI
ti incollo il migration da 1.2 a 2 magari ci trovi qualcosa di interessante
Seam 2.0 Migration Guide
========================
Before you get started with Seam2, you'll need to make a few changes to
your existing code and configuration. This process should not be too
painful - if you get stuck, just refer back to the updated Seam examples.
Supported container environments
--------------------------------
Seam 2.0 has been tested on the following containers:
* JBoss 4.2 (it is possible to run Seam2 on JBoss 4.0.5 by upgrading JSF)
* Tomcat 6.0 (Tomcat 5.5 is not compatible with JSF 1.2)
* GlassFish V2
* OC4J 11g Technology Preview
Migration to JSF 1.2
--------------------
Seam 2.0 requires JSF 1.2. We now recommend Sun's JSF RI as the most
mature JSF implementation, and this is the version that ships with most
EE 5 application servers, including JBoss 4.2. To switch to the JSF RI,
you'll need to make some changes to web.xml:
* remove the MyFaces StartupServletContextListener
* remove the Ajax4JSF filter and mappings
* rename org.jboss.seam.web.SeamFilter to
             org.jboss.seam.servlet.SeamFilter
Also note that for the JSF RI, client-side state saving is not required.
You'll also need to make some changes to faces-config.xml:
* Remove the (Tranactional)SeamPhaseListener declaration
* Remove the SeamELResolver declaration, if you have one
* Change the declaration of SeamFaceletViewHandler to the standard
             com.sun.facelets.FaceletViewHandler
Since Seam 1.2, you didn't need any declarations of SeamExceptionFilter
or SeamRedirectFilter in web.xml, just a single declaration of SeamFilter.
Make sure you've already made that change.
Code migration
--------------
Seam's built-in components have undergone a major reorganization designed
to organize them for easier learning, and to isolate dependencies upon
particular technologies like JSF into specific packages.
* Persistence-related components moved to org.jboss.seam.persistence
* jBPM related components moved to org.jboss.seam.bpm
* JSF-related components moved org.jboss.seam.faces
* Servlet-related components have moved to org.jboss.seam.web
* Components related to asynchronicity moved to org.jboss.seam.async
* i18n-related components moved to org.jboss.seam.international
* The Pageflow component moved to org.jboss.seam.pageflow
* The Pages component moved to org.jboss.seam.navigation
Code which depends on these APIs will need to be changed to reflect the
new Java package names.
Annotations have also been reorganized:
* BPM-related annotations moved to org.jboss.seam.annotations.bpm
* JSF-related annotations moved to org.jboss.seam.annotations.faces
* Interceptor annotations moved to
          org.jboss.seam.annotations.intercept
* Annotations related to asynchronicity moved to
          org.jboss.seam.annotations.async
* @RequestParameter moved to org.jboss.seam.annotations.web
* @WebRemote moved to org.jboss.seam.annotations.remoting
* @Restrict moved to org.jboss.seam.annotations.security
* Exception handling annotations moved to
          org.jboss.seam.annotations.exception
* Use @BypassInterceptors instead of @Intercept(NEVER)
Migration of components.xml
---------------------------
The new packaging comes with new namespaces and new schemas for
components.xml. The namespace for components in package
    org.jboss.seam.foobar
 
Is now:
 
http://jboss.com/products/seam/foobar
 
And the schema is:
 
http://jboss.com/products/seam/foobar-2.0.xsd
You'll need to update your components.xml file to reflect the new schemas
and namespaces. Take a look at the Seam examples if you're unsure of
exactly what you need to do.
Finally, some declarations must be removed completely:
* remove <conversation-is-long-running-parameter> from <core:init/>
* remove <core:ejb/>
* remove <core:microcontainer/>
* replace <core:transaction-listener/> with
          <transaction:ejb-transaction/>
* replace <core:resource-bundle/> with <core:resource-loader/>
 
Note: Seam transaction management is now enabled by default. If you want
      to disable use of Seam-managed transactions, use the following:
 
      <core:init transaction-management-enabled="false"/>
 
Note: The expression attribute on event action's has been deprecated in
favor of
      execute e.g.:
      <event type="org.jboss.seam.notLoggedIn">
          <action execute="#{redirect.captureCurrentView}"/>
      </event>
Migration to JBoss Embedded
---------------------------
Support for deployment to JBoss Embeddable EJB3 and JBoss Microcontainer
has been removed. Instead, the new JBoss Embedded distribution gives you
a full set of EE-compatible APIs with simplified deployment.
For testing, you need the jars in Seam's lib/ directory, together with the
bootstrap/ directory in your classpath. SeamTest will automatically start
the container. Refer to the Seam examples, or seam-gen, if you have
trouble.
For Tomcat deployment, follow the instructions in the user guide. You no
longer need any special configuration or packaging for Tomcat deployments.
Note that JBoss Embedded is able to bootstrap a datasource from a -ds.xml
file, so there is no longer a need for jboss-beans.xml.
Migration to JBPM 3.2
---------------------
If you are using JBPM for business processes (not just pageflows), you need
to add the tx service to jbpm.cfg.xml:
  <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
 
Migration to RichFaces 3.1
--------------------------
If you are using RichFaces or Ajax4jsf, a major reorganisation of the
codebase
has occurred. ajax4jsf.jar and richfaces.jar have been replaced by
richfaces-api.jar (which should go in your ear lib/ directory) and
richfaces-impl.jar and richfaces-ui.jar (both of which go in WEB-INF/lib).
s:selectDate has been deprecated in favor of rich:calendar. No more
development will be done on s:selectDate.
You should check the RichFaces documentation for more information on
parameter
name changes and namespace changes.
Packaging changes
-----------------
You should place all the dependencies which you previously declared as
modules
in application.xml in the lib/ directory of your ear *except* jboss-seam.jar
which should be declared as an ejb module in application.xml
Changes to Seam UI
------------------
* s:decorate has become a naming container. Therefore client ids have
changed
  from fooForm:fooInput to fooForm:foo:fooInput (assuming your s:decorate has
  foo as an id.
Changes to seam-gen
-------------------
There was a change in seam-gen starting with Seam 2.0.0.CR2 regarding
how the generated classes are organized when generate-entities is
executed.
Old way:
  src/model/com/domain/projectname/model/EntityName.java
  src/action/com/domain/projectname/model/EntityNameHome.java
  src/action/com/domain/projectname/model/EntityNameList.java
New way:
  src/model/com/domain/projectname/model/EntityName.java
  src/action/com/domain/projectname/action/EntityNameHome.java
  src/action/com/domain/projectname/action/EntityNameList.java
Home and Query objects are "action" components, not "model" components
and are therefore placed in the action package. This change makes the
convensions followed by generate-entities consistent with the convensions
used in the new-entity command.
Remember, model classes are kept separate because they cannot be hot
reloaded.


 Comque sono curioso: quali sono i problemi che crea?
Premettendo che non usato Spring per progetti reali mi sembra che 
l'utilizzo esetnsivo di configurazione XML sia aqbbastanza farragginoso..

 l'utilizzo esetnsivo di configurazione XML sia aqbbastanza farragginoso..
No, e' minimale ormai. Questo grazie alla filosofia convenzioni meglio di 
configurazioni.
Ad esempio Spring cerca di gestire le dipendenze dei tuoi bean seguendo i 
match dei nomi tra bean e proprieta'.
Oppure match dei tipi. Oppure anche se no questo non ti va bene.
A questo bisogna aggiungere che in Spring 2.5 puoi utilizzare quasi solo 
annotazioni per gestire i tuoi bean! Dacci un occhio.

 integrazioni varie.
Ma bisogna usare script ant/maven anche in ambiente eclipse?

 richfaces TOTALI
JSF è un'altra tecnologia che ho preferito far "sedimentare".
Ci lavorate?
Che ve ne pare?
Ciao


Si
N


 Ciao
 Ciao Nicola


 e recupero il pesciolino con una facilita' enorme
Questo in effetti non ha paragone neppure in Spring 2.5 :)