Antoine, I believe this was discussed a while back and the biggest problem in doing such a solution was the package naming clash between Seam 2 and 3 that would prevent them both being in the same deployment. There were probably other issues too Ken Sent from my iPhone On Nov 25, 2011, at 8:26, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 it wasn't, but this exactly same idea appeared in a discussion with my colleagues ;-). On 11/25/2011 03:14 PM, John D. Ament wrote: - -- Marek Novotny - -- Seam Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno Email: mnovotny(a)redhat.com Office phone: +420 532 294 287, ext. 82-62 087 mobile: +420 608 509 230

Just programming model is not enough as it covers maybe 10% of the problems with seam2--> cdi+seam3 migration. Also, there are scenarios that code that is automatically converted won't work. The biggest problems are: - @Out has no alternative in CDI (and rightly so) - @Factory as @Produces does not behave the same (producer from non-defendant scope cannot return null) - Component.getInstance("myComponent") can be mimicked in cdi but it is not the same I have tried to migrate a medium size project from seam2 to cdi+ seam3 modules and the behavior of producers forced me to change the code quite a bit not just replace annotations. If we put this aside, what I have found out when porting project was lots of features of seam2 that have no replacements in cdi+seam3 or parts where replacement means changing lots of code. Currently there is no replacement or replacement is hard: - seam application framework - for witch I think there could be an easy port if we retain same functionality/concept - s:* tags - and taglibs in general(a4j:,rich:), there are no replacements for lots of components or behavior is totally different, changing all that is the biggest problem in project I am porting even with including monstrum like richfaces - seam mail - all the templates have to be changed - new concept is great but backward compatibly is non-existent - seam remoting - for gwt remoting now there is errai witch is great but migrating from seam gwt servlet to errai is whole project for itelf... - seam pdf/xls - there is (good) alternative but it means rewrite all the templates - rewriting support - what we have now is let's say ok(still missing few features of pages.xml), but external project, additional dependencies and non-seamless integration is quite a pain to maintain And other small things that is got used to :-) Really the biggest problem with migration is all that taglibs missing with no replacements, refactoring code is one thing and it can be quite well tested but refactor xhtml templates is a different beast that requires lots of changes to code and in some cases also UX and UI changes... Before trying to go this path I tried to migrate project step by step in the way that seam2 could co-exists with cdi on AS7, for that I have created a fork of seam2 on my github that runs native on AS7 or say batter it runs as JEE6 (JPA2,JSF2,...) it still has some issues but I stopped fixing that as the biggest problem was that it does play well with seam-persistence module as there is package clash... and I cannot use persistence in both seam components and in cdi ones. There are lots of ideas how to attack problems of migrating from seam2 to seam3 but as it seems there are lots of features missing and there is nothing to migrate to... We talked about migration with Pete and Lincoln on JUDCON in Boston where idea for migration of code was a plugin to forge that would refactor the code for you and not go with cdi extension that would that for you at runtime... Creating the bridge that would enable you getting cdi components in seam ones is quite easy if you know what you are doing but I don't know how useful it is in the long run, we have one project that is a hybrid like that and it gives us lots of development/maintenance issues... Cheers, tomaz -----Original Message----- From: seam-dev-bounces(a)lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Jozef Hartinger Sent: Friday, November 25, 2011 5:06 PM To: Antoine Sabot-Durand Cc: seam-dev(a)lists.jboss.org Subject: Re: [seam-dev] what about a seam2 - CDI Bridge ? I've been working on something similar. It is a CDI extension that allows a Seam 2 application to run in an EE6 container without Seam 2. It focuses solely on the core programming model. Some of the Seam 2 -> CDI conversions are done at the deployment time while the rest is handled by a compatibility layer at runtime. On 11/25/2011 02:26 PM, Antoine Sabot-Durand wrote: _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev !DSPAM:6,4ecfbd12173961628642973!

