[jsr-314-open] rendered attribute for ui:component, ui:fragment?
by Cay Horstmann
According to the JSF 2.0 spec, ui:component and ui:fragment do not have
a "rendered" attribute. Yet Mojarra supports it, and so does the
original facelets implementation. In fact, the only usecase that I have
seen for ui:fragment is to conditionally render one.
Is this a spec error? If so, I'll be glad to file an issue.
Thanks,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
15 years, 1 month
Re: [jsr-314-open] FacesServlet declaration in Java EE 6
by Andy Schwartz
This all sounds good to me. +1 to adding this (with both mappings).
Andy
Pete Muir wrote:
> Hi Matthias,
>
> Yeah, I was being lazy in the email, I meant to ask for feedback on
> whether it should be a suffix mapping, a prefix mapping or both :-)
>
> I'm no expert on this, but I see no harm in the both option.
>
> On 5 Nov 2009, at 06:50, Matthias Wessendorf wrote:
>
>> Hello friends and /dev/null ...
>>
>> I'd like to see a sentence like that, however I prefer that /faces/*
>> is present as well.
>> So it should be IMO an "and" ...
>>
>> -Matthias
>>
>> Martin Marinschek wrote:
>>> +1 as well!
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 11/5/09, Dan Allen <dan.j.allen(a)gmail.com> wrote:
>>>
>>>>> "If the JSF container is used in a Servlet 3 (or newer)
>>>>> environment, it
>>>>> should register an implementation of ServletContainerInitializer
>>>>> (using
>>>>> Service Providers from the JAR file specification). The
>>>>> ServletContainerInitializer should register the FacesServlet, with
>>>>> a name
>>>>> of
>>>>> Faces Servlet, if an existing servlet is not yet registered with this
>>>>> name.
>>>>> Furthermore, a suffix mapping of *.jsf [and/or a prefix mapping of
>>>>> /faces/*]
>>>>> should be added."
>>>>>
>>>>>
>>>> Well said. +1 from me.
>>>>
>>>> -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, 1 month
[jsr-314-open] Fwd: FacesServlet declaration in Java EE 6
by Martin Marinschek
Relaying Matthias - he wants an AND. For reasons of resource-handling,
we will need the prefix-mapping anyways.
regards,
Martin
---------- Forwarded message ----------
From: Matthias Wessendorf <matthias.wessendorf(a)oracle.com>
Date: Thu, 05 Nov 2009 07:50:09 +0100
Subject: Re: [jsr-314-open] FacesServlet declaration in Java EE 6
To: jsr-314-open(a)jcp.org, dan.j.allen(a)gmail.com,
mmarinschek(a)apache.org, pmuir(a)redhat.com, andy.schwartz(a)oracle.com
Hello friends and /dev/null ...
I'd like to see a sentence like that, however I prefer that /faces/* is
present as well.
So it should be IMO an "and" ...
-Matthias
Martin Marinschek wrote:
> +1 as well!
>
> regards,
>
> Martin
>
> On 11/5/09, Dan Allen <dan.j.allen(a)gmail.com> wrote:
>
>>> "If the JSF container is used in a Servlet 3 (or newer) environment, it
>>> should register an implementation of ServletContainerInitializer (using
>>> Service Providers from the JAR file specification). The
>>> ServletContainerInitializer should register the FacesServlet, with a name
>>> of
>>> Faces Servlet, if an existing servlet is not yet registered with this
>>> name.
>>> Furthermore, a suffix mapping of *.jsf [and/or a prefix mapping of
>>> /faces/*]
>>> should be added."
>>>
>>>
>> Well said. +1 from me.
>>
>> -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
>>
>>
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years, 1 month
Re: [jsr-314-open] [OT] faces-config.xml names
by Andy Schwartz
Gang -
Just wanted to send out one more ping on this before we pick our names
for Trinidad/ADF Faces.
It seems clear that the current restrictions on faces-config.xml names
was not intentional. Is there any hope of getting some solution in
place quickly, eg. could we:
- Doc this as a spec errata for the next MR
- Tweak Mojarra/MyFaces to allow NMTOKENs for names
This seems like it should be fairly trivial to do, but I have no idea
whether there are some process barriers that would prevent us from doing
this.
Ed/Roger -
Any thoughts on whether this might be possible? (If not, I'll
understand, but would be good to know either way.)
Andy
Andy Schwartz wrote:
> Thanks Dan.
>
> BTW, regarding:
>
>> The desired semantics are to match the XML NMTOKEN type:
>
> Looking back at our original email thread, there was discussion of
> using the XML ID type (which also allows '.'). It seems fairly clear
> that the choice of javaee:java-identifierType did not match our intent.
>
> Ed, Roger -
>
> Can we find some way to address this, at the spec and/or
> implementation level? Ideally we want to do this before too many more
> frameworks publish their faces-config names.
>
> Andy
>
> Dan Allen wrote:
>> \p in the regexp basically the dot matcher (.) for specific unicode
>> classifications. So the regex says roughly:
>>
>> starts with a letter, _ or $
>> can have any number of letters, _ or $
>>
>> Letter is a loose term that encompasses strange symbols you will
>> likely never type (at least not if you are writing in English, but we
>> are friendly to other character sets as well where the dot character
>> would not match).
>>
>> Still, no literal dot (.) allowed.
>>
>> -Dan
>>
>> p.s. Not sure why we select the $ to be allowed. Or is that the end
>> of line matcher? If so, I still don't get what it is trying to say.
>>
>> On Tue, Oct 20, 2009 at 2:48 PM, Andy Schwartz
>> <andy.schwartz(a)oracle.com <mailto:andy.schwartz@oracle.com>> wrote:
>>
>> Gang -
>>
>> The spec defines the name element as:
>>
>> <xsd:element name="name"
>> type="javaee:java-identifierType"
>> minOccurs="0"
>> maxOccurs="1">
>>
>>
>> javaee:java-identifierType is:
>>
>> <xsd:complexType name="java-identifierType">
>> <xsd:annotation>
>> <xsd:documentation>
>>
>> The java-identifierType defines a Java identifier.
>> The users of this type should further verify that
>> the content does not contain Java reserved keywords.
>>
>> </xsd:documentation>
>> </xsd:annotation>
>> <xsd:simpleContent>
>> <xsd:restriction base="j2ee:string">
>> <xsd:pattern value="($|_|\p{L})(\p{L}|\p{Nd}|_|$)*"/>
>> </xsd:restriction>
>> </xsd:simpleContent>
>> </xsd:complexType>
>>
>>
>>
>> My regular expression parsing skills are not what they should be,
>> but I believe that this is unintentionally overly strict. The
>> desired semantics are to match the XML NMTOKEN type:
>>
>> http://www.w3.org/TR/2000/WD-xml-2e-20000814.html#NT-Nmtoken
>>
>> Which allows '.' (and other characters too, like '-', ':').
>>
>> This is going to require a loosening of the spec - in particular,
>> in the XSD for faces-config.xml. Can we find some way to address
>> this? Perhaps as a spec errata that allows implementations to
>> accept qualified ids?
>>
>> Andy
>>
>> lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com> wrote:
>>
>> Agreed. I don't know if that's something we can fix? Should be
>> fixed IMO. Though I don't understand the reasons it wasn't
>> included at all, so I can't really theorize.
>>
>> Sent from my Verizon Wireless BlackBerry
>>
>>
>> ------------------------------------------------------------------------
>> *From: * Dan Allen <dan.j.allen(a)gmail.com
>> <mailto:dan.j.allen@gmail.com>>
>> *Date: *Tue, 20 Oct 2009 14:20:53 -0400
>> *To: *<lincolnbaxter(a)gmail.com
>> <mailto:lincolnbaxter@gmail.com>>; <jsr-314-open(a)jcp.org
>> <mailto:jsr-314-open@jcp.org>>
>> *Subject: *Re: [jsr-314-open] [OT] faces-config.xml names
>>
>>
>>
>> On Tue, Oct 20, 2009 at 2:16 PM, <lincolnbaxter(a)gmail.com
>> <mailto:lincolnbaxter@gmail.com>
>> <mailto:lincolnbaxter@gmail.com
>> <mailto:lincolnbaxter@gmail.com>>> wrote:
>>
>> Andy,
>>
>> Prettyfaces uses ocpsoft_pretty_faces (dot is not an allowed
>> character and will cause deploy failure)
>>
>>
>> Too bad. I would have voted for the Java namespace style. I
>> like org.apache.myfaces.trinidad and org.ocpsoft.prettyfaces
>>
>> Either way, I would use a name that maps closely to the root
>> package of the component library.
>>
>> -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
>>
>>
>>
>>
>>
>> --
>> 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, 1 month
[jsr-314-open] New spec issue 659 - MethodExpressionActionListener.processAction() logs and wraps exceptions in AbortProcessingExceptions
by Martin Marinschek
Hi guys,
See the issue comment for the new spec issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=659
below. Please let's please fix this rather soon - I have an ugly hack
in place to work around this.
======
One case we missed when we decided to fix exception-handling for 2.0:
In MethodExpressionActionListener.processAction(), we first do custom logging of
an exception, and then rethrow it with:
throw cause == null ? new AbortProcessingException(thrown.getMessage(),
thrown) : new AbortProcessingException(thrown.getMessage(),
cause);
which leads to a silently (for the user - not for the logs if they are switched
on and available) swallowed exception in the action-listener. I believe the
whole exception-handling in this method can be made a lot simpler - we need to
check if the user threw an AbortProcessingException (might also be the cause of
the ELException) and rethrow that, if not, do nothing - just let the exception
bubble up to the exception-handler.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years, 1 month
