Gurkan, I was not talking about special products, I also meant the API and I mentioned RichFaces-3.3.2 only as an example. You can google for the incompatibility problems.
Matter of fact: .) EE6 WebProfile defines JSF-2, so from this point I'm with you But: .) there is no full stack for JSF-2 on the market currently (the component libraries are missing, since they are mostly incompatible) Plus, there will be lot old projects which still use JSF-1.2 but may like to use OWB for new extensions. and as such: .) providing an easy migration path to EE6 by allowing to use JSF-1.2 + OWB would imho be a pretty nice goodie. I don't think it will confuse users if they have a choice between a JSF-1.2 and a JSF-2 plugin if we explain the differences in the documentation. I think we will start hacking on the feature and if we hit the point of no return we should create an own module. wdyt? LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Do, 17.12.2009: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: Integration of JSF2 specific API calls > An: [email protected] > Datum: Donnerstag, 17. Dezember 2009, 10:03 > Hey Mark, > > >>E.g. try running RichFaces-3.3.2 on a JSF-2 > container ;) > Java EE standards do not depend on any special product! > Standards talk about > API. > > >>In JSF-1.2 there was no standardised ajax handling, > so we would have no > chance to use those features in a portable fashion. > JSR-299 is contained in Java EE 6. Java EE 6 defines JSF2 > and when we talk > about JSF functionality, it means JSF2 not JSF1.2 or > earlier. > We wrote a little JSF code for conversations and at that > time there was no > offical MyFaces JSF2 API to use. Now there is one and we > will update our pom > to use MyFaces JSF2 and we will go ahead with it. In fact, > our codes in > webbeans-jsf must work within JSF2. Moreover, JSF2 is > compatible with JSF1.2 > as written in Java EE 6 specification. > > So all functionality must go into package webbeans-jsf. > There is no need to > create extra project modules that confuses developers > minds. > > Thnks; > > --Gurkan > > 2009/12/17 Mark Struberg <[email protected]> > > > > JSF2 is backward compatible > > > > Not when it comes to the details! > > E.g. try running RichFaces-3.3.2 on a JSF-2 container > ;) > > > > There have been a few changes which allows us to > create better support for > > JSF2, mostly in the AJAX area. In JSF-1.2 there was no > standardised ajax > > handling, so we would have no chance to use those > features in a portable > > fashion. > > > > LieGrue, > > strub > > > > --- Gurkan Erdogdu <[email protected]> > schrieb am Do, 17.12.2009: > > > > > Von: Gurkan Erdogdu <[email protected]> > > > Betreff: Re: Integration of JSF2 specific API > calls > > > An: [email protected] > > > Datum: Donnerstag, 17. Dezember 2009, 9:50 > > > >>>Id favour a > > > webbeans-jsf2, I think that's more future proof. > > > I think that there is no need to define extra > jsf > > > module/project. There is > > > no such a thing that "You could use it in JSF > 1.2 but > > > not JSF2 or vice > > > versa". We support JSF2 and JSF2 is backward > compatible. > > > But, if we really > > > emphasize that the code is related with "JSF2", > we can > > > create a package with > > > named "jsf2" in webbeans-jsf project. > > > > > > Thanks; > > > > > > --Gurkan > > > > > > 2009/12/17 Mark Struberg <[email protected]> > > > > > > > cool! > > > > > > > > Id favour a webbeans-jsf2, I think that's > more future > > > proof. > > > > > > > > And as Gurkan already said: please attach > the patch as > > > owb-171-patch.rfc in > > > > Jira. > > > > > > > > txs and LieGrue, > > > > strub > > > > > > > > --- Sven Linstaedt <[email protected]> > > > schrieb am Do, > > > > 17.12.2009: > > > > > > > > > Von: Sven Linstaedt <[email protected]> > > > > > Betreff: Integration of JSF2 specific > API calls > > > > > An: [email protected] > > > > > Datum: Donnerstag, 17. Dezember 2009, > 2:24 > > > > > Back in business. > > > > > > > > > > I am currently working on a patch for > OWB-171. > > > Besides some > > > > > cleanups I have refactored the code: > > > > > > > > > > Conversation is request scoped and > solely created > > > or > > > > > restored by ConversationBean which > delegates the > > > later one > > > > > to the ConversationManager. > WebBeansPhaseListener > > > is only > > > > > responsible for retrieving and handling > the > > > > > ConversationContext. Conversation is > only > > > restored using the > > > > > "cid" request parameter and not the > > > > > UIViewRoot's attributes, because the > view is > > > only > > > > > accessible after restore view phase. > The > > > restored > > > > > conversation (and it's context of > course) must > > > actually > > > > > exist for restoring the view. This > chicken or egg > > > problem > > > > > was the reason not to store the the cid > in the > > > view's > > > > > attributes, because restoring these > attributes > > > actually > > > > > needs restoring the conversation > beforehand. > > > > > > > > > > > > > > > There is still an issue with the > jsf2-example: In > > > case of > > > > > ajax requests which start a long > running > > > conversation, all > > > > > form's action attributes needs to be > updated to > > > reflect > > > > > the current active conversation for > following > > > request. This > > > > > could be done using JSF2 specific API > features. > > > At the > > > > > moment webbeans-impl is purely compiled > against > > > the JSF 1.2 > > > > > API. Without the necessary abstraction > there is > > > no chance to > > > > > get the JSF2 specific ajax > functionality working > > > again. > > > > > > > > > > > > > > > I have attached the patch to this mail > and not to > > > the > > > > > issue, because the patch is not meant > for > > > inclusion yet, but > > > > > for testing purposes. Integration it > and > > > rerunning the > > > > > jsf2-example points out my problem. If > you > > > disable ajax by > > > > > disabling javascript in your browser > e.g. the > > > conversation > > > > > example is working, because in this > case the full > > > page with > > > > > updated form's action urls is rendered > during > > > each > > > > > action invocation. > > > > > > > > > > > > > > > Last but not least: Do you guys have a > glue how > > > JSF2 > > > > > specific extension for conversation > handling > > > should be > > > > > integrated? I supose either adding > another > > > project > > > > > (webbeans-jsf2 e.g.) or updating the > JSF API (not > > > impl) > > > > > version to 2.x and making sure, we are > loading > > > JSF2 specific > > > > > classes only for this ajax purpose. > > > > > > > > > > > > > > > good night, Sven > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Sie sind Spam leid? Yahoo! Mail verfügt > über einen > > > herausragenden Schutz > > > > gegen Massenmails. > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > -- > > > Gurkan Erdogdu > > > http://gurkanerdogdu.blogspot.com > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sie sind Spam leid? Yahoo! Mail verfügt über einen > herausragenden Schutz > > gegen Massenmails. > > http://mail.yahoo.com > > > > > > -- > Gurkan Erdogdu > http://gurkanerdogdu.blogspot.com > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
