Hello All,
It is nice to get from under a security issue at work that has had me away
from just about everything for a month.
This is quite a discussion around CDI injection of the FacesContext. I see
the merits of using CDI and for one of my projects we were using CDI with
Mojarra. Everything was working well until we had to use WebSphere. The IBM
implementation of CDI + JSF was OpenWebBeans and MyFaces. We could use
Mojarra, but without CDI. If we wanted to use CDI we would have to use
MyFaces. We had written a number of components taking advantage of Mojarra.
We didn't want to have to have multiple implementations of our components
for Mojarra and MyFaces. In the end, we ended up striping out CDI and went
with pure JSF to avoid issues with CDI.
So here are my concerns with moving to CDI:
1. How do we deal with different CDI implementations? Is there going to be
a requirement that the CDI implementations must work with Mojarra, as well
as, MyFaces?
2. How do we deal with existing applications that are very large (2.5+
mLOC) using existing JSF implementations which do not rely on CDI currently.
I am comfortable with the approaches I am looking at, but I am concerned
about the lack of interest in backwards compatibility, and compatibility
between implementations of CDI.
I will work on looking at all the emails to date on the list to make sure I
am up to speed, and I apologize in advance if I have missed a discussion
about this already.
I am excited about a more uniform bean management approach across EE using
CDI. I think this is the right direction. I just don't want unbridled
enthusiasm to throw caution to the wind.
John
____________________________
John Yeary
____________________________
*NetBeans Dream Team*
*President Greenville Java Users GroupJava Users Groups Community
LeaderJava Enterprise Community Leader*
____________________________
<
http://javaevangelist.blogspot.com/> <
https://twitter.com/jyeary>
<
http://www.youtube.com/johnyeary> <
http://www.linkedin.com/in/jyeary>
<
https://plus.google.com/112146428878473069965>
<
http://www.facebook.com/jyeary>
<
http://feeds.feedburner.com/JavaEvangelistJohnYearysBlog>
<
http://netbeans.org/people/84414-jyeary>
"Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy much nor suffer much, because they live in the gray twilight
that knows not victory nor defeat."
-- Theodore Roosevelt
On Tue, Oct 7, 2014 at 11:34 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Tue, Oct 7, 2014 at 5:19 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
> >> I wouldn't be surprised if there is code out there that assumes the
> >> instance returned by FacesContext.getCurrentInstance() is *NOT* a
> >> proxy. If so, that code will likely break. Do we care about that?
> >> Personally, yes, I do care about that. Does anyone else think this is a
> >> risk?
> >
> > And that assumption won't change. The FacesContext.getCurrentInstance()
> call
> > still returns the same thing. The #{facesContext} expression returns the
> > proxy.
>
> Indeed, code that currently uses FacesContext.getCurrentInstance();
> will see no differences whatsoever, as it will return the same old
> regular instance that has always been returned.
>
> For those situations where a FacesContext is passed along that was
> originally obtained by resolving #{facesContext} or by injection via
> "@Inject FacesContext context;" there will thus be a proxy, but I
> wonder if code is really capable of seeing any real difference.
>
> Kind regards,
> Arjan Tijms
>