You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Balunas, Jay" <ba...@netscout.com> on 2006/01/13 20:01:09 UTC
JSF 1.2 support/plans
Hello all,
I have been lurking for some time, and have been investigating JSF for a new project at my company. Please forgive me is this has come up already - I did search through several pages of archives and could not find a reference to 1.2 support roadmaps
Because this will be a new project starting in about a month, and first release around end of summer (August -September) I have been investigating both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF provides. We are planning on using Ajax and from what research I have done JSF 1.2 has some hooks for making Ajax requests less of a hack into the life cycle.
We are also investigating Suns implementation, but I would prefer to stick with myFaces as the support and community seems stronger.
Thanks in advance,
Jay
Re: JSF 1.2 support/plans
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, of course.
We've done so already ;)
regards,
Martin
On 1/14/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 1/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes,
> >
> > we all know the improvements JSF 1.2 has to offer, and all committers
> > want to have a JSF 1.2 compliant version out as soon as possible.
> >
> > If you can help us make it possible to rely on Sun's CDDL licensed
> > code, we'll have a chance to actually work on it.
>
> Glad to hear it! But, please understand that at Apache I have just one
> voice among many. If the MyFaces community considers this to be an
> important issue, then you need to ask your PMC to raise the urgency of
> dealing with this with the Apache Board, and (in particular) the VP of Legal
> Affairs, Cliff Schmidt (to avoid spam attacks, I'll leave it to you to
> figure out what his Apache email address is :-). Many voices have more
> influence than one voice.
>
>
> > regards,
> >
> > Martin
>
> Craig
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF 1.2 support/plans
Posted by Bernd Bohmann <be...@atanion.com>.
> Why would Sun need to relicense the JSF 1.2 RI? It's already under an
> open source license (CDDL).
>
> It's up to Apache to decide whether or not to accept a dependency on
> CDDL-licensed code, as it does for (say) BSD licensed code.
>
> Craig
>
Allows the CDDL a distribution over a maven repository?
Regards
Bernd
Re: JSF 1.2 support/plans
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan schrieb:
> Why would Sun need to relicense the JSF 1.2 RI? It's already under an
> open source license (CDDL).
>
I agree, it is not Suns responsibility, nevertheless it would be a nice
move.
But the Apache board really has to come to a conclusion in this matter.
The current situation of having a yes no limbo is not really that good
for anyone.
> It's up to Apache to decide whether or not to accept a dependency on
> CDDL-licensed code, as it does for (say) BSD licensed code.
>
Well, BSD is a different issue as CDDL as far as I know the licenses ;-)
CDDL sort of is a Mozilla like license while Apache is a derivation of BSD.
CDDL is less liberal than both Apache2 and BSD to my knowledge but only
slightly.
Re: JSF 1.2 support/plans
Posted by Craig McClanahan <cr...@apache.org>.
On 1/16/06, Werner Punz <we...@gmx.at> wrote:
>
> Craig McClanahan schrieb:
>
> > Glad to hear it! But, please understand that at Apache I have just one
> > voice among many. If the MyFaces community considers this to be an
> > important issue, then you need to ask your PMC to raise the urgency of
> > dealing with this with the Apache Board, and (in particular) the VP of
> > Legal Affairs, Cliff Schmidt (to avoid spam attacks, I'll leave it to
> > you to figure out what his Apache email address is :-). Many voices
> > have more influence than one voice.
> >
> Wouldnt it be easier to relicense parts of the RI under a different
> license, or is that forbidden within Sun?
Why would Sun need to relicense the JSF 1.2 RI? It's already under an open
source license (CDDL).
It's up to Apache to decide whether or not to accept a dependency on
CDDL-licensed code, as it does for (say) BSD licensed code.
Craig
Re: JSF 1.2 support/plans
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan schrieb:
> Glad to hear it! But, please understand that at Apache I have just one
> voice among many. If the MyFaces community considers this to be an
> important issue, then you need to ask your PMC to raise the urgency of
> dealing with this with the Apache Board, and (in particular) the VP of
> Legal Affairs, Cliff Schmidt (to avoid spam attacks, I'll leave it to
> you to figure out what his Apache email address is :-). Many voices
> have more influence than one voice.
>
Wouldnt it be easier to relicense parts of the RI under a different
license, or is that forbidden within Sun?
Re: JSF 1.2 support/plans
Posted by Craig McClanahan <cr...@apache.org>.
On 1/14/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Yes,
>
> we all know the improvements JSF 1.2 has to offer, and all committers
> want to have a JSF 1.2 compliant version out as soon as possible.
>
> If you can help us make it possible to rely on Sun's CDDL licensed
> code, we'll have a chance to actually work on it.
Glad to hear it! But, please understand that at Apache I have just one
voice among many. If the MyFaces community considers this to be an
important issue, then you need to ask your PMC to raise the urgency of
dealing with this with the Apache Board, and (in particular) the VP of Legal
Affairs, Cliff Schmidt (to avoid spam attacks, I'll leave it to you to
figure out what his Apache email address is :-). Many voices have more
influence than one voice.
regards,
>
> Martin
Craig
Re: JSF 1.2 support/plans
Posted by Martin Marinschek <ma...@gmail.com>.
Ah - I was last searching for this in December, and then Jacob hadn't
fulfilled his plan to donate the el.
Cool thing!
regards,
Martin
On 1/14/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> There is an Apache licensed EL, here at apache tomcat (at least that is the plan) :
>
> http://www.mail-archive.com/dev%40tomcat.apache.org/msg02077.html
>
> So it may be easier to talk to the tomcat people on their plans..
>
> Mvgr,
> Martin
>
> Martin Marinschek wrote:
> > Yes,
> >
> > we all know the improvements JSF 1.2 has to offer, and all committers
> > want to have a JSF 1.2 compliant version out as soon as possible.
> >
> > If you can help us make it possible to rely on Sun's CDDL licensed
> > code, we'll have a chance to actually work on it.
> >
> > regards,
> >
> > Martin
> >
> > On 1/14/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >>On 1/13/06, Simon Kitching <sk...@apache.org> wrote:
> >>
> >>
> >>>On Fri, 2006-01-13 at 14:01 -0500, Balunas, Jay wrote:
> >>>
> >>>>Hello all,
> >>>>
> >>>>I have been lurking for some time, and have been investigating JSF for a
> >>
> >>new project at my company. Please forgive me is this has come up already -
> >>I did search through several pages of archives and could not find a
> >>reference to 1.2 support roadmaps
> >>
> >>>>Because this will be a new project starting in about a month, and first
> >>
> >>release around end of summer (August -September) I have been investigating
> >>both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF
> >>provides. We are planning on using Ajax and from what research I have done
> >>JSF 1.2 has some hooks for making Ajax requests less of a hack into the life
> >>cycle.
> >>
> >>>>We are also investigating Suns implementation, but I would prefer to
> >>
> >>stick with myFaces as the support and community seems stronger.
> >>
> >>>Note that all the following is not "official"; I'm a myfaces committer,
> >>>but not part of the project management committee. This info is just my
> >>>view from what I observe happening...
> >>>
> >>>Firstly, the JSF 1.2 spec is not yet released; it's at "proposed final
> >>>draft", and has been for many months.
> >>
> >>Indeed, no one can actually "release" a "General Availability"
> >>implementation of a JCP spec that is not final yet. But that doesn't stop
> >>you from working on such an implementation, on the assumption that it will
> >>eventually go final (since JSF 1.2 is part of JavaEE 5, I think that's a
> >>pretty good bet :-).
> >>
> >>
> >>>I doubt very much if MyFaces will manage to release a 1.2-compatible
> >>>version in the next six months. Sun have made JSF 1.2 dependent on a new
> >>>version of the EL "expression language" library, and on a new version of
> >>>JSP. Until those exist MyFaces can't even begin to implement much of JSF
> >>>1.2.
> >>>
> >>>And I'm not aware of any progress on implementing the next JSP version
> >>>by Apache Tomcat or other such projects. As far as I am aware, Sun is
> >>>the only one with an implementation of this near completion. That would,
> >>>in fact, prevent the official release of the spec for many
> >>>organisations; it's common to require at least 2 successful
> >>>implementations of a spec before it is considered ready for release. I'm
> >>>not sure that Sun works by those rules though.
> >>>
> >>>MyFaces is intending to add some JSF1.2 type features into the current
> >>>1.1-compatible release. Encrypted client-side sessions are already done
> >>>for example.
> >>>
> >>>In addition, there is still a lot of work to be done to stabilise the
> >>>current 1.1-compatible release. I personally would like to see effort
> >>>put into this before moving on to the next spec version.
> >>
> >>One option for the MyFaces community to consider, with regards to JSF 1.2,
> >>is to utilize some portions of the JSF 1.2 reference implementation, which
> >>(unlike the JSF 1.1 RI) is under the CDDL license. The implementation of
> >>the new EL APIs seems like an obvious candidate for this. In turn, though,
> >>this would require pushing on Apache to accept dependencies on CDDL-licensed
> >>code -- from my conversation with insiders, there seems to be no conceptual
> >>problem with CDDL's terms; it's caught up in a larger strategic initiative
> >>on dealing with non-Apache-licensed software. If the MyFaces community
> >>wants to, this would be an obvious case where it would benefit the world.
> >>I'd happily go advocate that scenario, if the MyFaces community felt that
> >>this was the right direction to go.
> >>
> >>It isn't by any means required that such a dependency last forever -- if it
> >>makes sense to create your own implementation, that's perfectly fine.
> >>Consider using the RI code a short term strategy to get a release out the
> >>door more quickly than would otherwise be possible. If the code works, and
> >>does everything you need, then no harm in relying on it. If it doesn't,
> >>replace it -- that's what open source is about.
> >>
> >>But I need to reiterate a comment above, because it is not obvious to me
> >>that the MyFaces development community has figured out all the implications
> >>yet:
> >>
> >>* JSF 1.2 will be (when it is released -- trust me, that is not a long time
> >>away :-) a *required*
> >> API to be supported by any Java EE 5 server.
> >>
> >>* That means, any app server vendor who is planning on implementing Java EE
> >>5 is going
> >> to need to make a JSF technology choice sooner, rather than later.
> >>
> >> * At the moment, there is only one viable JSF 1.2 implementation that I am
> >>aware of.
> >> In the absence of any other choice, this will become the default
> >>selection.
> >>
> >>* Specific use cases -- if/when Geronimo and JBoss decide to implement Java
> >>EE 5,
> >> they are going to require a JSF 1.2 implementation.
> >>
> >>* Is the MyFaces community interested in being an option for app server
> >>vendors? If so,
> >> it's time to move quickly. Once a particular app server chooses a
> >>particular implementation
> >> of a particular dependency, it's generally pretty difficult to affect that
> >>choice later.
> >>
> >>* If MyFaces is satisfied being a JSF 1.1 implementation, for non-JavaEE5
> >>environments,
> >> then none of the above matters. ((In my personal opinion, that would be a
> >>poor choice,
> >> but it is not my choice to make.))
> >>
> >>If I were a MyFaces committer (and I'd certainly enjoy being one, but my
> >>personal interest is more in the components than in the JSF implementation),
> >>I would seriously think about the strategic issues around the
> >>when-and-if-supporting-JSF-1.2 question. I would also view a decision to
> >>defer paying attention to JSF 1.2 with sadness ... as someone interested in
> >>dealing with many of the issues that JSF 1.0/1.1 + JSP brings to the table,
> >>I would sure like there to be more people (rather than less) that take
> >>advantage of the JSF 1.2 improvements in this area -- and they are
> >>*substantial*. To say nothing of everything else that is improved in 1.2
> >>...
> >>
> >>
> >>>Regards,
> >>>
> >>>Simon
> >>>
> >>>
> >>
> >>Craig
> >>
> >>
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF 1.2 support/plans
Posted by Martin van den Bemt <ml...@mvdb.net>.
There is an Apache licensed EL, here at apache tomcat (at least that is the plan) :
http://www.mail-archive.com/dev%40tomcat.apache.org/msg02077.html
So it may be easier to talk to the tomcat people on their plans..
Mvgr,
Martin
Martin Marinschek wrote:
> Yes,
>
> we all know the improvements JSF 1.2 has to offer, and all committers
> want to have a JSF 1.2 compliant version out as soon as possible.
>
> If you can help us make it possible to rely on Sun's CDDL licensed
> code, we'll have a chance to actually work on it.
>
> regards,
>
> Martin
>
> On 1/14/06, Craig McClanahan <cr...@apache.org> wrote:
>
>>On 1/13/06, Simon Kitching <sk...@apache.org> wrote:
>>
>>
>>>On Fri, 2006-01-13 at 14:01 -0500, Balunas, Jay wrote:
>>>
>>>>Hello all,
>>>>
>>>>I have been lurking for some time, and have been investigating JSF for a
>>
>>new project at my company. Please forgive me is this has come up already -
>>I did search through several pages of archives and could not find a
>>reference to 1.2 support roadmaps
>>
>>>>Because this will be a new project starting in about a month, and first
>>
>>release around end of summer (August -September) I have been investigating
>>both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF
>>provides. We are planning on using Ajax and from what research I have done
>>JSF 1.2 has some hooks for making Ajax requests less of a hack into the life
>>cycle.
>>
>>>>We are also investigating Suns implementation, but I would prefer to
>>
>>stick with myFaces as the support and community seems stronger.
>>
>>>Note that all the following is not "official"; I'm a myfaces committer,
>>>but not part of the project management committee. This info is just my
>>>view from what I observe happening...
>>>
>>>Firstly, the JSF 1.2 spec is not yet released; it's at "proposed final
>>>draft", and has been for many months.
>>
>>Indeed, no one can actually "release" a "General Availability"
>>implementation of a JCP spec that is not final yet. But that doesn't stop
>>you from working on such an implementation, on the assumption that it will
>>eventually go final (since JSF 1.2 is part of JavaEE 5, I think that's a
>>pretty good bet :-).
>>
>>
>>>I doubt very much if MyFaces will manage to release a 1.2-compatible
>>>version in the next six months. Sun have made JSF 1.2 dependent on a new
>>>version of the EL "expression language" library, and on a new version of
>>>JSP. Until those exist MyFaces can't even begin to implement much of JSF
>>>1.2.
>>>
>>>And I'm not aware of any progress on implementing the next JSP version
>>>by Apache Tomcat or other such projects. As far as I am aware, Sun is
>>>the only one with an implementation of this near completion. That would,
>>>in fact, prevent the official release of the spec for many
>>>organisations; it's common to require at least 2 successful
>>>implementations of a spec before it is considered ready for release. I'm
>>>not sure that Sun works by those rules though.
>>>
>>>MyFaces is intending to add some JSF1.2 type features into the current
>>>1.1-compatible release. Encrypted client-side sessions are already done
>>>for example.
>>>
>>>In addition, there is still a lot of work to be done to stabilise the
>>>current 1.1-compatible release. I personally would like to see effort
>>>put into this before moving on to the next spec version.
>>
>>One option for the MyFaces community to consider, with regards to JSF 1.2,
>>is to utilize some portions of the JSF 1.2 reference implementation, which
>>(unlike the JSF 1.1 RI) is under the CDDL license. The implementation of
>>the new EL APIs seems like an obvious candidate for this. In turn, though,
>>this would require pushing on Apache to accept dependencies on CDDL-licensed
>>code -- from my conversation with insiders, there seems to be no conceptual
>>problem with CDDL's terms; it's caught up in a larger strategic initiative
>>on dealing with non-Apache-licensed software. If the MyFaces community
>>wants to, this would be an obvious case where it would benefit the world.
>>I'd happily go advocate that scenario, if the MyFaces community felt that
>>this was the right direction to go.
>>
>>It isn't by any means required that such a dependency last forever -- if it
>>makes sense to create your own implementation, that's perfectly fine.
>>Consider using the RI code a short term strategy to get a release out the
>>door more quickly than would otherwise be possible. If the code works, and
>>does everything you need, then no harm in relying on it. If it doesn't,
>>replace it -- that's what open source is about.
>>
>>But I need to reiterate a comment above, because it is not obvious to me
>>that the MyFaces development community has figured out all the implications
>>yet:
>>
>>* JSF 1.2 will be (when it is released -- trust me, that is not a long time
>>away :-) a *required*
>> API to be supported by any Java EE 5 server.
>>
>>* That means, any app server vendor who is planning on implementing Java EE
>>5 is going
>> to need to make a JSF technology choice sooner, rather than later.
>>
>> * At the moment, there is only one viable JSF 1.2 implementation that I am
>>aware of.
>> In the absence of any other choice, this will become the default
>>selection.
>>
>>* Specific use cases -- if/when Geronimo and JBoss decide to implement Java
>>EE 5,
>> they are going to require a JSF 1.2 implementation.
>>
>>* Is the MyFaces community interested in being an option for app server
>>vendors? If so,
>> it's time to move quickly. Once a particular app server chooses a
>>particular implementation
>> of a particular dependency, it's generally pretty difficult to affect that
>>choice later.
>>
>>* If MyFaces is satisfied being a JSF 1.1 implementation, for non-JavaEE5
>>environments,
>> then none of the above matters. ((In my personal opinion, that would be a
>>poor choice,
>> but it is not my choice to make.))
>>
>>If I were a MyFaces committer (and I'd certainly enjoy being one, but my
>>personal interest is more in the components than in the JSF implementation),
>>I would seriously think about the strategic issues around the
>>when-and-if-supporting-JSF-1.2 question. I would also view a decision to
>>defer paying attention to JSF 1.2 with sadness ... as someone interested in
>>dealing with many of the issues that JSF 1.0/1.1 + JSP brings to the table,
>>I would sure like there to be more people (rather than less) that take
>>advantage of the JSF 1.2 improvements in this area -- and they are
>>*substantial*. To say nothing of everything else that is improved in 1.2
>>...
>>
>>
>>>Regards,
>>>
>>>Simon
>>>
>>>
>>
>>Craig
>>
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: JSF 1.2 support/plans
Posted by Martin Marinschek <ma...@gmail.com>.
Yes,
we all know the improvements JSF 1.2 has to offer, and all committers
want to have a JSF 1.2 compliant version out as soon as possible.
If you can help us make it possible to rely on Sun's CDDL licensed
code, we'll have a chance to actually work on it.
regards,
Martin
On 1/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 1/13/06, Simon Kitching <sk...@apache.org> wrote:
>
> > On Fri, 2006-01-13 at 14:01 -0500, Balunas, Jay wrote:
> > > Hello all,
> > >
> > > I have been lurking for some time, and have been investigating JSF for a
> new project at my company. Please forgive me is this has come up already -
> I did search through several pages of archives and could not find a
> reference to 1.2 support roadmaps
> > >
> > > Because this will be a new project starting in about a month, and first
> release around end of summer (August -September) I have been investigating
> both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF
> provides. We are planning on using Ajax and from what research I have done
> JSF 1.2 has some hooks for making Ajax requests less of a hack into the life
> cycle.
> > >
> > > We are also investigating Suns implementation, but I would prefer to
> stick with myFaces as the support and community seems stronger.
> >
> > Note that all the following is not "official"; I'm a myfaces committer,
> > but not part of the project management committee. This info is just my
> > view from what I observe happening...
> >
> > Firstly, the JSF 1.2 spec is not yet released; it's at "proposed final
> > draft", and has been for many months.
>
> Indeed, no one can actually "release" a "General Availability"
> implementation of a JCP spec that is not final yet. But that doesn't stop
> you from working on such an implementation, on the assumption that it will
> eventually go final (since JSF 1.2 is part of JavaEE 5, I think that's a
> pretty good bet :-).
>
> > I doubt very much if MyFaces will manage to release a 1.2-compatible
> > version in the next six months. Sun have made JSF 1.2 dependent on a new
> > version of the EL "expression language" library, and on a new version of
> > JSP. Until those exist MyFaces can't even begin to implement much of JSF
> > 1.2.
> >
> > And I'm not aware of any progress on implementing the next JSP version
> > by Apache Tomcat or other such projects. As far as I am aware, Sun is
> > the only one with an implementation of this near completion. That would,
> > in fact, prevent the official release of the spec for many
> > organisations; it's common to require at least 2 successful
> > implementations of a spec before it is considered ready for release. I'm
> > not sure that Sun works by those rules though.
> >
> > MyFaces is intending to add some JSF1.2 type features into the current
> > 1.1-compatible release. Encrypted client-side sessions are already done
> > for example.
> >
> > In addition, there is still a lot of work to be done to stabilise the
> > current 1.1-compatible release. I personally would like to see effort
> > put into this before moving on to the next spec version.
>
> One option for the MyFaces community to consider, with regards to JSF 1.2,
> is to utilize some portions of the JSF 1.2 reference implementation, which
> (unlike the JSF 1.1 RI) is under the CDDL license. The implementation of
> the new EL APIs seems like an obvious candidate for this. In turn, though,
> this would require pushing on Apache to accept dependencies on CDDL-licensed
> code -- from my conversation with insiders, there seems to be no conceptual
> problem with CDDL's terms; it's caught up in a larger strategic initiative
> on dealing with non-Apache-licensed software. If the MyFaces community
> wants to, this would be an obvious case where it would benefit the world.
> I'd happily go advocate that scenario, if the MyFaces community felt that
> this was the right direction to go.
>
> It isn't by any means required that such a dependency last forever -- if it
> makes sense to create your own implementation, that's perfectly fine.
> Consider using the RI code a short term strategy to get a release out the
> door more quickly than would otherwise be possible. If the code works, and
> does everything you need, then no harm in relying on it. If it doesn't,
> replace it -- that's what open source is about.
>
> But I need to reiterate a comment above, because it is not obvious to me
> that the MyFaces development community has figured out all the implications
> yet:
>
> * JSF 1.2 will be (when it is released -- trust me, that is not a long time
> away :-) a *required*
> API to be supported by any Java EE 5 server.
>
> * That means, any app server vendor who is planning on implementing Java EE
> 5 is going
> to need to make a JSF technology choice sooner, rather than later.
>
> * At the moment, there is only one viable JSF 1.2 implementation that I am
> aware of.
> In the absence of any other choice, this will become the default
> selection.
>
> * Specific use cases -- if/when Geronimo and JBoss decide to implement Java
> EE 5,
> they are going to require a JSF 1.2 implementation.
>
> * Is the MyFaces community interested in being an option for app server
> vendors? If so,
> it's time to move quickly. Once a particular app server chooses a
> particular implementation
> of a particular dependency, it's generally pretty difficult to affect that
> choice later.
>
> * If MyFaces is satisfied being a JSF 1.1 implementation, for non-JavaEE5
> environments,
> then none of the above matters. ((In my personal opinion, that would be a
> poor choice,
> but it is not my choice to make.))
>
> If I were a MyFaces committer (and I'd certainly enjoy being one, but my
> personal interest is more in the components than in the JSF implementation),
> I would seriously think about the strategic issues around the
> when-and-if-supporting-JSF-1.2 question. I would also view a decision to
> defer paying attention to JSF 1.2 with sadness ... as someone interested in
> dealing with many of the issues that JSF 1.0/1.1 + JSP brings to the table,
> I would sure like there to be more people (rather than less) that take
> advantage of the JSF 1.2 improvements in this area -- and they are
> *substantial*. To say nothing of everything else that is improved in 1.2
> ...
>
> > Regards,
> >
> > Simon
> >
> >
>
> Craig
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF 1.2 support/plans
Posted by Craig McClanahan <cr...@apache.org>.
On 1/13/06, Simon Kitching <sk...@apache.org> wrote:
> On Fri, 2006-01-13 at 14:01 -0500, Balunas, Jay wrote:
> > Hello all,
> >
> > I have been lurking for some time, and have been investigating JSF for a
> new project at my company. Please forgive me is this has come up already -
> I did search through several pages of archives and could not find a
> reference to 1.2 support roadmaps
> >
> > Because this will be a new project starting in about a month, and first
> release around end of summer (August -September) I have been investigating
> both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF
> provides. We are planning on using Ajax and from what research I have done
> JSF 1.2 has some hooks for making Ajax requests less of a hack into the
> life cycle.
> >
> > We are also investigating Suns implementation, but I would prefer to
> stick with myFaces as the support and community seems stronger.
>
> Note that all the following is not "official"; I'm a myfaces committer,
> but not part of the project management committee. This info is just my
> view from what I observe happening...
>
> Firstly, the JSF 1.2 spec is not yet released; it's at "proposed final
> draft", and has been for many months.
Indeed, no one can actually "release" a "General Availability"
implementation of a JCP spec that is not final yet. But that doesn't stop
you from working on such an implementation, on the assumption that it will
eventually go final (since JSF 1.2 is part of JavaEE 5, I think that's a
pretty good bet :-).
I doubt very much if MyFaces will manage to release a 1.2-compatible
> version in the next six months. Sun have made JSF 1.2 dependent on a new
> version of the EL "expression language" library, and on a new version of
> JSP. Until those exist MyFaces can't even begin to implement much of JSF
> 1.2.
>
> And I'm not aware of any progress on implementing the next JSP version
> by Apache Tomcat or other such projects. As far as I am aware, Sun is
> the only one with an implementation of this near completion. That would,
> in fact, prevent the official release of the spec for many
> organisations; it's common to require at least 2 successful
> implementations of a spec before it is considered ready for release. I'm
> not sure that Sun works by those rules though.
>
> MyFaces is intending to add some JSF1.2 type features into the current
> 1.1-compatible release. Encrypted client-side sessions are already done
> for example.
>
> In addition, there is still a lot of work to be done to stabilise the
> current 1.1-compatible release. I personally would like to see effort
> put into this before moving on to the next spec version.
One option for the MyFaces community to consider, with regards to JSF 1.2,
is to utilize some portions of the JSF 1.2 reference implementation, which
(unlike the JSF 1.1 RI) is under the CDDL license. The implementation of
the new EL APIs seems like an obvious candidate for this. In turn, though,
this would require pushing on Apache to accept dependencies on CDDL-licensed
code -- from my conversation with insiders, there seems to be no conceptual
problem with CDDL's terms; it's caught up in a larger strategic initiative
on dealing with non-Apache-licensed software. If the MyFaces community
wants to, this would be an obvious case where it would benefit the world.
I'd happily go advocate that scenario, if the MyFaces community felt that
this was the right direction to go.
It isn't by any means required that such a dependency last forever -- if it
makes sense to create your own implementation, that's perfectly fine.
Consider using the RI code a short term strategy to get a release out the
door more quickly than would otherwise be possible. If the code works, and
does everything you need, then no harm in relying on it. If it doesn't,
replace it -- that's what open source is about.
But I need to reiterate a comment above, because it is not obvious to me
that the MyFaces development community has figured out all the implications
yet:
* JSF 1.2 will be (when it is released -- trust me, that is not a long time
away :-) a *required*
API to be supported by any Java EE 5 server.
* That means, any app server vendor who is planning on implementing Java EE
5 is going
to need to make a JSF technology choice sooner, rather than later.
* At the moment, there is only one viable JSF 1.2 implementation that I am
aware of.
In the absence of any other choice, this will become the default
selection.
* Specific use cases -- if/when Geronimo and JBoss decide to implement Java
EE 5,
they are going to require a JSF 1.2 implementation.
* Is the MyFaces community interested in being an option for app server
vendors? If so,
it's time to move quickly. Once a particular app server chooses a
particular implementation
of a particular dependency, it's generally pretty difficult to affect that
choice later.
* If MyFaces is satisfied being a JSF 1.1 implementation, for non-JavaEE5
environments,
then none of the above matters. ((In my personal opinion, that would be a
poor choice,
but it is not my choice to make.))
If I were a MyFaces committer (and I'd certainly enjoy being one, but my
personal interest is more in the components than in the JSF implementation),
I would seriously think about the strategic issues around the
when-and-if-supporting-JSF-1.2 question. I would also view a decision to
defer paying attention to JSF 1.2 with sadness ... as someone interested in
dealing with many of the issues that JSF 1.0/1.1 + JSP brings to the table,
I would sure like there to be more people (rather than less) that take
advantage of the JSF 1.2 improvements in this area -- and they are
*substantial*. To say nothing of everything else that is improved in 1.2...
Regards,
>
> Simon
>
>
Craig
Re: JSF 1.2 support/plans
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2006-01-13 at 14:01 -0500, Balunas, Jay wrote:
> Hello all,
>
> I have been lurking for some time, and have been investigating JSF for a new project at my company. Please forgive me is this has come up already - I did search through several pages of archives and could not find a reference to 1.2 support roadmaps
>
> Because this will be a new project starting in about a month, and first release around end of summer (August -September) I have been investigating both the current 1.1.1 version of myFaces, and looking into what 1.2 JSF provides. We are planning on using Ajax and from what research I have done JSF 1.2 has some hooks for making Ajax requests less of a hack into the life cycle.
>
> We are also investigating Suns implementation, but I would prefer to stick with myFaces as the support and community seems stronger.
Note that all the following is not "official"; I'm a myfaces committer,
but not part of the project management committee. This info is just my
view from what I observe happening...
Firstly, the JSF 1.2 spec is not yet released; it's at "proposed final
draft", and has been for many months.
I doubt very much if MyFaces will manage to release a 1.2-compatible
version in the next six months. Sun have made JSF 1.2 dependent on a new
version of the EL "expression language" library, and on a new version of
JSP. Until those exist MyFaces can't even begin to implement much of JSF
1.2.
And I'm not aware of any progress on implementing the next JSP version
by Apache Tomcat or other such projects. As far as I am aware, Sun is
the only one with an implementation of this near completion. That would,
in fact, prevent the official release of the spec for many
organisations; it's common to require at least 2 successful
implementations of a spec before it is considered ready for release. I'm
not sure that Sun works by those rules though.
MyFaces is intending to add some JSF1.2 type features into the current
1.1-compatible release. Encrypted client-side sessions are already done
for example.
In addition, there is still a lot of work to be done to stabilise the
current 1.1-compatible release. I personally would like to see effort
put into this before moving on to the next spec version.
Regards,
Simon