Adrian: http://seamframework.org/Seam3/ReportsModule https://github.com/seam/reports cheers, tomaz From: seam-dev-bounces(a)lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Adrian Gonzalez Sent: Monday, November 28, 2011 11:41 AM To: Tomaž Cerar; Jozef Hartinger; Antoine Sabot-Durand Cc: seam-dev(a)lists.jboss.org Subject: [seam-dev] Re : what about a seam2 - CDI Bridge ? Hi Tomaz, I'm no Seam developper (just a user) and I didn't begin any migration yet ;( I'm interested about what alternative did you use for seam pdf/xls (seam pdf/xls - there is (good) alternative but it means rewrite all the templates) Thanks very much for the feedback ! ________________________________ De : Tomaž Cerar <cerar(a)parsek.com&gt; À : Jozef Hartinger <jharting(a)redhat.com>; Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Cc : seam-dev(a)lists.jboss.org Envoyé le : Lundi 28 Novembre 2011 11h28 Objet : Re: [seam-dev] what about a seam2 - CDI Bridge ? Just programming model is not enough as it covers maybe 10% of the problems with seam2--> cdi+seam3 migration. Also, there are scenarios that code that is automatically converted won't work. The biggest problems are: - @Out has no alternative in CDI (and rightly so) - @Factory as @Produces does not behave the same (producer from non-defendant scope cannot return null) - Component.getInstance("myComponent") can be mimicked in cdi but it is not the same I have tried to migrate a medium size project from seam2 to cdi+ seam3 modules and the behavior of producers forced me to change the code quite a bit not just replace annotations. If we put this aside, what I have found out when porting project was lots of features of seam2 that have no replacements in cdi+seam3 or parts where replacement means changing lots of code. Currently there is no replacement or replacement is hard: - seam application framework - for witch I think there could be an easy port if we retain same functionality/concept - s:* tags - and taglibs in general(a4j:,rich:), there are no replacements for lots of components or behavior is totally different, changing all that is the biggest problem in project I am porting even with including monstrum like richfaces - seam mail - all the templates have to be changed - new concept is great but backward compatibly is non-existent - seam remoting - for gwt remoting now there is errai witch is great but migrating from seam gwt servlet to errai is whole project for itelf... - seam pdf/xls - there is (good) alternative but it means rewrite all the templates - rewriting support - what we have now is let's say ok(still missing few features of pages.xml), but external project, additional dependencies and non-seamless integration is quite a pain to maintain And other small things that is got used to :-) Really the biggest problem with migration is all that taglibs missing with no replacements, refactoring code is one thing and it can be quite well tested but refactor xhtml templates is a different beast that requires lots of changes to code and in some cases also UX and UI changes... Before trying to go this path I tried to migrate project step by step in the way that seam2 could co-exists with cdi on AS7, for that I have created a fork of seam2 on my github that runs native on AS7 or say batter it runs as JEE6 (JPA2,JSF2,...) it still has some issues but I stopped fixing that as the biggest problem was that it does play well with seam-persistence module as there is package clash... and I cannot use persistence in both seam components and in cdi ones. There are lots of ideas how to attack problems of migrating from seam2 to seam3 but as it seems there are lots of features missing and there is nothing to migrate to... We talked about migration with Pete and Lincoln on JUDCON in Boston where idea for migration of code was a plugin to forge that would refactor the code for you and not go with cdi extension that would that for you at runtime... Creating the bridge that would enable you getting cdi components in seam ones is quite easy if you know what you are doing but I don't know how useful it is in the long run, we have one project that is a hybrid like that and it gives us lots of development/maintenance issues... Cheers, tomaz -----Original Message----- From: seam-dev-bounces(a)lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Jozef Hartinger Sent: Friday, November 25, 2011 5:06 PM To: Antoine Sabot-Durand Cc: seam-dev(a)lists.jboss.org Subject: Re: [seam-dev] what about a seam2 - CDI Bridge ? I've been working on something similar. It is a CDI extension that allows a Seam 2 application to run in an EE6 container without Seam 2. It focuses solely on the core programming model. Some of the Seam 2 -> CDI conversions are done at the deployment time while the rest is handled by a compatibility layer at runtime. On 11/25/2011 02:26 PM, Antoine Sabot-Durand wrote: _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev !DSPAM:6,4ed3654989881804284693!