Re: [jsr-314-open] [Fwd: CDI and JSF Phase Listeners]
by Alexander Smirnov
On 01/10/2010 06:39 AM, Pete Muir wrote:
>
> On 8 Jan 2010, at 17:38, Dan Allen wrote:
>
>> On Fri, Jan 8, 2010 at 11:30 AM, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
>> It would be a nice feature to be able to have CDI injection in Phase
>> Listeners also, as any Servlet/JSF/CDI integration is always welcome
>> where applicable
>>
>>
>> This is actually a more general requirement (which we may have discussing in passing). Any user-defined class instance that JSF creates should be classified as a components in Java EE. But, to accommodate that without tying JSF directly to the platform (a separation we have always maintained), there should be a pluggable class instance resolver which could be satisfied with a CDI implementation, a Spring bean implementation, etc.
>
> I had initially thought we should just specify that JSF is required to support this injection, but I can see that specifying an SPI to support instantiation/lifecycle management of these objects would fit well with the pluggability goal that JSF has.
>
> Is this too big for a mainatainance release?
Nice Idea. Implementation would delegate all requests for class
instances to single object that really already Util class that loads
classes defined in the configuration. One step forward is using similar
objectto create class instances and make that object plugable. CDI can
substitute such loader to create instances of any Faces objects, even to
inject something into FacesContext.
>
> Is this something we can prototype in MyFaces or Mojarra sooner?
15 years, 6 months
Re: [jsr-314-open] [Fwd: CDI and JSF Phase Listeners]
by Dan Allen
On Sun, Jan 10, 2010 at 9:39 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
> On 8 Jan 2010, at 17:38, Dan Allen wrote:
>
> > On Fri, Jan 8, 2010 at 11:30 AM, Roger Kitain <Roger.Kitain(a)sun.com>
> wrote:
> > It would be a nice feature to be able to have CDI injection in Phase
> > Listeners also, as any Servlet/JSF/CDI integration is always welcome
> > where applicable
> >
> >
> > This is actually a more general requirement (which we may have discussed
> in passing). Any user-defined class instance that JSF creates should be
> classified as a component in Java EE. But, to accommodate that without tying
> JSF directly to the platform (a separation we have always maintained), there
> should be a pluggable class instance resolver which could be satisfied with
> a CDI implementation, a Spring bean implementation, etc.
>
> I had initially thought we should just specify that JSF is required to
> support this injection, but I can see that specifying an SPI to support
> instantiation/lifecycle management of these objects would fit well with the
> pluggability goal that JSF has.
>
+1 To provide further justification, I think this is really going to help
users take advantage of the new extension points in JSF 2 without leaving
them to figure out how to tie those classes back into their programming
model. Otherwise, we my hear a lot of complaints.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
15 years, 6 months
Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
>>>>> On Mon, 04 Jan 2010 11:21:50 -0800, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> On 1/3/10 12:45 PM, Lincoln Baxter, III wrote:
>> I'd like to revisit this for JSF2.1 -
>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=499
>>
>> Project stage is something that needs to be configurable without
>> modifying the underlying WAR (and while JNDI support is provided, it
>> requires container configuration, admittedly not a huge downside.)
>> However, for those who do not primarily use JNDI for configuration, a
>> -D system property makes a lot of sense.
JD> That sounds like something that could be handy - please file an RFE.
>> I'd also like to propose one other enhancement, which is runtime
>> configuration of the PROJECT_STAGE through an exposed API. This is
>> something that I think should be able to turn on and off while the
>> server is running (For the same reason it must be possible to enable
>> or disable debug logging or auditing at runtime.)
JD> That has performance implications - for instance, we do some setup of
JD> the application based on project stage that would be awkward to change
JD> on the fly. Offhand, I'm not in favor of this change, since that
JD> complicates the runtime behavior for what must be a rather small corner
JD> case. If you have a compelling use case, you might change my mind, but
JD> keep in mind that implementing this is not as simple as it may appear at
JD> first blush.
I also am not in favor of this change. We make a lot of assumptions
about the immutability of the ProjectStage value at runtime.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 6 months
[jsr-314-open] [717-ComponentMetadata] (was: DRY and form with JSF 2)
by Ed Burns
>> <Norbert.Truchsess(a)t-online.de> wrote:
NT> it would be way less overhead, if there would be a reference back from
NT> the inputText to the outputLabel that is actually stored with the
NT> inputText and not just logically defined by the 'for' attribute of
NT> label. If a reference to the outputLabel would be stored in a collection
NT> with the inputText by setting the 'for'-attribute on outputLabel it
NT> could be just taken from there and wouln't require runtime-walk of the
NT> component-tree to be retrieved.
On Tue, Sep 15, 2009 at 3:24 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
DA> +1. Exactly what I was thinking.
DA>
DA> It appears we have two correlated issues here. I've found a need for the
DA> backreference in the past. It can be linked at build time. Of course,
DA> programmatic access would need to be aware of it if the tree is modified in
DA> a way that breaks the reference. That should be mentioned in the issue
DA> report, not necessarily solved here.
>>>>> On Fri, 09 Oct 2009 02:46:31 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> FWIW, MyFaces originally implemented a solution for this, but then
MM> dropped it from the IMPL and moved it to Tomahawk, to remain
MM> compatible.
It seems to me that this is a request for a general purpose component
metadata solution. Right now we have this in the spec:
3.6.2.1 Composite Component Metadata
In the current version of the specification, only composite
UIComponents must have component metadata. It is possible that future
versions of the specification will broaden this requiremnt so that all
UIComponents must have metadata.
I've opened issue 717 for this, and added this specific usecase. I'll
continue to scan for this topic in my traversal of old messages, but
just in case I miss something, please add additional requirements to the
issue.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 6 months
[jsr-314-open] [716-VDLResponseWriter] Pluggable VDL handler heavy depends from ViewHandler implementation.
by Ed Burns
I've created
<https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=716>,
target for 2.1 (not 2.0 Rev a)
>>>>> On Tue, 05 Jan 2010 16:56:10 -0800, Alexander Smirnov <asmirnov(a)exadel.com> said:
AS> ViewDeclarationLanguage implementation close depended from
AS> ViewHandler implementation.
[...]
AS> modifications. Possible solutions are:
AS> 1) Introduce ViewDeclarationLanguage#writeState method that should
AS> be called from ViewHandler#writeState in the same way as renderView
AS> method does.
AS> 2) Change default ViewHandler#renderView method requirements that it
AS> should create appropriate ResponseWriter before calling
AS> ViewDeclarationLanguage#renderView method, so ViewHandler can
AS> perform late state writing in consistent way.
AS> I prefer to the #2 solution because that allows to reduce duplicated
AS> code in the ViewDeclarationLanguage implementations, but there is a
AS> problem: VDL may provide additional options for response like buffer
AS> sixe, encoding and content type that required to create
AS> ResponseWriter. Possible solution is to make public
AS> ViewDeclarationLanguage#createResponseWriter(FacesContext context)
AS> method that already exists in the Mojarra implementation.
As you know, ultimate responsibility for creating the ResponseWriter
lies with the RenderKit. Is it fair to describe your requirement like
this:
we need a standard way for the VDL to decorate the ResponseWriter at the
beginning of the rendering phase?
If so, the VDL could listen for the PreRenderView event and perform the
decoration there. Would that work?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 6 months
[jsr-314-open] Test from Neil
by Neil Griffin
Hi Guys,
I've been having troubles posting to jsr-314-open
If one of y'all gets this email, could you please reply?
Thanks,
Neil
15 years, 6 months
