[seam-dev] what about a seam2 - CDI Bridge ?

Shane Bryzak sbryzak at redhat.com
Mon Nov 28 07:56:25 EST 2011


That's an awesome list of migration issues, thanks Tomaz.  I'm currently 
working on a Seam 2 -> Java EE migration guide and you've nailed a good 
deal of the issues on the head, which I'll try to address as I go.

On 28/11/11 20:28, Tomaž Cerar wrote:
> 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 at lists.jboss.org [mailto:seam-dev-bounces at lists.jboss.org] On Behalf Of Jozef Hartinger
> Sent: Friday, November 25, 2011 5:06 PM
> To: Antoine Sabot-Durand
> Cc: seam-dev at 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:
>> Reading the SeamNext thread and all these remarks about Seam 2 to Seam
>> 3 migration I was wondering how difficult would it be to create a Seam
>> 2 CDI extension to provide the same kind of bridge we have with Spring ?
>>
>> This bridge would be one way : using Seam 2 bean in CDI (the other way
>> is not relevant). It would help people to go thru the migration
>> process don't you think ?
>>
>> The biggest difficulty would probably be the Seam 2 navigation and
>> providing some kind of extension to merge JSF2 and Seam 2 navigation
>> seems a bit tricky.
>>
>>
>>
>> Antoine SABOT-DURAND
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
> !DSPAM:6,4ecfbd12173961628642973!
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev



More information about the seam-dev mailing list