[jsr-314-open] Metadata complete jar files
by Andy Schwartz
Gang -
Section 11.5.1 of the spec defines the following annotation scanning
behavior:
> Requirements for scanning of classes for annotations
> * If the <faces-config> element in the WEB-INF/faces-config.xml file
> contains metadata-complete attribute whose value is “true”, the
> implementation must not perform annotation scanning on any classes
> except for those classes provided by the implementation itself.
> Otherwise, continue as follows.
> * If the runtime discovers a conflict between an entry in the
> Application Configuration Resources and an annotation, the entry in
> the Application Configuration Resources takes precedence.
> * All classes in WEB-INF/classes must be scanned.
> * For every jar in the application's WEB-INF/lib directory, if the jar
> contains a “META-INF/faces-config.xml” file or a file that matches the
> regular expression “.*\.faces-config.xml” (even an empty one), all
> classes in that jar must be scanned.
Since application developers have the ability to disable annotation
scanning at a global level, this means that any component set that wants
to support this mode would need to provide a metadata complete
faces-config.xml file. I don't think this is a hardship for most
component vendors, since presumably component vendors are going to want
to provide design-time metadata (eg. JSR-276 metadata), which, for the
moment, requires a faces-config.xml file anyway.
A question that came up here is whether we can tweak section 11.5.1 to
accommodate metadata complete jar files. That is, can we specify that
any jar that contains a faces-config.xml with a metadata-complete="true"
attribute would not be scanned? This would allow component vendors to
indicate that their jar files are metadata complete, and thus avoid the
cost of annotation scanning for the contents of the jar.
Note that while the annotation scan is typically a one time hit (during
application startup), design-time tools may end up starting/stopping JSF
repeatedly during the development process. Thus, avoiding unnecessary
scanning should provide for a more efficient development experience.
Any thoughts on whether we could/should make this change? Does anyone
know of reasons why we avoided specifying this originally?
Also - if we agree to make this change, is this small enough that we
could get this into the the next MR?
Andy
13 years, 8 months
[jsr-314-open-mirror] [jsr-314-open] Should the ViewDeclarationLanguage be responsible to indicate if a viewId can be created?
by Leonardo Uribe
Hi
The current algorithm to check if a view with a specific viewId does not
allow to add or extends a new ViewDeclarationLanguage using a new
prefix/extension.
This issue is related to
https://issues.apache.org/jira/browse/MYFACES-2628 Facelets ResourceSolver
can't work
and
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
The problem resides on a "hidden" requeriment for Restore View Phase
algorithm, that is ignored silently. On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:
public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext
context,
String viewId)
{
String actualViewId = derivePhysicalViewId(context, viewId, false);
return vdlFactory.getViewDeclarationLanguage(actualViewId);
}
Now on myfaces is this:
@Override
public ViewDeclarationLanguage getViewDeclarationLanguage(
FacesContext context, String viewId)
{
// return a suitable ViewDeclarationLanguage implementation for the
given viewId
return _vdlFactory.getViewDeclarationLanguage(viewId);
}
The difference is subtle, but very, very important. This method is called
from many locations, but only once (from RestoreViewPhase) it is passed the
"raw" viewId. To "derive" the physical viewId it is required to know if
prefix or suffix mapping is used and if suffix mapping is used, try to check
if a view "resource" exists or not with different derived ids with the
extensions configured ".xhtml .jsp".
javax.faces.view.facelets.ResourceResolver documentation says this:
"... Provide a hook to decorate or override the way that Facelets loads
template files. A default implementation must be provided that satisfies the
requirements for loading templates as in Pre-JSF 2.0 Facelets ..."
So, in theory it is possible to override ResourceResolver interface and
serve resources from a different location. But the algorithm in
MultiViewHandler.derivePhysicalViewId does not take into account this
interface, so it try to check if the view "resource" exists on the same
location and fails.
The solution proposed is add a method on ViewHandler,
ViewDeclarationLanguageFactory and ViewDeclarationLanguage called:
public boolean existsViewId(String viewId)
So the VDL can indicate if a viewId exists or not. In this way, on Facelets
VDL we can check if a viewId exists using the ResourceResolver instance. It
is curious that ViewDeclarationFactory implementation has some methods that
indicate if a vdl can handle a viewId or not (it is not the same, but
similar). I'm not done too much work on this issue, but it could be good to
take a look at this one. It could be good to open an issue on the spec for
this one too (if no objections I'll open an issue for this one, but better
to ask first).
Suggestions are welcome.
regards,
Leonardo Uribe
13 years, 10 months
[jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL(s)
by Roger Kitain
There are two proposals for enhancing CSRF attacks in JSF. We need to
pick one.
Proposal 1: Form Action URL Approach (Approach provided by Kito Mann)
This approach does the following: - Token is generated on the
server consisting (minimally) of a randomly generated "secret key
(stored in session).
- ViewHandler.getActionURL method must include the token parameter
named "javax.faces.Token", and whose value is the token value.
- At render time this token will be included in Form's action URL -
and it will be
posted back to the server.
- Restore View Phase processing compares the incoming token request
parameter value
with the token value generated from the secret key in the session.
Spec Document Modifications:
Section 7.5.1:
getActionURL:
"The URL must contain the parameter constant defined by
ResponseStateManager.VIEW_TOKEN_PARAM
The value of this parameter must be a cryptographically produced value
minimally consisting
of a "secret key". The "secret key" is a random generated value that was
stored in the session
(preferably around session creation time). Implementations may also
choose to combine other
values with the secret key to produce a more complex token."
Section 2.2.1
"Verify the "javax.faces.Token" request parameter value is the same as
the token value generated
from the "secret key" stored in the session. If the values do not
match, throw a meaningful
exception."
Proposal 2: Form Hidden Field Approach
This approach is similar to Approach 1, except a Form hidden field
"javax.faces.Token"
is used instead of appending to the Form's Action URL.
Spec Document Modifications:
Standard RenderKit Docs
- Form Rendering
"Render a hidden field named "javax.faces.Token" using the
ResponseStateManager.VIEW_TOKEN_PARAM
constant. The value of this hidden field is a cryptographically
produced value that must at least
consist of a "secret key". The "secret key" is a random generated
value that was stored in the
session (preferably around session creation time). Implementations
may also choose to combine
other values with the secret key to produce a more complex token."
Specification Document
Section 2.2.1
"Verify the "javax.faces.Token" request parameter value is the same
as the token value generated
from the "secret key" stored in the session. If the values do not
match, throw a FacesException.
For both approaches see:
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
Look at the two latest change bundles attached to the issue.
Please review by COB Friday as we have no time left for 2.1.
Kudos to Kito Mann for helping out with the implementation.
-roger
14 years, 1 month
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Fri, 27 Aug 2010 16:32:21 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> The OCA was filled. I hope it will be no problem with share this
LU> contribution with myfaces.
I'm about ready to commit the feature to Mojarra head.
I've added the test app and an HtmlUnit driver. Very nice test app.
I just have to slap the standard copyright header on things before
commiting.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 7 work days until handoff of JSF 2.1 change log to jcp
14 years, 1 month
Re: [jsr-314-open-mirror] [jsr-314-open] [Mojarra-1812-FacesServlet.service] PROPOSAL
by Ed Burns
Thanks for your prompt response.
Comments inline.
>>>>> On Wed, 8 Sep 2010 18:05:15 +0200, Matthias Wessendorf <matzew(a)apache.org> said:
MW> I think I don't get why the release() has been (re)moved at all and
MW> why this now need to exposed as lifecyle API.
MW> Doesn't the ticket talk about exception handling/reporting? I think I
MW> don't understand how that is related to release the facesCtx.
The reason it impacts exception handling is the case where an exception
is thrown as a result of action taken by the JSF impl to synchronize
session scoped beans at the end of a JSF request so that clustering
requirements are not violated. This is the catch block that needs to be
invoked when such an exception is thrown:
EB> + } catch (Throwable t) {
EB> + ExceptionQueuedEventContext eventContext =
EB> + new ExceptionQueuedEventContext(context, t);
EB> + context.getApplication().publishEvent(context,
EB> + ExceptionQueuedEvent.class, eventContext);
EB> + context.getExceptionHandler().handle();
EB> + } finally {
Obviously, this needs to happen *before* the FacesContext is released.
This proposal, provides a simple and clean way for the implemention to
know that the jsf portion of the request processing lifecycle has
finished.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 7 work days until JavaOne 2010
14 years, 1 month
[jsr-314-open-mirror] [jsr-314-open] Enhance conversion model is required because UIInput.submittedValue returns Object, but Converter suggest only String is allowed
by Leonardo Uribe
Hi
This issue has been posted on spec issue tracker:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=888
The current conversion model is not good enough on some cases when it
is required the submitted value be something different than String, or on
more complex components that requires to send information from multiple html
"input" components.
This issue has been discussed earlier on myfaces list, as you can
see on the comments at the end of this mail:
To understand what's missing, I'll resume how the current conversion model
works.
This could be redundant, but the intention is expose the reasons about why
it is
wanted to extend the current model in a understandable way.
Every component that is used as a input has at least one "value binding" to
a bean.
In UIInput, the user just set "value" property with an EL expression to
indicate that the value sent should be assigned to that expression.
Now suppose a form with this component that is submitted. The input
component
should first create the "submittedValue" from the information available on
request parameter map. This is done on UIComponent or Renderer decode()
method.
Then, this value is converted to the type required by the "value binding",
through
Converter interface and later, if conversion fails by some reason, the
information
stored on "submittedValue" will be used to render the component later.
Therefore, "submittedValue" must satisfy three conditions:
1. It should contain all info sent by the component through request
parameter map,
otherwise the renderer will not be able to render the component
correctly.
2. It should be on a way that can be converted to the type indicated by
"value binding",
that means the submittedValue type should be a public class, so the
renderer can
instantiate it and conversion model can process it.
3. The component should be responsible to define the type used by
submitted value,
according to its needs.
Now, let's take a look at the current Converter interface:
public interface Converter
{
/**
* used to map the submittedValue to the "value binding".
*/
Object getAsObject(FacesContext context,
UIComponent component,
String value) throws ConverterException;
/**
* used to convert the "value binding" into a String to be used
* on the renderer.
*/
String getAsString(FacesContext context,
UIComponent component,
Object value) throws ConverterException;
}
Note that JSF provide some converters for the most common types, so the user
can
specify which converter use or let JSF decide which one fits best, using
the converters registered with "forClass" mapping. Yes, that's ok, but only
for
components with only one "<input>". In that case, assume String as submitted
value type looks better and keep things simple.
Things start to get confusing when you see the signature of
UIInput.getSubmittedValue():
public Object getSubmittedValue()
Does the conversion model did not make the assumption that String is the
only type to
be used by submittedValue?
But this assumption fails when a more complex component is required. The
typical
example is a component that handles date/time values. In that case, the
date/time value
can be decomposed into its elements (year, month, day, hour, minutes ....).
In this case, a component developer could want to send all that info into
multiple
"<input>" parameters through request parameter map. So, to use the model
proposed,
all that information should be used to encode a String, just to later decode
it on
the converter used to construct the "value binding" required, but later it
will be
decoded/encoded by the renderer again to render the component.
The proposal to put into consideration is do the following modifications on
jsf:
- Add a class called BusinessConverter (maybe you can find other name but
for now let
it as is) :
public interface BusinessConverter
{
public Object getBusinessValue(FacesContext context,
UIComponent component,
Object submittedValue);
public Object getAsSubmittedValue(FacesContext context,
UIComponent component,
Object value);
}
Really is similar to Converter interface but does not force submittedValue
to be String,
instead it lets it open.
- Add the following methods to Application class :
public abstract void addBusinessConverter(Class<?> submittedClass,
Class<?> targetClass,
String converterClass);
public abstract void addBusinessConverter(String businessConverterId,
String
businessConverterClass);
public abstract Converter createBusinessConverter(Class<?>
submittedClass,
Class<?> targetClass);
public abstract Converter createBusinessConverter(String
businessConverterId);
public abstract Iterator<String> getBusinessConverterIds();
public abstract Iterator<Class<?>> getBusinessConverterTypes(Class<?>
submittedClass);
Again, it is similar to converter methods on Application class, but in this
case it takes
into consideration the submittedClass. Therefore, a component that define as
submittedClass
java.util.Date, could retrieve the converters that can handle this
conversion. From some
point of view, the current Converter interface is a particular case when
submittedClass is
java.lang.String.
- Add the following methods to UIOutput class :
public BusinessConverter getBusinessConverter();
public void setBusinessConverter(BusinessConverter converter);
/**
* Return the value type the submitted value will take on
* decode() method. In my opinion, allow just one submittedValueType is
* enough.
*/
public Class<?> getSubmittedValueClass();
The idea is provide a way to configure business converter, just like
Converter.
Note this implies change some stuff on UIInput too.
- Add an annotation @FacesBusinessConverter.
- Add a component f:businessConverter in the same way as f:converter.
I would like to put into consideration this idea. My personal opinion is
this should be
included at the spec level for two reasons:
- It is clear there is a contradiction between UIInput.getSubmittedValue()
and
Converter interface.
- It could be good to have a common repository for business converters, and
use JSF
annotations to register it.
I have some code I'm working but it is better to know if you think it is
worth or
not before continue. If it is necessary I can help with the implementation.
Suggestions are welcome
best regards,
Leonardo Uribe
Note: As an historical comment, currently, Trinidad has a workaround for
handle
handle "oracle types", from the binding layer, using an interfaces called
TypedConverter as you can see below:
package org.apache.myfaces.trinidadinternal.convert;
public interface TypeConverter
{
/**
* converts the given Object into an instance of the
* targetType.
* @return an instance of the targetType.
*/
Object convert(Object source, Class<?> targetType);
}
The idea behind this interface is provide a way that trinidad can
"understand"
specific types and include them when are resolved, but note this class is
not
part of trinidad api. The reason is this is just an internal workaround.
COMMENTS FROM OTHER PEOPLE SUPPORTING THIS ISSUE:
Martin Koci
MK>> maybe this is a stupid question but:
MK>>
MK>> >From UIInput javadoc:
MK>>
MK>> ... decoded value of this component, usually but >>>not necessarily a
MK>> String<<<, must be stored - but not yet converted - using
MK>> setSubmittedValue() ....
MK>>
MK>> from UIInput.getConvertedValue:
MK>>
MK>> ... and the submitted value is a >>>String<<<, locate a Converter as
MK>> follows
MK>>
MK>> Question: why is Converter tied only to String? Whole specification
MK>> speaks about submitted value as of "raw representation of value from
MK>> client" but not necessarily String. And 3.3 Conversion Model: "This
MK>> section describes the facilities provided by JavaServer Faces to
support
MK>> type conversion between server-side Java objects and their (typically
MK>> String-based) representation in presentation markup."
MK>> But Converter.getAsObject expects only String as this "raw
MK>> representation" and "typically String-based" formulation from spec now
MK>> means "always String-based".
MK>> It seems to me that Converter introduces unnecessary dependency on
MK>> String-based representation - even ResponseWriter.write* accepts
MK>> java.lang.Object as value ....
MK>>
MK>> What I try to do is JSF-based server view with custom NOT-string based
MK>> protocol where "raw representations from client" can be java object
like
MK>> Integer or more complex. Creating of:
MK>>
MK>> interface Converter2 {
MK>> Object getAsObject(FacesContext,UIComponent,Object)
MK>> Object getAsRepresentation(FacesContext,UIComponent,Object)
MK>> }
MK>>
MK>> solves my problem but I must reprogram significant part of JSF api.
Martin Marinschek
MM>> MK>> So on JSF level conversion String <-> Object is unable to solve
this
MM>> MK>> problem - I simply need Object <-> Object conversion which is not
MM>> MK>> supported yet.
MM>>
MM>> Yes, this is true - this is obviously a spec problem.
MM>>
MM>> If the submitted value is an object, it should also be allowed to
MM>> convert it. A converter is more than just a string to object (and
MM>> back) converter, it is an artefact which transforms information from
MM>> its representation for output (and this output could be anything, and
MM>> certainly doesn't have to be string based) to its representation which
MM>> the business model (or also an artefact within JSF, like a validator)
MM>> understands.
MM>>
MM>> So I agree. This hasn't come up so far cause nobody uses non string
MM>> based output models for JSF.
MM>>
MM>> Note that my notion of a business converter (discussed on this mailing
MM>> list a while ago) for converting between a business model
MM>> representation and a representation in a JSF artefact like the
MM>> renderer (e.g. you use joda.Date in the business model, but the JSF
MM>> date picker renderer only understands the normal java date) is also
MM>> hinting in the direction that such an additional converter API would
MM>> be necessary. I discussed this with the EG (and also Ed privately),
MM>> and there wasn't much interest for adding this.
14 years, 1 month
[jsr-314-open-mirror] [jsr-314-open] Cannot register listener for PostConstructApplicationEvent and PreDestroyApplicationEvent using @ListenerFor annotation
by Leonardo Uribe
Hi
This issue is related to
https://issues.apache.org/jira/browse/MYFACES-2509 @ListenerFor not
processed for global system events
On JSF 2.0 the following system events were added:
javax.faces.event.PostConstructApplicationEvent
javax.faces.event.PreDestroyApplicationEvent
javax.faces.event.PostConstructCustomScopeEvent
javax.faces.event.PreDestroyCustomScopeEvent
javax.faces.event.PostConstructViewMapEvent
javax.faces.event.PreDestroyViewMapEvent
And the following component system events were added:
javax.faces.event.PostAddToViewEvent
javax.faces.event.PreRemoveFromViewEvent
javax.faces.event.PostRestoreStateEvent
javax.faces.event.PreValidateEvent
javax.faces.event.PostValidateEvent
javax.faces.event.PreRenderComponentEvent
javax.faces.event.PreRenderViewEvent
The javadoc of @ListenerFor annotation is clear to say which classes could
be a valid target for this annotation:
"....The default implementation must support attaching this annotation to
UIComponent or Renderer classes. In both cases, the
annotation processing described herein must commence during the
implementation of any variant of Application.createComponent() and
must complete before the UIComponent instance is returned from
createComponent()...."
Long time ago on MYFACES-2509, it was mentioned those classes could not be
the only target:
Jan-Kees van Andel
JK>> Hrm, it looks like the JavaDoc can be interpreted in multiple ways.
JK>>
JK>> What I read, is that it should be possible for classes that implement
JK>> SystemEventListener, to listen to SystemEvents.
JK>>
JK>> For example: PostConstructApplicationEvent
JK>>
JK>> The current implementation cannot deal with this event, because it
occurs
JK>> before the ApplicationImpl code is invoked (there is no component tree
at
JK>> that time). For this reason, we need to check it @startup.
JK>>
JK>> But because its so ambiguous, I suggest to leave it out of the (myfaces
core) beta release.
Thinking about how to enhance some myfaces projects and reading some
documentation I notice this usage on the book The Complete
Reference JavaServer Faces 2.0 Page 509 (just type on google @ListenerFor
PostConstructApplicationEvent and you will find it):
@ListenerFor(systemEventClass =
javax.faces.event.PostConstructApplicationEvent.class)
public class TestSystemEventListener implements SystemEventListener {
...
}
The previous example does not work on both myfaces and mojarra, because both
implement what @ListenerFor javadoc says. But note this
syntax should be valid on JSF 2.0, at least for
PostConstructApplicationEvent and PreDestroyApplicationEvent.
I tried something more elaborated like this:
@ManagedBean(name="myCustomListener", eager=true)
@ApplicationScoped
@ListenersFor({
@ListenerFor(systemEventClass=PostConstructApplicationEvent.class),
@ListenerFor(systemEventClass=PreDestroyApplicationEvent.class)
})
public class SimpleFacesConfigListener implements SystemEventListener
{
...
}
Does not work too, but the fact is that syntax should be valid too. Well,
maybe we can use @PostConstruct and @PreDestroy and have the
same effect, but it is worth to mention it.
It could be good to know what do you think about it. I feel inclined to
include it in myfaces, but better to ask first.
Anyway, it could be good if you can consider if it is worth or not adding
@ListenerFor annotation support for JSF application scope objects and
factories (ex: Application, RenderKit, StateManager, ViewHandler .....). I'm
not very sure about it, but better to mention it.
Should I create a spec issue for this one? I think yes.
In another topic, looking for more issues, I notice a side effect testing
this example:
<system-event-listener>
<system-event-listener-class>org.apache.myfaces.testListenerFor.SimpleFacesConfigListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
</system-event-listener>
<system-event-listener>
<system-event-listener-class>org.apache.myfaces.testListenerFor.SimpleFacesConfigListener</system-event-listener-class>
<system-event-class>javax.faces.event.PreDestroyApplicationEvent</system-event-class>
</system-event-listener>
public class SimpleFacesConfigListener implements SystemEventListener
{
...
}
In this case according to both myfaces and mojarra implementation, the
object instance that receive PostConstructApplicationEvent is
not the same that receive PreDestroyApplicationEvent, so the listener should
be "stateless", but the spec does not warn about this
fact (in theory it should be).
regards,
Leonardo Uribe
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
by Ed Burns
>>>>> On Thu, 23 Sep 2010 12:54:09 -0700, Kito Mann <kito.mann(a)virtua.com> said:
Kito> Hello everyone,
Kito> Let's meet at the Thirsty Bear instead, so people can show up later if
Kito> necessary. I'm doing a podcast with Dan Allen until 6 or so. What's the best
Kito> time for everyone?
7pm. Can you please tweet it out liberally?
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 1 work days until handoff of JSF 2.1 change log to jcp
| 0 work days until JavaOne 2010
| 35 work days until DOAG 2010
| 39 work days until JSF 2.1 Milestone 6
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
by Kito Mann
Hello everyone,
Let's meet at the Thirsty Bear instead, so people can show up later if
necessary. I'm doing a podcast with Dan Allen until 6 or so. What's the best
time for everyone?
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Sep 22, 2010, at 2:43 PM, Hazem Saleh <hazems(a)apache.org> wrote:
+1 for Jankees
On Wed, Sep 22, 2010 at 1:21 PM, Jan-Kees van Andel <
jankeesvanandel(a)gmail.com> wrote:
> +1 for Thursday. I think my Thursday night is still free. How about meeting
> at the Hilton, after my talk? According to the current schedule, it's in the
> Continental Parlor 1/2/3 in the Hilton from 15:30 to 16:30.
>
> /JK
>
>
> 2010/9/21 Edward Burns <edward.burns(a)oracle.com>
>
> On 9/20/10 23:13 , Kito Mann wrote:
>>
>>> We're thinking Thursday might be good for some drinks, if anyone is
>>> still around.
>>>
>>
>> That would be better for me, actually. I double booked myself for
>> Wednesday night.
>>
>> Kito, thanks for taking point on this one.
>>
>> Ed
>>
>
>
--
Hazem Ahmed Saleh Ahmed
Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY
Web blog: http://www.jroller.com/HazemBlog
[Web 2.0] Mashups Integration with JSF:
http://code.google.com/p/mashups4jsf/
14 years, 2 months
