[FACELETS-374] Composite components arguments are passed to ui:insert Created: 12/Oct/11  Updated: 12/Oct/11

Status: Open
Project: facelets
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: piojas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If I define composite component with name comp like this:

<ui:component xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:c="http://java.sun.com/jstl/core" xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets">	
  Argument: #{empty argument? 'empty': argument}.
  <ui:insert/>
</ui:component>

then:

<comp argument="value">
  <comp/>
</comp>

will generate:

Argument: value. Argument: value.

but it should generate:

Argument: value. Argument: empty.

What is more, when we define component like this:

<ui:component xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:c="http://java.sun.com/jstl/core" xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets">	
  Argument: #{empty argument? 'empty': argument}.
  <c:set var="argument" value="foo"/>
  <ui:insert/>
</ui:component>

then

<comp argument="value">
  <comp/>
</comp>

will generate:

Argument: value. Argument: foo.

but it should generate:

Argument: value. Argument: empty.





[FACELETS-373] 1.1.15 has a compile dependency on JSF 1.2 Created: 18/Jul/11  Updated: 18/Jul/11

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.15
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gpitteloud Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From facelets 1.1.14 to 1.1.15, the method UIRepeat.invokeOnComponent(FacesContext faces, String clientId, ContextCallback callback) has been added. It is not possible to use facelets with JSF 1.1 anymore.



 Comments   
Comment by gpitteloud [ 18/Jul/11 ]

When instanciating a UIRepeat tag, class introspection is performed, and a ClassNotFoundException is thrown when the introspector goes over invokeOnComponent().





[FACELETS-372] ui:repeat doesn't accept ValueExpressions for "var" and "varStatus" - useful for composite components Created: 07/Jun/11  Updated: 28/Jun/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: None

Type: Bug Priority: Major
Reporter: swehner33 Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File UIRepeat.diff     File UIRepeat.java.patched    
Tags: composite_components, facelet, ui_repeat, valueexpression, var, varstatus

 Description   

UI:repeat only accepts Strings and not ValueExpressions for both var and varStatus attributes - using a ValueExpression to define these attribute values doesn't work even though the Documentation mentions possible use of ValueExpressions.

The use case we have is in a composite component that uses an ui:repeat in the implementation and lets the user specify the var attribute.

<timeline:timeline events="#

{eventHistoryView.eventList}

" var="event" varStatus="eventStatus">
<timeline:event title="#

{event.summary}

"/>
</timeline:timeline>

The component's implementation would be something like this:

— timeline/timeline.xhtml —

<cc:interface>
<cc:attribute name="events" required="true"/>
<cc:attribute name="var" required="true"/>
<cc:attribute name="varStatus" default="status"/>
</cc:interface>
<cc:implementation>
<div id="#

{cc.clientId}

" style="height: 150px; border: 1px solid #aaa"/>
<ui:repeat var="#

{cc.attrs.var}

" value="#

{cc.attrs.events}

" varStatus="#

{cc.attrs.varStatus}

">
<cc:insertChildren/>
</ui:repeat>
</cc:implementation>

— timeline/event.xhtml —

<cc:interface>
<cc:attribute name="title"/>
...
</cc:interface>
<cc:implementation>
Title: #

{cc.attrs.title}

...
</cc:implementation>

We're attaching a patch to UIRepeat that uses getters similar to begin, end, etc... for var and varStatus.
We've also changed every direct use of the field var/varStatus with getVar()/getVarStatus().

We know there are some other workarounds, and we could use the ui:repeat in timeline/event component, but still it'd seem to make sense to allow ValueExpressions for var and varStatus, doesn't it?



 Comments   
Comment by vindum [ 28/Jun/12 ]

Any news on this? Will this be fixed in a future release?





[FACELETS-371] Replace XHTML by HTML 5 Created: 19/Apr/11  Updated: 19/Apr/11

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fribeiro Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Given that support for HTML 5 is coming to JSF in 2.2, we should consider moving from XHTML 1.1 to HTML 5 as the language in the templates.






[FACELETS-370] CLONE -UIDebug not working with Spring WebFlow with 2.0.4 Created: 15/Mar/11  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: kenyatta Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 312

 Description   

When using <ui:debug> tag in JSF views managed by Spring WebFlow, the debug
window opens with a server side error:
java.lang.NumberFormatException: For input string:
"1?facelets.ui.DebugOutput=1209388398877"

The reason is that UIDebug.encodeBegin assumes that action URL has no URL
parameters in it, what is not true for SWF (action URL is of form
'/monitoring/spring/get?execution=c1v1')

The UIDebug code should check whether action URL contains URL parameters and
append '?' or '&' correspondingly.






[FACELETS-369] "Component ID has already been found in the view" thrown when using composite components with <c:if> or <c:forEach> Created: 14/Mar/11  Updated: 09/Feb/12

Status: Open
Project: facelets
Component/s: None
Affects Version/s: 1.1.15
Fix Version/s: None

Type: Bug Priority: Major
Reporter: TomaszKurpios Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JSF 2.0 RI


Attachments: Text File facelets.patch    

 Description   

There seems to be a problem with the algorithm that assigns tag ids. Say we have the following code:

"example.xhtml"
	<h:form id="form">
		<c:if test="#{Bean.clicked}">
			<ns:compositeComponent id="aa"/>
		</c:if>
		<ns:compositeComponent id="bb"/>
		<h:commandLink value="Click" action="#{Bean.click}" />
	</h:form>

where ns is some namespace and compositeComponent is a component defined in its own file:

"compositeComponent.xhtml"
        <h:panelGroup id="#{id}" xmlns:h="http://java.sun.com/jsf/html"/>

The implementation of Bean (session scoped in my case):

"Bean.java"
	public class Bean {
		private boolean clicked = false;
		
		public boolean isClicked() {
			return clicked;
		}
		
		public void click() {
			clicked = true;
		}
	}

After clicking on the command link the exception is thrown:
Component ID form:bb has already been found in the view.

The problem is that during the process of building view after the click, the generated id for the first <h:panelGroup> component (inside <c:if>) is exactly the same as it was for the second <h:panelGroup> during the first tree building process. This way during the second tree building process the first <h:panelGroup> component is found and the second (the one outside <c:if>) - was not found, therefore the second one is created and assigned JSF id "bb". This way we have two <h:panelGroup> components with id="bb"



 Comments   
Comment by TomaszKurpios [ 14/Mar/11 ]

When I wrote "component is found" I meant that ComponentSupport.findChildByTagId method inside ComponentHandler.apply method returned a non-empty result.

Comment by piojas [ 09/Feb/12 ]

I believe that this patch to DefaultFaceletContext fixes this problem. Could someone verify it please?





[FACELETS-368] strange duplicate content rendered with two <ui:insert> tags in different facelet pages Created: 13/Aug/10  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.2
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: the_alchemist Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: GZip Archive eclipse-weird.rendering.project.tar.gz     File facelets-strange.renderings.mp4     PNG File jsf-bad.rendering.screenshot.png     PNG File jsf-good.rendering.screenshot.png    
Issuezilla Id: 368

 Description   

I've been following the tutorial at
http://www.andygibson.net/blog/article/how-to-do-10-common-tasks-in-jsf-2-0/ .
It contains some pretty basic JSF / Facelets stuff.

I came across an issue where a duplicate component (in this case, an input
field) gets rendered at the bottom of the page of the page when it's not
supposed to.

This happens when I have a <ui:insert> that I don't strictly need for this
project. The screencast shows this.

FILES

  • calculator.xhtml
  • main page
  • has <ui:composition template="index.xhtml">
  • has two <ui:decorate template="/property.xhtml">
  • property.xhtml
  • a <ui:composition>
  • a few div tags
  • a <ui:insert />
  • index.xhtml
  • "main" template
  • has lots of <ui:insert>'s
  • has lots of div tags
  • has a <ui:insert>

I'm going to attach the Eclipse project, the screencast, and screenshots to
demonstrate what I mean.

Thanks, all!



 Comments   
Comment by the_alchemist [ 13/Aug/10 ]

Created an attachment (id=146)
screencast of Eclipse project and what the output looks like

Comment by the_alchemist [ 13/Aug/10 ]

Created an attachment (id=147)
Eclipse 3.6 project that contains the pages that don't render right

Comment by the_alchemist [ 13/Aug/10 ]

Created an attachment (id=148)
bad rendering

Comment by the_alchemist [ 13/Aug/10 ]

Created an attachment (id=149)
good rendering





[FACELETS-367] ui:repeat in combination with h:inputText Created: 05/Aug/10  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.12
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: tougar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 367

 Description   

When updating several values in h:inputTexts rendered by an ui:repeat component
via ajax, the wrong value is written into the value attribute of the input.
assigning the value to an Label on the blank page is no issue






[FACELETS-366] multi-threaded access to an unsynchronized Map Created: 10/May/10  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Critical
Reporter: sbartram Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 366

 Description   

MetaRulesetImpl.getMetadataTarget method modifies a static WeakHashMap object without any
synchronization. We have observed corruption of the hashmap structure in a heavily loaded system.

The method should be synchronized or refactored to avoid multi-threaded updates to the map.






[FACELETS-365] f:phaselistener re-registered on every validation error Created: 02/Mar/10  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: rpodlas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 365

 Description   

Dear All,
I had much troubles with a (before render response) phaselistener registered to
my facelets view using the <f:phaselistener> tag. It was called multiple times
although registered only once. As I unsuccessfully spent hours to search on the
web for such an issue I started to debug the facelets view root and found out,
that whenever I submit the facelets view with invalid content (validation
fails) it jumps to the render response phase, but my phaselistener is suddenly
registered one more time. I.e. when I first view the facelets page my
phaselistener runs only once as it is only registered once in the view root.
When I then submit with invalid input and the validation fails, it goes to the
render reponse phase again and suddenly my phaselistener ist called twice (as
it is now registere 2 times in the view root). Whenever I repeat submitting
invalid values and validation fails, the registration count of my phaselistener
is incremented (i.e. 3 times after my 2nd attempt to submit invalid
values...and so on).
I do not think this is wanted, and also could not find any documentation about
this behaviour. To me it looks like a defect. Am I right?
Thank you, Rainer Podlas

(in the meantime I do not registere it for the view with the f:phaselistener
tag, but instead perform the lifecycle registration via config, but anyway it
would be great if it works properly via the tag)






[FACELETS-364] c:foreach throws nullpointer exception Created: 05/Jan/10  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: UNKNOWN
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: delgurth Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=9605


Issuezilla Id: 364

 Description   

This bug was found in facelets 1.1.15-jsf1.2, but that's not a revision I can
choose.

If you use the c:foreach tag without begin or step it throws a nullpointer
exception.

The defect is in IterationStatus.java and below is the patch (for java 1.5). The
bug was introduced in rev 1.5, which is an attempt to fix issue: 328

For the "discussion" about this see:
https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=9605

— src\java\com\sun\facelets\tag\jstl\core\IterationStatus.java~ 2009-12-17
18:19:52.763847200 +0100
+++ src\java\com\sun\facelets\tag\jstl\core\IterationStatus.java 2009-12-17
13:26:50.171870900 +0100
@@ -51,7 +51,9 @@
this.step = step;
this.first = first;
this.last = last;

  • this.even = ((index - begin) / step) % 2 == 0;
    + int iBegin = ((begin != null) ? begin.intValue() : 0);
    + int iStep = ((step != null) ? step.intValue() : 1);
    + this.even = ((index - iBegin) / iStep) % 2 == 0;
    }

public boolean isFirst() {






[FACELETS-363] Enabling the attribute name in the tags <ui:insert> e <ui:define> receives parameters, currently receives only a literal Created: 23/Dec/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: New Feature Priority: Critical
Reporter: rafaelmeireles Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Issuezilla Id: 363

 Description   

Enabling the attribute name in the tags <ui:insert> e <ui:define> receives
parameters, currently receives only a literal
example:

<ui:insert name="nameDefault#

{nameOfUC}" />

<ui:define name="nameDefault#{nameOfUC}

">
code here
</ui:define>

On one page I inserted another page that contains the template:

<ui:include src="page.xhtml">
<ui:param name="nameOfUC" value="Country" />
</ui:include>

This behavior would be useful for the use of modal, where templates would be
used in more than one modal, and thus the same section <ui:define> on the same
page, since the code block of the modalis inserted in the middle of the page
that calls the modal. As there are more of a modal on the same page that use the
same modal structure, two blocks would modal, and thus two <ui:define> for
example, and it does not work in facelets because he always keeps the contents
of the first <u i: define>






[FACELETS-362] Facelet path treated as regexp Created: 22/Dec/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: Daniel Lichtenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 362

 Description   

I'm running a Jetty-based JSF application [1] on Mac OS X. Startup fails with
this stacktrace [2]:

java.util.regex.PatternSyntaxException: Dangling meta character '+' near index 48
/private/var/folders/Ua/Ua4hBwrbHfamEYcHEKe47k+++TQ/Tmp/Jetty_0_0_0_0_8080_flexive.war_flexive_qfub3b/webapp/
^
at java.util.regex.Pattern.error(Pattern.java:1713)
at java.util.regex.Pattern.sequence(Pattern.java:1878)
at java.util.regex.Pattern.expr(Pattern.java:1752)
at java.util.regex.Pattern.compile(Pattern.java:1460)
at java.util.regex.Pattern.<init>(Pattern.java:1133)
at java.util.regex.Pattern.compile(Pattern.java:823)
at java.lang.String.replaceFirst(String.java:2146)
at
com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:221)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:150)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:101)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
at
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.flexive.war.filter.FxFilter.doFilter(FxFilter.java:145)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:334)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:482)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.flexive.war.filter.JsonRpcFilter.doFilter(JsonRpcFilter.java:81)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at com.flexive.war.filter.VersionUrlFilter.doFilter(VersionUrlFilter.java:68)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at com.flexive.war.filter.FxFilter.doFilter(FxFilter.java:145)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)

com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:221)
contains:

url.getFile().replaceFirst(this.baseUrl.getFile(), "");

String#replaceFirst apparently expects a regexp, and since the path with the
temporary directory contains control characters ("+"), this fails. As a quick
fix I replaced replaceFirst with the 1.5 method String#replace(). I'm not sure
whether there are actually scenarios where the base URL might end up more than
once in the file path, so the cleaner solution would probably be to properly
escape regexp control characters in this.baseUrl.getFile().

[1] http://www.flexive.org/
[2] http://issuetracker.flexive.org/jira/browse/FX-770






[FACELETS-361] 321 bug fix has potential problems. Better fix suggested here. Created: 09/Nov/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: plaudit Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://facelets.dev.java.net/issues/show_bug.cgi?id=321


Issuezilla Id: 361

 Description   

The fix on this bug is not the best option:
https://facelets.dev.java.net/issues/show_bug.cgi?id=321

The reasons this is not the best is:

  • Garbage collection will constantly clear the weakhashmap since a String is
    used as the key.
  • If facelets is shared between multiple webapps (ignoring my first point) and
    when you redploy a webapp, previous metadatarulsets will remain in the map
    causing a small memory leak.

I believe a better solution is to use the actual Class as the key. This is the
same approach that java.beans.Introspector takes.

In addition to fixing the originally 321 bug and solving the above concerns it
saves memory since we aren't creating another object to be used as the key – we
are using something already in memory.






[FACELETS-360] c:forEach: duplicated ID when component removed and then added back Created: 04/Nov/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: ishaikovsky Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File dyntabpanel.zip    
Issuezilla Id: 360

 Description   

The issue originally not related to id's I just simplified https://
jira.jboss.org/jira/browse/RF-7962 case.

Test case war attached.

Related Code
<h:form>
<h:inputText value="#

{bean.number}

" />
<h:commandButton value="Add" action="#

{bean.add}

"/>
<h:commandButton value="Remove" action="#

{bean.remove}

"/>
</h:form>
<h:panelGrid>
<c:forEach items="#

{bean.tabs}

" var="number">
<h:outputText id="tab#

{number}" value="#{number}

" />
</c:forEach>
</h:panelGrid>
Bean contains ArrayList of Strings. We removing String "2". And getting "1" and
"3" fine rendered. BUT: <ui:debug/> shows us that there are still three
outputText components in tree. And after we trying to add "2" back - duplicated
id exception risen.
If after removing but before adding we will refresh the page - this issue will
not appears. Also the problem not reproduced if we removing last imtem from
list instead of second.

We investigated the case and found out that seems when forEach handler invoked
on build view - component handler doesn't process last component because of the
collection new length.



 Comments   
Comment by ishaikovsky [ 04/Nov/09 ]

Created an attachment (id=143)
maven based source project

Comment by ishaikovsky [ 12/Nov/09 ]

RF QE engineer added to CC.





[FACELETS-359] Error in initialization sequence Created: 03/Nov/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: Kevin Dean Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 359

 Description   

In com.sun.facelets.FaceletViewHandler.restoreView(), lines 315-321:

if (!this.buildBeforeRestore || !handledByFacelets(viewId))

{ return this.parent.restoreView(context, viewId); }

if (this.faceletFactory == null) { this.initialize(context); }

The buildBeforeRestoreProperty is dependent on proper initialization. The
sequence of these lines should be:

if (this.faceletFactory == null) { this.initialize(context); }

if (!this.buildBeforeRestore || !handledByFacelets(viewId)) { return this.parent.restoreView(context, viewId); }




[FACELETS-358] Custom component with children - Child component added dynamically at end appears as first child when rendered <full source code included> Created: 29/Oct/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Blocker
Reporter: kpkeerthi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 358

 Description   

Here is a highly simplified case of the problem (source included):

The custom component 'repeat' will simply iterate through its children and
renders them.

Usage:

<custom:repeat binding="#

{testBean.htmlRepeat}

">
<h:outputText value="Child-1"/>
<h:outputText value="Child-2"/>
</custom:repeat>

Below is how the component renders:

[begin - Child-1Child-2 - end]

BackingBean:

The repeat component is bounded to a backing bean like so:

public class TestBean {

private HtmlRepeat htmlRepeat;

public HtmlRepeat getHtmlRepeat()

{ return null; }

public void setHtmlRepeat(HtmlRepeat htmlRepeat)

{ this.htmlRepeat = htmlRepeat; }

// – action method
public String formSubmitted()

{ System.out.println("formSubmitted()"); Application application = FacesContext.getCurrentInstance().getApplication(); // Create a new child and add it to the parent HtmlOutputText child = (HtmlOutputText) application.createComponent(HtmlOutputText.COMPONENT_TYPE); child.setValue("Child-3"); htmlRepeat.getChildren().add(child); return null; }

}

and the form is submitted using <h:commandButton value="Submit"
action="#

{testBean.formSubmitted}

"/>

The formSubmitted() method simply adds a child to htmlRepeat using
htmlRepeat.getChildren().add(child). Note that the child is added as the last
child to the children list. But when the response is rendered, the newly added
child appears at the beginning.

Expected Output:
[begin - Child-1Child-2Child-3 - end]

Actual Output:
[begin - Child-3Child-1Child-2 - end]

Attachments:

1. jsf-repeat.jar - Deployable JSF component packaged as jar (contains .java
files, faces-config.xml and facelet taglib).

Download >> http://keerthi.linux.googlepages.com/jsf-repeat.jar

2. TestRepeat.xhtml - Facelet view using the <netx:repeat/> custom component

Download >> http://keerthi.linux.googlepages.com/TestRepeat.xhtml (Use Save
target as, otherwise you will get only a blank page)

Note: Tested on myfaces1.2.6/Tomcat 6.20/Facelets .14 & .15






[FACELETS-357] When using ui:repeat and inputText with attributes that are 'nullable' (for example date attributes) they cannot be set to null by entering an empty String ("") Created: 02/Oct/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: UNKNOWN
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: marcelurbanek Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 357

 Description   

(Affected Facelets Version is 1.1.15.B1)
When using ui:repeat in conjunction with an input field and a attribute with a
type that can normally be set to null by a user (for example a date) by entering
an empty string into the input field (""), it is not possible for the user to do
so. A small example:

TestBean.java:

public class TestBean {
public List testEntries=new LinkedList();
public TestBean()

{ testEntries.add(new TestEntry()); }

public class TestEntry implements Serializable{
private Date testAttribute;

public Date getTestAttribute()

{ return testAttribute; }

public void setTestAttribute(Date testAttribute)

{ System.out.println("set:"+testAttribute); this.testAttribute = testAttribute; }

}
public List getEntries()

{ return testEntries; }

}

test.xhtml (excerpt):

<ui:repeat value="#

{TestBean.entries}

" var="entry">
<h:inputText value="#

{entry.testAttribute}

">
<f:convertDateTime type="date" dateStyle="medium"/>
</h:inputText>
</ui:repeat>

When you now enter a Date (lets say 1/1/2009) it is accepted and set. If you try
to set the date to null by entering an empty string into the input field, it
gets set to its initial value (1/1/2009).

The problem happens in the "populate" method of UIRepeat.SavedState . It uses
"getValue" to get the current component value after the value was already set to
null. The "getValue" method itself will then try to get a value from the value
it is bind to instead, which is, at that state, still filled with the old data
(1/1/2009) and returns this value. When the "apply" Method is fired afterwards
the old value is then written again to the component value and the value binding
won't get updated with the null value. Using "getLocalValue" instead of
"getValue" seems to solve the problem:

public void populate(EditableValueHolder evh) {
this.value = evh.getLocalValue();
this.valid = evh.isValid();
this.submittedValue = evh.getSubmittedValue();
this.localValueSet = evh.isLocalValueSet();
}






[FACELETS-356] Fix for issue 228 in UIInstructionHandler.apply method causes Performance degradation Created: 28/Aug/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Blocker
Reporter: yagish Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 356

 Description   

The fix for issue 228 in UIInstructionHandler.apply method causes a performance
degradation when porting from facelets1.1.12 to facelets1.1.14.

Using JProbe and profiling the application, we found the
FaceletViewHandler.buildView() method almost takes double time to execute on an
average in Facelets1.1.14, than it takes in Facelets1.1.12. Digging deeper we
found its the UIInstructionHandler.apply method, which used to take 3000
ms(approx.) for 30,000 calls in Facelets1.1.12, now takes 80,000 ms for same
number of calls in Facelets1.1.14.



 Comments   
Comment by yagish [ 01/Sep/09 ]

Raising the priority cause of its impact.





[FACELETS-354] Remove calls to flush methods on streams Created: 30/Jul/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Improvement Priority: Critical
Reporter: ramiromagalhaes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 354

 Description   

Near FaceletViewHandler.java line 695 you can read

Writer w = httpResp.getWriter();
DevTools.debugHtml(w, context, e);
w.flush();
context.responseComplete();

I think the code w.flush() should be removed because this commits the response.
If the response is commited, Servlet filters that manipulate the output stream
won't work right.






[FACELETS-353] duplicate id with c:forEach when child IDs are manually set Created: 13/Jul/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Critical
Reporter: josefreire Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File proposedPatch-20090714.diff     Text File proposedPatch-20090820.diff     Text File proposedPatch-353-20091229.diff     Java Source File ShowBugForEach.java     Text File showBugForEach.xhtml    
Issuezilla Id: 353

 Description   

If you have a simple c:forEach loop, and it's children have manually set ids,
adding one line will ignore the new manually set id, and will duplicate the
previous id on the list, giving a duplicate id error.



 Comments   
Comment by josefreire [ 13/Jul/09 ]

Sorry:
If you add a new line in the beginning of the list, you get duplicate ids.

Comment by josefreire [ 13/Jul/09 ]

Created an attachment (id=138)
Show bug in action (xhtml)

Comment by josefreire [ 13/Jul/09 ]

Created an attachment (id=139)
Show bug in action (managed bean)

Comment by josefreire [ 13/Jul/09 ]

Created an attachment (id=140)
Proposed patch

Comment by josefreire [ 20/Aug/09 ]

Created an attachment (id=142)
Proposed patch

Comment by josefreire [ 29/Dec/09 ]

Created an attachment (id=145)
Proposed patch (doesn't break state saving inside a forEach)





[FACELETS-352] Facelets setDefaultUseCaches to false Created: 13/Jun/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Blocker
Reporter: oxleydave Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 352.diff    
Issuezilla Id: 352

 Description   

The Class:
com.sun.facelets.util.Classpath
in method search calls:
conn.setDefaultUseCaches(false);
which sets all URLConnections within the JVM to never use caching. I found this
as I started getting HTTP 503 status codes from W3C servers for requesting
xhtml1-transitional.dtd even though I'd put a squid server in to cache them. It
took many hours to track down this obscure problem!



 Comments   
Comment by oxleydave [ 13/Jun/09 ]

Created an attachment (id=135)
Suggested fix





[FACELETS-350] Valid XHTML with namespace declarations and nested lists renders wrongly in JSF/Facelets Created: 28/May/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: wastl Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 350

 Description   

If I take the following (valid) XHTML document and try to render it as a JSF
page with facelets, the nesting of lists is for whatever reason wrong, the
second heading is indented and displayed as part of the first list. It works as
soon as I remove the xmlns:kiwi attribute from the link (which is, however,
valid XHTML). Namespace declaration in e.g. ui:composition seems to work,
though, but since my XHTML is generated automatically as canonicalized XML, I
consider this a serious bug nonetheless.

<h2>Heading 1</h2>

<ul>
<li><a href="http://localhost/"
xmlns:kiwi="http://www.kiwi-project.eu/kiwi/html/">Link</a>
<ul>
<li>Subitem 1</li>
<li>Subitem 2</li>
</ul>
</li>
</ul>

<h2>Heading 2</h2>

<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>






[FACELETS-349] nested ui:repeat does not work when datamodel is changed in invoke application phase Created: 07/May/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: stemey Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File proposedPatch-20090703.diff     Text File proposedPatch-20091229.diff     Zip Archive showBug.zip    
Issuezilla Id: 349

 Description   

I have a nested ui:repeat like this:

<ui:repeat var="item" value="#

{context.selectItemListRows}

">
<tr>
<ui:repeat var="item" value="#

{row}

">
<td>
<h:outputLabel for="itemSelector" styleClass="#

{item.selected ? 'active' : ''}

">
<h:selectBooleanCheckbox id="itemSelector" value="#

{item.selected}

"/>
<h:outputText value="#

{item.label}

"/>
</h:outputLabel>
</td>
</ui:repeat>
</tr>
</ui:repeat>

Everything works fine except that updates to the DataModel (nested list in this
case) in the invoke application phase are not reflected in the value of the
stamped checkbox component. This is because the value is locally set and the
expression is not evaluated again. Otherwise the expression evaluation would
return the corrcet value.



 Comments   
Comment by josefreire [ 29/Jun/09 ]

Created an attachment (id=136)
Simple test to show the bug in actions

Comment by josefreire [ 02/Jul/09 ]

Created an attachment (id=137)
Proposed patch

Comment by josefreire [ 29/Dec/09 ]

Created an attachment (id=144)
Proposed patch (don't clear child state if there are validation errors)





[FACELETS-348] Unique IDs are not enforced for components repeated by c:forEach Created: 27/Apr/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Critical
Reporter: mst_70 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 348

 Description   

UIComponnetClassicTagBase used to ensure that IDs on components repeated by
c:forEach are unique. However, Facelets' ComponentHandler has no such code.

If the Id of the repeated component is not specified, a unique Id gets
generated. However, literal Ids are written 'as is', so you may end up with the
id 'id1' repeated n times. This produces invalid HTML.

We understand that literal Ids are not very useful when a component is used
within c:forEach because actual Id value are impossible to predict. However, our
customization layer stores identifies customizations within a document using
literal Id, and customizing a repeated component is a valid use case.






[FACELETS-347] TagValueExpression.equals does not work properly Created: 25/Mar/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: igor_ti Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 347

 Description   

This is the source code of TagValueExpression equals method:

public boolean equals(Object obj) {
return this.orig.equals(obj.orig);
}

This implementation uses the orig property to be compared with the obj parameter
and not the orig property of the obj parameter. i.e. this should be:

public boolean equals(Object obj) {
return this.orig.equals(obj.orig);
}



 Comments   
Comment by igor_ti [ 17/Nov/09 ]

Today I reviewed this issue and realized that I posted the current facelets
source code incorrectly (with the fix applied), then follow down the source of
the current class TagValueExpression that makes the comparison unfair manner.

public boolean equals(Object obj)

{ return this.orig.equals(obj); }

This method remains the same on the current 1.1.15 draft release.





[FACELETS-346] CSS rule in Facelets docs makes links barely clickable Created: 25/Feb/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: www
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: messi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh
URL: https://facelets.dev.java.net/nonav/docs/dev/docbook.html


Attachments: PNG File facelets-docs-overlapping-bug.png    
Issuezilla Id: 346

 Description   

https://facelets.dev.java.net/nonav/docs/dev/docbook.html

When using Firefox (3.x and 2.x, any OS) the links in the ToC are barely
clickable because of a rule in xhtml.css on line 68:

.sect1, .sect2, .sect3 {
padding-top: 10px;
}

The 10px padding area of the <span> overlaps with the above link area and hides
it almost completely.

It's only a small bug but it makes the use of the documentation a bit inconvenient.



 Comments   
Comment by messi [ 25/Feb/09 ]

Created an attachment (id=133)
Firefox with FireBug add-on shows the padding area that overlaps with the link area. On the right is the CSS rule in question.





[FACELETS-345] stack overflow if include/decorate src is null Created: 18/Feb/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: rogerkeays Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 345

 Description   

I noticed that the following code causes a StackOverflowError in facelets-1.1.14:

<ui:include src="$

{null}

"/>

while this code:

<ui:include src="invalid"/>

just produces a memory-friendly 404 error.

an empty string also produces a stack overflow:

<ui:include src=""/>






[FACELETS-344] \ as last character in attribute value causes ArrayIndexOutOfBoundsException Created: 05/Feb/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Minor
Reporter: russen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 344

 Description   

<img alt="\" src="top_right_corner.png/>

causes the follow exception:
java.lang.ArrayIndexOutOfBoundsException: 1
at com.sun.facelets.el.ELText.parse(ELText.java:319)
at com.sun.facelets.el.ELText.parse(ELText.java:282)
at com.sun.facelets.el.ELText.isLiteral(ELText.java:267)
at com.sun.facelets.tag.TagAttribute.<init>(TagAttribute.java:57)
at
com.sun.facelets.compiler.SAXCompiler$CompilationHandler.createAttributes(SAXCompiler.java:92)
at
com.sun.facelets.compiler.SAXCompiler$CompilationHandler.startElement(SAXCompiler.java:194)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at
com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:220)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDValidator.java:819)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:322)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:176)
at com.sun.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:232)
at com.sun.facelets.compiler.Compiler.compile(Compiler.java:105)
at
com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:197)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:144)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)






[FACELETS-343] template encoding and http content-type Created: 04/Feb/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: djeanprost Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 343

 Description   

There is actually a weird behaviour if both xhtml template and xhtml pages
mention a xml encoding and if these xml encoding are different. To reproduce,
just take the number guess demo :
1. Change template.xhtml and add the xml header : <?xml version="1.0"
encoding="iso-8859-1"?>, because I want to edit this file using the iso-8859-1
charset.
2. Change guess.xhtml and add the xml header : <?xml version="1.0"
encoding="iso-8859-15"?>, because this file contains the euro character (you
can add it or not in the page).

Now run the demo and hit the guess.jsf page. If you display source page, you
get the xhtml template xml header (which is <?xml version="1.0" encoding="iso-
8859-1), and if you inspect http header content-type, you get the xhtml guess
page encoding used as the content-type (iso-8859-15) : there is something weird
here, because http header content-type and xhtml page encoding do not say the
same thing. I think facelets should throw a warning or an error telling all of
the xml encoding of the template-page chains are not the same, and that it
could lead to inconsistent behaviour (which I met).
Thank you






[FACELETS-341] ui:debug does not encode URL Created: 06/Jan/09  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: skelvin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 341

 Description   

UIDebug.encodeBegin(FacesContext) uses ViewHandler.getActionURL():

String actionId = faces.getApplication().getViewHandler().getActionURL(faces,
faces.getViewRoot().getViewId());

and then directly renders the "actionId" (URL) as javascript.
However it should also encode the URL:
actionId = faces.getExternalContext().encodeActionURL(actionId);

If my app uses URL rewriting (i.e. Seam's builtin feature or using tuckey's
UrlRewriteFilter directly) the debug page no longers works, because it contains
wrong (not-rewritten) URLs.






[FACELETS-340] faces-config.xml: validation problem without an Internet connection. Created: 16/Nov/08  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: jmsanchez Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 340

 Description   

We have a problem with the facelets validation. When we start our application
without an internet connection we get this Exception:
java.net.UnknownHostException: java.sun.com
javax.faces.FacesException: java.net.UnknownHostException: java.sun.com.

The problem comes from the assignation to PUBLIC in the DOCTYPE validation, in
the header of the file faces-config.xml.

We wonder if it would be possible, in the next release, to assign the DOCTYPE to
SYSTEM and include the dtd within the library as recommended in the following
link the tomahawk library:

http://wiki.apache.org/myfaces/Installation_and_Configuration

Thx.



 Comments   
Comment by Ryan Lubke [ 22/Dec/08 ]

Facelets doesn't process the faces-config.xml. That's the responsibility of the
JSF runtime you're using. I would recommend logging an issue with them.

Comment by jmsanchez [ 29/Dec/08 ]

The owner of faces-config.xml is Facelets, so is responsability of Facelets to
change it.

Faces-config.xml should be changed to 'SYSTEM', so the validation will do in
local, without an Internet connection.

IMHO, It's not important who does the validation, if it is 'SYSTEM', an Internet
connection is not needed.





[FACELETS-335] ui:repeat input map value cannot be cleared Created: 21/Oct/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: deaves Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 335

 Description   

Under the following conditions a text input backed by a map value is unable to
set a null value into the map:

1. The input is within a ui:repeat
2. The input uses a converter that converts empty strings to null
3. The map value is initialised to a non-null value via a @PostConstruct method

With such a configuration I can change the value in the map to any other value,
but attempting to input empty string (which is converted to null) causes the
@PostConstruct default to be set into the map instead.

This seems to be due to HtmlInputText.getValue() (which is implemented by the
UIOutput ancestor class) re-evaluating the EL expression if the current value is
null, even if the local value has already been set.

This occurs with Facelets 1.1.14 and JSF 1.2_09. I have not tested with other
releases.

Following are some code snippets from a minimal example demonstrating this:

MapExampleBean.java:
package mapexample;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.annotation.PostConstruct;

public class MapExampleBean {
private Map<String, String> map = new HashMap<String, String>();

@PostConstruct
public void initialise()

{ map.put("One", "1"); }

public Map<String, String> getMap()

{ return map; }

public List<String> getMapKeys()

{ return new ArrayList<String>(map.keySet()); }

public void actionSubmit()

{ System.out.println("MapTest.actionSubmit() - map " + map); }

}

MyStringConverter:
package mapexample;

import javax.faces.component.UIComponent;
import javax.faces.component.html.HtmlInputText;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.ConverterException;

public class MyStringConverter
implements Converter
{
public Object getAsObject(FacesContext context, UIComponent component, String
value)
{
if (value == null || value.trim().length() == 0)

{ return null; }

return value;
}

public String getAsString(FacesContext context, UIComponent component, Object
value)
{
if (value == null)
{ return null; }

return value.toString();
}
}

mapExample:xhtml:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html">

<h:form id="form">
<ui:repeat id="repeat" value="#

{mapExample.mapKeys}

" var="key">
<h:inputText value="#

{mapExample.map[key]}

" converter="MyStringConverter" />
</ui:repeat>
<h:commandButton id="submit" value="Submit"
action="#

{mapExample.actionSubmit}

" />
</h:form>

</html>



 Comments   
Comment by deaves [ 21/Oct/08 ]

This issue has also been reported for the Mojarra project as I'm unsure where
the problem resides. See
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=819





[FACELETS-334] bad logging for load implicit message Created: 10/Oct/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: stenlee Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File patch.txt    
Issuezilla Id: 334

 Description   

issue 298 still not fixed in 1.1.15.b1 . Still lot of error messages appeared
in app. server logs.

09:14:09,150 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/jsf-facelets-1.1.15.B1.jar!/META-INF/jsf-core.taglib.xml
09:14:09,154 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/jsf-facelets-1.1.15.B1.jar!/META-INF/jsf-html.taglib.xml
09:14:09,157 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/jsf-facelets-1.1.15.B1.jar!/META-INF/jsf-ui.taglib.xml
09:14:09,164 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/jsf-facelets-1.1.15.B1.jar!/META-INF/jstl-core.taglib.xml
09:14:09,179 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/jsf-facelets-1.1.15.B1.jar!/META-INF/jstl-fn.taglib.xml
09:14:09,187 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/richfaces-ui-3.2.2.GA.jar!/META-INF/a4j.taglib.xml
09:14:09,191 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/richfaces-ui-3.2.2.GA.jar!/META-INF/ajax4jsf.taglib.xml
09:14:09,197 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/richfaces-ui-3.2.2.GA.jar!/META-INF/jsp.taglib.xml
09:14:09,211 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/richfaces-ui-3.2.2.GA.jar!/META-INF/rich.taglib.xml
09:14:09,217 ERROR [STDERR] Oct 10, 2008 9:14:09 AM
com.sun.facelets.compiler.TagLibraryConfig loadImplicit
INFO: Added Library from:
jar:file:/home/stenlee/Work/jboss-portal-2.6.6.GA/server/default/tmp/deploy/tmp3506wu-selfcare-all.ear-contents/lib/richfaces-ui-3.2.2.GA.jar!/META-INF/richfaces.taglib.xml



 Comments   
Comment by kukeltje [ 17/Dec/08 ]

Created an attachment (id=128)
Patch for this issue, corrects logging

Comment by fribeiro [ 19/Apr/11 ]

Any update yet?





[FACELETS-332] Don't trim whitespace in literal text Created: 21/Sep/08  Updated: 28/Feb/09

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: Ryan Lubke
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 332

 Description   

Facelets currently trims whitespace in literal text. As a result, if two JSF
components are separated by only whitespace, that whitespace is removed and the
two components bump up next to one another. The well-documented workaround is to
insert an EL value expression that resolves to a space to trick Facelets into
adding a space between components. This is a ridiculous hack and there is
absolutely no reason this whitespace should be trimmed. I would like to propose
that Facelets change its trimming policy. If necessary, you can add a legacy
flag to retain the old behavior (but I don't think it's necessary).

Here's the common workaround to produce JavaServer Faces:

<h:outputText value="JavaServer"/>
#

{' '}

<h:outputText value="Faces"/>

Another workaround is to use a non-breaking space (i.e., #&160, but this is
even more of a hack (and semantically wrong).

This issue can be solved by removing all the logic from the private method
com.sun.facelets.compiler.TextUnit#trimRight(String).



 Comments   
Comment by mojavelinux [ 28/Feb/09 ]

As Ryan pointed out, the problem with not trimming is that you end up creating
extra components that represent the whitespace in the tree. This is not a
problem when you would expect the whitespace (such as between two inline links)
but would be a problem if the components were children of a grid component.

I think the solution is to have a "trimming" setting per component. When you
register the component in the Facelets library, you mark whether whitespace is
to be trimmed or not from children. The default would be to not trim.
h:panelGrid, for example, would be set to trim.





[FACELETS-331] Facelets seems to not support the JSF 1.2 MethodExpression parameters Created: 19/Sep/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: jdebouil Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 331

 Description   

Using Woodstock components and Facelets, we cannot use validatorExpression,
actionExpression, actionListenerExpression...

May be the problem is in Facelets; that is, not supporting the JSF
1.2 APIs that return/consume MethodExpression parameters.






[FACELETS-330] Browser refreshes cause TagHandlers to be executed too many times Created: 17/Sep/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: sombrero83 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 330

 Description   

Multiple requests cause TagHandlers to be executed simultaneously several times
and therefore the rendered page is full of duplicated components. This happens
if the user performs a page refresh while a TagHandler apply() action is still
running. The consequence: The same TagHandler instance is used by another Tomcat
thread and apply() is invoked as many times as the user refreshes the page. All
the JSF components referenced in the TagHandlers are therefore added several
times to the component tree and the rendered page is totally deformed. This also
applies if the user clicks several times on a link to a Facelets-rendered page
if the response isn't yet generated.
We tried to solve this issue by holding a set of currently active tagIds for a
request: The current tagId is put into a session bean before apply() is invoked.
After the invocation, the tagId is removed. If the current tagId is already in
the Set, then the invocation of apply() is suppressed. Unfortunately this only
works with our own TagHandlers – Facelets-internal TagHandlers can't be adapted
because we cannot influence their apply() behaviour without using AOP.
Are there any other hints or ideas how to solve that? It would be great if
Facelets framework could handle that. Thread connection pooling cannot be turned
off in Tomcat for obvious reasons.
Thanks in advance!
Markus
Using Tomcat 6.0.16, JSF 1.2 Sun RI, Windows XP






[FACELETS-329] getAlternativeJarFile() problem for com.sun.facelets.util.Classpath Created: 09/Sep/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: sitan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 329

 Description   

When we deploy the hangman.war application to Borland AppServer 6.6(BAS), we get
the following exception:

2008-09-10 13:01:24,000 INFO - Sep 10, 2008 1:01:24 PM
com.sun.facelets.compiler.Compiler initialize
SEVERE: Compiler Initialization Error
java.util.zip.ZipException: The system cannot find the path specified
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:203)
at java.util.jar.JarFile.<init>(JarFile.java:132)
at java.util.jar.JarFile.<init>(JarFile.java:70)
at com.sun.facelets.util.Classpath.getAlternativeJarFile(Classpath.java:124)
at com.sun.facelets.util.Classpath.search(Classpath.java:67)
at
com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:428)
at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
at
com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:197)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:144)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:253)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:216)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:891)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:783)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:548)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

This is due to the path of a URL scanned by the com.sun.facelets.util.Classpath:

The URL scanned is
"besjar:C%3A/BAS6.6/var/domains/base/configurations/j2eeSample/mos/MyPartition/tmp/tmpbes_33163hangman.war/hangman.war!/META-INF/".
Therefore, in Classpath.getAlternativeJarFile (line 124),
the jarFileUrl would be derived as
"C:/BAS6.6/var/domains/base/configurations/j2eeSample/mos/MyPartition/tmp/tmpbes_33163hangman.war/hangman.war".

However, an exception (java.util.zip.ZipException: The system cannot find the
path specified) is thrown
because the jarFileUrl is pointing to a directory instead of a jar file. This is
because the war file has been expanded
and copied to that directory for BAS.

There is a comment(as indicated below) for the getAlternativeJarFile in the
Classpath.java source code which mentioned
that it does not cater for unpack WAR or EAR. Would this be implemented in the
later release?

Since it seems that the URLs returned by different AppServers can cause problems
for the getAlternativeJarFile method,
would it be possible to provide some kind of extension such that other users can
write classes to override the default
implementation of the search mechanism implemented by the Classpath source code,
rather than changing it. Just a suggestion.

/** For URLs to JARs that do not use JarURLConnection - allowed by

  • the servlet spec - attempt to produce a JarFile object all the same.
  • Known servlet engines that function like this include Weblogic
  • and OC4J.
  • This is not a full solution, since an unpacked WAR or EAR will not
  • have JAR "files" as such.
    */





[FACELETS-327] README.txt outdated (asks to download libs) Created: 20/Aug/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: UNKNOWN
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: jlaskowski Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 327

 Description   

In README.txt there's a section "Building Facelets" in which points 1 and 2 are
outdated and should be removed as the libs are downloaded during build.






[FACELETS-326] Avoid UIRepeat calling getValue() when rendered is false. Created: 05/Aug/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: adrianpj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 326

 Description   

UIRepeat is calling getValue() for child components even if the child is not
rendered. If the child value expression is not valid JSF/EL will throw an
exception.

When handling heterogeneous objects (i.e. objects of different classes) in an
<ui:repeat/> I try to use "rendered" on child components to avoid invalid
expression evaluation.

<ui:repeat value="#

{bean.mixedObjects}

" var="object">

<h:panelGroup rendered="#

{object.class.name EQ 'A'}

">
...
<h:inputText value="#

{object.fieldA}

"/>
...
</h:panelGRoup>

<h:panelGroup rendered="#

{object.class.name EQ 'B'}

">
...
<h:inputText value="#

{object.fieldB}

"/>
...
</h:panelGroup>

</ui:repeat>

In this example, fieldB is not present in class A and fieldA is not present in
class B.

The call to getValue() is located in UIRepeat.populate() when saving child state.

UIRepeat.saveChildState() should propagate "rendered status" and avoid calling
getValue() in populate() if child component is not rendered and assign "null".



 Comments   
Comment by adrianpj [ 05/Aug/08 ]

This guy seems to have the same scenario:

http://mail-archives.apache.org/mod_mbox/myfaces-users/200607.mbox/%3c20060725122000.F16D210FB001@asf.osuosl.org%3e





[FACELETS-325] No new variable mapper is created if no attributes are given to a UserTag Created: 26/Jul/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: nidi Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 325

 Description   

No new variable mapper is created if no attributes are given to a UserTag.

When inside the user tag a variable is set using c:set, it is set in the
enclosing scope and the calling template sees a variable set in the inner tag.

This can be avoided removing the following if statement in UserTagHandler:

public void apply(FaceletContext ctx, UIComponent parent) throws IOException,
FacesException, FaceletException,
ELException {
VariableMapper orig = ctx.getVariableMapper();

// setup a variable map
if (this.vars.length > 0) { <--- ******** remove this if ************
VariableMapper varMapper = new VariableMapperWrapper(orig);
for (int i = 0; i < this.vars.length; i++)

{ varMapper.setVariable(this.vars[i].getLocalName(), this.vars[i].getValueExpression(ctx, Object.class)); }

ctx.setVariableMapper(varMapper);
}






[FACELETS-322] XML Validation Error with Firefox2 only Created: 06/Jul/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: fischaman Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 322

 Description   

With the newest versions of Facelets (1.1.14), Richfaces (3.2.1) and JSF Mojarra
(1.2 08) you get an XML-Validation-Error only under Firefox2 when rendering a
page with HTML-Entities. You can take every doctype you want, the error occurs
everytime, but only with Firefox2 (not 3).



 Comments   
Comment by fischaman [ 15/Dec/08 ]

Documenttype Definition set to transitional instead of strict.... now the
problem is gone...





[FACELETS-320] doc build using JDK5 throws TransformerConfigurationException Created: 05/Jun/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: balunasj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 320

 Description   

"ant doc" with JDK 1.5 has an issue related to xsl style sheet processing

There may be a way to work around this without requiring the steps below.
Perhaps breaking the style sheet into sections, or using a different doc book
command/versions.

To work around this you need to download xalan-j_2_7_1 as mentioned in
"XALANJ-2318"

  • Copy the following jars from the xalan 2.7.1 to
    your "$ANT_HOME/lib" directory
  • xercesimpl.jar
  • xml-apis.jar
  • xalan.jar
  • serializer.jar





[FACELETS-319] portlet example requires portlet.jar and myfaces-all.jar which breaks the release build Created: 05/Jun/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: demo
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: balunasj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 319

 Description   

The portlet example is built during the release build. Because the portlet
example requires the portlet.jar and myfaces-all.jar the build fails. The work
around is to copy these jars from a previous facelets release.

Suggests:

  • Do not build and include the portlet.war in the distribution. Provide a
    readme.txt in the example that describes what is needed to build it.
  • Or include/download the jars like the other required jars during the build
    process.





[FACELETS-318] Document release process including building documentation Created: 05/Jun/08  Updated: 05/Jun/08

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: balunasj Assignee: youngm
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File release-process.txt    
Issuezilla Id: 318

 Description   

There are really no documented steps to generate a release.

There is also some tricks to getting the documentation and portlet example to build.



 Comments   
Comment by balunasj [ 05/Jun/08 ]

Created an attachment (id=123)
Writeup of steps required for building the release





[FACELETS-317] Component value expressions being cached Created: 05/Jun/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: bcoolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 317

 Description   

ComponentHandler calls "this.setAttributes(ctx, c)" only when the component
hasn't been created. This makes sense in most situations, but I've found a case
where this causes problems. I have a wizard the uses <ui:include
src="#

{SomeBean.src}

" />. That is, the bean returns the current page for the
wizard. Some of the wizard pages are using a common template and they each
provide a param to the template. When navigating through the wizard it
"appears" as though the param values are being cached from one page to the next.
After a lot of debugging the problem boils down to the ValueExpressions on the
components not being reset/updated (i.e. setAttributes() is not being called on
components that already exist).

The following is some simple code to produce the problem:

page.xml:

<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:a4j="http://richfaces.org/a4j" xmlns:f="http://java.sun.com/jsf/core">
<html>
<body>
<ui:include src="#

{PageBean.includeSrc}

.xml" />
<h:form>
<h:commandButton value="Switch"
action="#

{PageBean.updateIncludeSrc}

" />
</h:form>
</body>
</html>
</ui:composition>

template.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:outputText value="#

{myParam}

" />
</ui:composition>

include1.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core" template="template.xml">
<ui:param name="myParam" value="value1" />
</ui:composition>

include2.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core" template="template.xml">
<ui:param name="myParam" value="value2" />
</ui:composition>

PageBean (session scoped):

import java.io.Serializable;

// TODO Delete me
public class PageBean implements Serializable
{
private static final long serialVersionUID = -4793351076515412393L;

// The name of the first include file
private static final String INCLUDE1 = "include1";

// The name of the second include file
private static final String INCLUDE2 = "include2";

private String includeSrc = INCLUDE1;

public String getIncludeSrc()

{ return includeSrc; }

public String updateIncludeSrc()

{ // Switch the include src includeSrc = INCLUDE1.equals(includeSrc) ? INCLUDE2 : INCLUDE1; return null; }

}

This example will have one output text and one button. The first visit to the
page will display "value1". Clicking the button should alternate the text from
"value1" to "value2", but it doesn't.

I modified the source for ComponentHandler and added a call to
setAttributes(ctx, c) for components that already exists and it fixes this problem.






[FACELETS-316] DevTools.writeAttributes does wrong null check Created: 29/May/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: gstacey Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 316

 Description   

DevTools line 240 and 241...
if (pd[i].getWriteMethod() != null && Arrays.binarySearch(IGNORE,
pd[i].getName()) < 0) {
m = pd[i].getReadMethod();
...

Shouldn't that check on line 240 be
if (pd[i].getReadMethod()
since you call getReadMethod not getWriteMethod? It's minor since the method
eats the exception, but it would be a lot cleaner to not generate the NPE in the
first place.






[FACELETS-313] ValidateHandler / ConvertHandler need to process inner tags Created: 05/May/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: jctsay Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 313

 Description   

In Shale Commons Validator, there is a validator that is used like this:

<val:commonsValidator ...>
<val:validatorVar name="minlength" value="4" />
</val:commonsValidator>

The <val:validatorVar> provides an argument for the validator, similar to an
attribute or facet.

This doesn't work when I made the approprioate TagHandler's for commonsValidator
and validatorVar.

com.sun.facelets.tag.jsf.Validator handler's apply() method looks like this:

public final void apply(FaceletContext ctx, UIComponent parent)
throws IOException, FacesException, FaceletException, ELException {

if (parent == null || !(parent instanceof EditableValueHolder))

{ throw new TagException(this.tag, "Parent not an instance of EditableValueHolder: " + parent); }

// only process if it's been created
if (parent.getParent() == null) {
// cast to a ValueHolder
EditableValueHolder evh = (EditableValueHolder) parent;
ValueExpression ve = null;
Validator v = null;
if (this.binding != null)

{ ve = this.binding.getValueExpression(ctx, Validator.class); v = (Validator) ve.getValue(ctx); }

if (v == null) {
v = this.createValidator(ctx);
if (ve != null)

{ ve.setValue(ctx, v); }

}
if (v == null)

{ throw new TagException(this.tag, "No Validator was created"); }

this.setAttributes(ctx, v);
evh.addValidator(v);

}

}

Since the nextHandler is never applied it appears all child tags of the
validator will be ignored. In my case the TagHandler for val:validatorVar didn't
seem to be invoked. Unfortunately, apply() is a final method so this behavior
cannot be overridden in a subclass that handles the commonsValidator tag. The
solution, which I have found to work, is to add

nextHandler.apply(ctx, parent);

right after

evh.addValidator(v);

The tag handler for val:validateVar can then get the parent UIComponent's
validators, get at the last one, then modify the validator's configuration.
This works after the above change.

For completeness, I should mention that ConvertHandler probably has the same
problem. I am not too sure where to apply the next handler, here is my guess:

this.setAttributes(ctx, c);
vh.setConverter(c);

// Added here!!
nextHandler.apply(ctx, parent);

Object lv = vh.getLocalValue();
FacesContext faces = ctx.getFacesContext();
if (lv instanceof String)

{ vh.setValue(c.getAsObject(faces, parent, (String) lv)); }

Right now Shale Commons Validator doesn't use any child tags for converters, but
it's possible that some other tag library might, so the ConvertHandler should
probably be fixed for completeness.






[FACELETS-311] Tomahawk support Created: 24/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: glar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 311

 Description   

Hi,

i tryed tomahawk and facelets with myfaces 1.1.5, the most things work well.
But the sorting of t:dataTable do not work. The cause was the sorting boolean
attribute was not change after submit the form.

Thanks
glar






[FACELETS-310] DevTools swallows exceptions Created: 23/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: gstacey Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File DevTools.java     HTML File patch    
Issuezilla Id: 310

 Description   

The DevTools writeAttributes method swallows exceptions and continues to the
next attribute. Should'nt these be passed up to the framework to redirect /
deal with?



 Comments   
Comment by irobertson [ 19/Jul/08 ]

Created an attachment (id=124)
This patch will log the swallowed exceptions to the facelets.util logger at level WARN

Comment by jkronegg [ 05/Aug/08 ]

Created an attachment (id=125)
Instead of just doing a log.warn, the invoke method should be robust to m==null and should throw exception (otherwise computed values done by beans are near to impossible to debug in case of error). This attachment could be a good basis (it's not perfect: only a quickfix)





[FACELETS-309] Caching components Created: 22/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.13
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: jarrod Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 309

 Description   

Investigate a caching concept for facelets similar to what has been implemented
for JBoss Seam (<s:cache) and Oracle ADF. This component could plug into a
cache or global context like OSCache or the servlet containers application
context.

Note: This work may be more appropriate to be completed as part of the JSF
implementation being used (MyFaces or Sun RI), similar to JBoss/Oracle, but I
thought I'd throw it out there for the community to decide.

Regards,
Jarrod






[FACELETS-308] Some Issues with forEach tag Created: 18/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: sxnguyen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 308

 Description   

1. forEach can't handle value greater than 127

If I have a simple iteration loop like below:

<c:forEach begin="0" end="256" var="i">
<h:outputText value="#

{i}

"/>
</c:forEach>

It will output 0 1 ... 127 -128 -127 ... -1 0.

Need to have something that will allow a number greater than 127.

2. I've run into null pointer exception when using the forEach in conjunction
with RichFaces tab panel. The begin and end attributes were set up correctly
and they weren't null. (I think the bean has not been created in the non active
tab but for some reasons, the code in the for each tag was called even in this
non active tab so a null pointer occurs.)

It happens at the TagAttribute.getInt(FacesContext), this line
((Number) this.getObject(ctx, Number.class)).intValue();






[FACELETS-307] Incorrect behaviour when referencing a not existing template within a composition Created: 11/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.11
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: djeanprost Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 307

 Description   

I've just noticed that if I use a incorrect template reference within a
ui:composition, I get a 404 instead of having an explicit exception in my log
file. How could I get a cool exception in my log file telling me this file does
not exists ?

<ui:composition template="this/file/doesnot/exist.xhtml">

blabla

</ui:composition>






[FACELETS-305] Method binding for a custom facelet component not working by itself Created: 09/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: www
Affects Version/s: UNKNOWN
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: sureshtl Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 305

 Description   

hi
i use the facelets 1.0.14 and i am trying to create a custom component. In
facelets the ValueBinding for attributes works automatically but the
MethodBinding is not working automatically.

One work around approach for this is to extend the Facelets Tag handler and do
the method binding manually.
Do we still have to do this way ? Or is it fixed in the latest release of
facelets ?






[FACELETS-304] Logic error in ELText.java Created: 01/Apr/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.2_03
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: jeffparsons Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 304

 Description   

src/java/com/sun/facelets/el/ELText.java contains this line:

if (esc && i < end && ca[i+1] == '$' || ca[i+1] == '#') {

I believe this should read:

if (esc && i < end && (ca[i+1] == '$' || ca[i+1] == '#')) {

Sorry if a formal patch was expected; this is my first bug report against
Facelets, and I thought a formal patch would be more trouble than it's worth for
this small issue.






[FACELETS-303] ComponentSupport.markForDeletion() not marking all components that need to be deleted Created: 20/Mar/08  Updated: 20/Mar/08

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.13
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: Neil Griffin Assignee: Ryan Lubke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 303

 Description   

In ComponentSupport.java, on or about line 220 you'll see this code:

if (cc.getAttributes().containsKey(MARK_CREATED))

{ cc.getAttributes().put(MARK_DELETED, Boolean.TRUE); }

There needs to be a negation in the if statement, using an exclamation point,
like this:

if (!cc.getAttributes().containsKey(MARK_CREATED)) { cc.getAttributes().put(MARK_DELETED, Boolean.TRUE); }

I ran into this with the sample-jsf-1.2-sun-facelets-portlet that is meant for
use with Liferay Portal. When I placed a the portlet on portal-page-A, then
clicked on portal-page-B and then clicked back on portal-page-A, I would see
duplicate HTML rendered on UIInstruction components which contained simple HTML
markup.

Anyways if you look at the Java code above, and try to "read it out loud" as
English, you'll see that the negation was left out by accident.

I'm going to include a patched jsf-facelets.jar in the Liferay sample portlets
for now, until y'all are able to get this patch incorporated into the 1.1.14
version.

Regards,

Neil Griffin
Liferay, Inc.






[FACELETS-301] new feature <ui:catch> needed for catching DB failures in EL when <c:catch> doesn't Created: 29/Feb/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: New Feature Priority: Major
Reporter: arhak Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 301

 Description   

I think there would be great to have a new tag named <ui:catch> with the same
functionality of <c:catch> plus ELException handling instead of showing debug
window.
If I have something like
<h:dataTable value="#

{bean.names}

" var="name">
<h:column>#

{name}

</...>
</...>
and the method getNames() is dependant of a DB connection that could be
unavailable, then an ELException might be thrown and not catched even if
surrownded by a <c:catch>
This is very anoying when using A4J/JSF/RichFaces when a part of a page might
crash an the rest of the page could be visualized just fine, showing the
affected part like some alternativelly render.
It might be even better a sort of <ui:try>-<ui:catch> with the Java exception
handling philosophy, that might be implemented the same way as <c:when>-
<c:otherwise> but with respect an Exception, a Throwable much better, to take
even java.lang.OutOfMemory into account, wich would be an evident bug in the
Java classes but it steel no reason for makin a whole page unavailable in the
old non-ajaxed, non-framed, non-templated fashion.
A whole page composed by templated should support Error Handling like try-
catch, because a nested template could be written by someone (untrustable) else.
So, if a very nested template fails with a Throwable, there would be a lot of
page just rendered as well as nothing happened, but with a replacement of the
failed template saying "This feature is temporally unavailable" or something
like it.
I hope you share this feeling...
PS: great work!, keep going, my bests to you






[FACELETS-300] Include FaceletPortletViewHandler in jsf-portlet.jar Created: 20/Feb/08  Updated: 20/Feb/08

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: Ryan Lubke
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 300

 Description   

This is an enhancement request to compile FaceletPortletViewHandler.java and
include it in binary distributions of jsf-portlet.jar by default.






[FACELETS-297] facelets.DEVELOPMENT always "true" Created: 19/Feb/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.13
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: inturico Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://doodle.ch/


Issuezilla Id: 297

 Description   

Facelets can be used in DEVELOPMENT mode by setting the facelets.DEVELOPMENT
parameter to "true" (i.e.,
<context-param><param-name>facelets.DEVELOPMENT</param-name><param-value>true</param-value></context-param>
in web.xml).

In combination with MyFaces 1.2.0 and earlier, DEVELOPMENT mode can be enabled
and disabled as expected.

In combination with MyFaces 1.2.2, DEVELOPMENT mode is always enabled,
independent of the facelets.DEVELOPMENT parameter being "true" or "false".






[FACELETS-295] Default body of insert overrides defined content Created: 17/Feb/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File test.patch     File test.tar    
Issuezilla Id: 295

 Description   

There has been a lot of work done over how default facelet context should
include definitions <https://facelets.dev.java.net/issues/show_bug.cgi?id=234>
but I'm afraid I found still one failing use case.

Use case where default body of insert overrides defined content only happens
using include because composition and define always define at least empty
content. But when using inclusion either programmatically or using the tag there
will not be applied any template client semantics.



 Comments   
Comment by tuomas_kiviaho [ 17/Feb/08 ]

Created an attachment (id=112)
test case

Comment by tuomas_kiviaho [ 17/Feb/08 ]

..composition and define.. should be composition and declare.

Comment by tuomas_kiviaho [ 17/Feb/08 ]

By reversing the order of including definitions for inserts this use case can be
fixed hopefully without impacting internal behaviour of facelets.

For this to work the composition tag must be identical compared to declare. In
other words all template clients would be pushed instead of extended except
inserts which are processed still after others but in reverse order.

Comment by tuomas_kiviaho [ 17/Feb/08 ]

Created an attachment (id=113)
test case patch

Comment by tuomas_kiviaho [ 17/Feb/08 ]

The patch is proved to fix (at least) the test case. Pushing and extending still
resemble queue as before but the processing is split in half instead of
overstepping. Using of template manager root as split marker is just for
minimizing the patch.





[FACELETS-291] ui:include tags are not working from 1.1.13 version. Created: 20/Jan/08  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: jsf
Affects Version/s: 1.1.13
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: amardeep_talwar Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 291

 Description   

ui:include tags are not working from 1.1.13 version.



 Comments   
Comment by jhook [ 20/Jan/08 ]

you need to be more specific

Comment by amardeep_talwar [ 21/Jan/08 ]

The following tag is not including the src directory from 1.1.13 version
onwards.
<ui:insert id="leftnavvar" name="page-leftnav-var">
<ui:include id="layout_leftnavvar_include"
src="/layout/page_leftnav_default_var.xhtml">
</ui:include>
</ui:insert>





[FACELETS-289] Getting the unit tests running Created: 14/Jan/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.13
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: jandockx Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 289

 Description   

I just did a checkout of the source, and I am a bit surprised that I can't get the unit tests running quickly.
We need to add a test target in the ant build script for sure? Secondly, something weird is going on in
FaceletTestCase, line 164. This method ( protected void initFacesListener(ServletContext context)) fails
when trying unit tests in eclipse. I can't get it to work with the provided Sun RI 1.2, nor with a downloaded
myfaces. Some documentation is in order.






[FACELETS-288] As of Issue 199 ./. relative Path on CSS also does not work Created: 11/Jan/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: frankzinner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 288

 Description   

Hi, I have problems on using relative path in css-styles included in the
template-master.xhtml e.g. (defined in css extern or intern):

.image {
background-image:url(/images/example.jpg);
}

The images and css styles will appear the first time the page is loaded but will
lose the css images on the next pages!






[FACELETS-287] Requestion fails silently when any composition template parameter is invalid Created: 10/Jan/08  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: gcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 287

 Description   

Searching through the sources, I found what I think is the cause of one of our
most frustrating issues with facelets: an entire request fails silently when any
composition in the tree has an invalid template parameter.

It is difficult to deal with because you have to test all of the compositions
referenced within a call to find the one that's actually invalid.

As far as I can tell it's happening within the
CompositionHandler.apply(FaceletContext, UIComponent) call, where the try
doesn't have a catch:

try {
ctx.includeFacelet(parent, this.template.getValue(ctx));
} finally {
ctx.popClient(this);
ctx.setVariableMapper(orig);
}

I am not familiar enough with the code base to know for certain, but I can't
think of any reason why a composition should fail silently when the
includeFacelet call throws an exception.

I (humbly of course suggest, based on my limited familiarity, that:

1. An an error should be logged that clearly specifies the cause

2. A more specific exception should be re-thrown

3. Documentation should be updated to suggest ways the exception could be caught
and handled in an application-specific way higher up the stack

4. Major projects utilizing facelets, such as Seam, should be notified about the
best way to default to handling and documenting the exception case

And of course, in closing, I'm fairly certain I'm missing something completely
obvious, so apologies in advance if I'm just being dense.






[FACELETS-286] Custom resource resolver (from JAR) leads to many: flushing component applied Created: 21/Dec/07  Updated: 31/Jul/08

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Bug Priority: Critical
Reporter: Daniel Lichtenberger Assignee: rogerk
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jar_url_timestamp.patch    
Issuezilla Id: 286

 Description   

As described in the users mailinglist thread "Custom resource resolver (from
JAR) leads to many: flushing component applied" [1], as of Facelets 1.1.14
resources served from a JAR file are never cached, because the JarURLConnection
returned for a JAR file entry returns no modification date (it is always 0).
This leads to performance and also functionality issues.

The author's patch seems to work (he gets the modification date from the JAR
file connection instead of the JAR file entry), so it would be nice to include
it in Facelets CVS - otherwise classpath resource resolvers don't really work
with Facelets 1.1.14. I'll attach a patch against the latest Facelets CVS. I'm
not very familiar with the java.net.URL stuff, so you might want to double-check
that the connection resources are properly released.

[1] https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=8576



 Comments   
Comment by Daniel Lichtenberger [ 21/Dec/07 ]

Created an attachment (id=108)
Getting correct timestamps for resources served from a JAR file

Comment by Ryan Lubke [ 29/Jan/08 ]

Assigning to Roger.

Comment by elponderador [ 31/Jul/08 ]

In reality, I am not familiar at all with any jar hot loading environment... in
other words, if the resource is in a jar, could it really ever be refreshed
without the web application being redeployed.... if not this would work wihtout
the cost of even opening any connection object:

long ttl = facelet.getCreateTime() + this.refreshPeriod;
if (System.currentTimeMillis() > ttl) {
InputStream is;
try

{ URL url = facelet.getSource(); if ("jar".equalsIgnoreCase(url.getProtocol())) return false; long atl = url.openConnection().getLastModified(); return atl == 0 || atl > ttl; }

catch (Exception e)

{ throw new FaceletException("Error Checking Last Modified for " + facelet.getAlias(), e); }

}





[FACELETS-285] SKIP_COMMENTS web.xml default value does not work Created: 21/Dec/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.12
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: grzegorz_oledzki Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 285

 Description   

(not quite sure, if the subcomponent is the right one, sorry)
https://facelets.dev.java.net/nonav/docs/dev/docbook.html#config-webapp-init
claims that the default value for SKIP_COMMENTS is "true".

Without having any value specified, the comments are copied to the output sent
to the browser. And what's worse - the EL expressions without comments are
evaluated.

+++++ cat web.xml | grep -2 facelets
<context-param>
<param-name>facelets.LIBRARIES</param-name>
<param-value>
/WEB-INF/ourfirst.taglib.xml;
/WEB-INF/oursecond.taglib.xml
</param-value>
</context-param>
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>facelets.REFRESH_PERIOD</param-name>
<param-value>2</param-value>
</context-param>






[FACELETS-283] Documentationâ€� - Using Dynamic Faces with Facelets Created: 13/Dec/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: www
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: javanet_user Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 283

 Description   

Hello,

I have used Dynamic Faces (RC4) with JSP with success. I have also used
facelets with JSF 1.2.
But when I tried to use Dynamic Faces with Facelets (facelets-1.1.13), I'm
running into issues. I have searched the web for documentation.

Can a document/article be added to describe integration of Dynamic Faces with
Facelets ?

Thank You.






[FACELETS-279] Workaround for OC4J buggy classloader Created: 20/Nov/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Task Priority: Major
Reporter: osvetlik Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File exception.txt     Text File oc4j.diff    
Issuezilla Id: 279

 Description   

This bug occures in Oracle Containers for J2EE 10g (10.1.3.3.0).

We have a taglib.xml in a jar file and it references other files from the same
jar. Let's have an example:

<?xml version="1.0"?>
<!DOCTYPE facelet-taglib PUBLIC "-//Sun Microsystems, Inc.//DTD Facelet Taglib
1.0//EN" "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">
<facelet-taglib>
<namespace>http://example.com/some/namespace</namespace>
<tag>
<tag-name>example</tag-name>
<source>/some/path/example.xhtml</source>
</tag>
</facelet-taglib>

When facelets parse the taglib, it uses this line:

URL url = new URL(this.source, path);

to get the url for /some/path/example.xhtml in the context of the taglib.xml file.

In tomcat this.source would look like:

jar:file:/path/to/jar.jar!/META-INF/taglib.xml

and the new one:

jar:file:/path/to/jar.jar!/some/path/example.xhtml

But, OC4J has it's own protocol called code-source and it's own buggy URL
handler called SharedCodeSourceURL.

So the first url looks like:

code-source:/path/to/jar.jar!/META-INF/taglib.xml

and the second one:

code-source:/some/path/example.xhtml

and when it comes to opening the file referenced by the second URL, an exception
is raised:

java.io.IOException: code-source:/some/path/example.xhtml has no "!/<path>"
suffix so does not name a path within the code-source.
at
oracle.classloader.SharedCodeSourceSet.getResourceStream(SharedCodeSourceSet.java:505)
at
oracle.classloader.SharedCodeSourceURL$Connection.getInputStream(SharedCodeSourceURL.java:107)
at java.net.URL.openStream(URL.java:1009)
at com.sun.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:227)
...



 Comments   
Comment by osvetlik [ 20/Nov/07 ]

Created an attachment (id=105)
The full exception/callstack text

Comment by osvetlik [ 20/Nov/07 ]

Created an attachment (id=106)
Patch that is not really perfect but fixes the problem

Comment by haycom [ 26/May/11 ]

hi, i have some problem related to this issue.
how can i solve it?

Comment by osvetlik [ 27/May/11 ]

I don't think the patch will ever make it to the official source so you'll have to download the source codes of facelets, apply the patch to them, build your own jar file and use it instead of the official one.

I hope this is what you were looking for, you should provide more information when looking for help. Especially when this bug comes from 2007, it's been a while .





[FACELETS-273] Unable to pass custom converter name to a composition facelet component Created: 02/Nov/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.11
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File Facelets-273.patch    
Issuezilla Id: 273

 Description   

I have some ICEfaces markup that looks like this:

<ice:column>
<f:facet name="header">
<ice:outputText value="Foo" />
</f:facet>
<ice:outputText converter="fooIdConverter" value="#

{MyBean.columns ['fooId']}" />
</ice:column>

I turned this into a Facelet composite component named column.xhtml like this:

<ui:composition>
<ice:column>
<f:facet name="header">
<ice:outputText value="#{columnTitle}" />
</f:facet>
<ice:outputText converter="#{columnConverter}" value="#{columnValue}" />
</ice:column>
</ui:composition>

Now, when I do this:

<myice:column columnConverter="fooIdConverter" columnTitle="Foo" columnValue="#{MyBean.columns['fooId']}

" />

I get this error in the browser:

java.lang.IllegalArgumentException: Cannot convert fooIdConverter of type class
java.lang.String to interface javax.faces.convert.Converter
com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:329)
com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
com.sun.facelets.el.TagValueExpression.getValue
(TagValueExpression.java:71)
com.sun.facelets.el.LegacyValueBinding.getValue
(LegacyValueBinding.java:56)
javax.faces.component.UIOutput.getConverter(UIOutput.java:117)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.converterGet
AsString(DomBasicRenderer.java:211)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.formatCompon
entValue(DomBasicRenderer.java:195)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.getValue
(DomBasicRenderer.java:156)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeEnd
(DomBasicRenderer.java:128)
javax.faces.component.UIComponentBase.encodeEnd
(UIComponentBase.java:720)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParent
AndChildren(DomBasicRenderer.java:384)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParent
AndChildren(DomBasicRenderer.java:380)
com.icesoft.faces.component.ext.renderkit.TableRenderer.encodeChildren
(TableRenderer.java:474)
javax.faces.component.UIComponentBase.encodeChildren
(UIComponentBase.java:701)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParent
AndChildren(DomBasicRenderer.java:374)
com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren
(GroupRenderer.java:92)
javax.faces.component.UIComponentBase.encodeChildren
(UIComponentBase.java:701)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParent
AndChildren(DomBasicRenderer.java:374)
com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren
(GroupRenderer.java:92)
javax.faces.component.UIComponentBase.encodeChildren
(UIComponentBase.java:701)
com.icesoft.faces.component.util.CustomComponentUtils.renderChild
(CustomComponentUtils.java:339)
com.icesoft.faces.component.paneltabset.PanelTabSetRenderer.writeTabCell
(PanelTabSetRenderer.java:913)
com.icesoft.faces.component.paneltabset.PanelTabSetRenderer.encodeEnd
(PanelTabSetRenderer.java:410)
javax.faces.component.UIComponentBase.encodeEnd
(UIComponentBase.java:720)
com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParent
AndChildren(DomBasicRenderer.java:384)
com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren
(GroupRenderer.java:92)
javax.faces.component.UIComponentBase.encodeChildren
(UIComponentBase.java:701)
com.icesoft.faces.application.D2DViewHandler.renderResponse
(D2DViewHandler.java:581)
com.icesoft.faces.application.D2DViewHandler.renderResponse
(D2DViewHandler.java:585)
com.icesoft.faces.application.D2DViewHandler.renderResponse
(D2DViewHandler.java:585)
com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse
(D2DFaceletViewHandler.java:320)
com.icesoft.faces.application.D2DViewHandler.renderView
(D2DViewHandler.java:152)
com.sun.faces.lifecycle.RenderResponsePhase.execute
(RenderResponsePhase.java:87)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.renderCyclePartial
(ReceiveSendUpdates.java:69)
com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.service
(ReceiveSendUpdates.java:43)
com.icesoft.faces.webapp.http.core.IDVerifier.service
(IDVerifier.java:25)
com.icesoft.faces.webapp.http.core.ViewBoundServer.service
(ViewBoundServer.java:52)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Match
er.serviceOnMatch(PathDispatcherServer.java:50)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.servi
ce(PathDispatcherServer.java:19)
com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.serv
ice(ThreadBlockingAdaptingServlet.java:19)
com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service
(EnvironmentAdaptingServlet.java:29)
com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service
(MainSessionBoundServlet.java:117)
com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service
(SessionDispatcher.java:36)
com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMa
tch(PathDispatcher.java:52)
com.icesoft.faces.webapp.http.servlet.PathDispatcher.service
(PathDispatcher.java:29)
com.icesoft.faces.webapp.http.servlet.MainServlet.service
(MainServlet.java:76)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service
(BlockingServlet.java:54)



 Comments   
Comment by Ryan Lubke [ 20/Feb/08 ]

Created an attachment (id=115)
Possible fix

Comment by Ryan Lubke [ 20/Feb/08 ]

This is an ugly one.

Here's the break down:

GIVEN: columnConverter="fooIdConverter"

This reates a literal ValueExpression. Because this maps to a
ui:composition, this VE is stored in the FaceletContext
VariableMapper so that the expression #

{columnConverter}
is encountered, it maps back to the original VE 'fooIdConverter'.

However, because #{columnConverter}

isn't a literal expression,
ValueHolderRule.applyRule() will create a DynamicConveterMetaData
which ultimately create a ValueExpression for #

{columnConverter} that
must yield a Converter. This code path is what causes the exception.
#{columnConverter}

is evaluated expecting Converter, but the variable
mapped expression 'fooIdConverter' is evaluated in the process and returns
String.

So in short, the 'fix' is to do something like this:

if ("converter".equals(name)) {
// It could be that the value for this converter is mapped
// via VariableMapper meaning the original expression could
// be a literal. We have to check for this now in order to
// create the correct ConverterMetaData otherwise an error
// will occur during evaluation.
VariableMapper mapper = ctx.getVariableMapper();
String val = attribute.getValue();
val = val.substring(2, val.length() - 1);
ValueExpression mapped = mapper.resolveVariable(val);
if (mapped != null && mapped.isLiteralText())

{ return new LiteralConverterMetadata(mapped.getExpressionString()); }

else if (attribute.isLiteral())

{ return new LiteralConverterMetadata(attribute.getValue()); }

else {
if (FacesAPI.getComponentVersion(meta.getTargetClass()) >= 12)

{ return new DynamicConverterMetadata2(attribute); }

else

{ return new DynamicConverterMetadata(attribute); }

}
}
-------------------------------------------------

Basically, check the VariableMapper for a mapped reference.
If one is found, and it's a literal expression use the expression String
to create a LiteralConverterMetaData, if not, then back to the old
logic.

Hopefully this rambling made sense (it's 1:48am)





[FACELETS-268] Is there a need for a ui:if tag? Created: 16/Oct/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.14
Fix Version/s: 1.1.15

Type: Improvement Priority: Major
Reporter: hanafey Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 268

 Description   

I have a classic template that includes a header, side menu, and body, with the
small wrinkle that the side menu can optionally include a top section.

Initially I tried to do this with JSTL "if":

<c:if test="#

{not mainToolBar.upperEmpty}

">
<ui:include src="#

{mainToolBar.upperSideBarPath}"/>
<div class="menu_separator"> </div>
</c:if>

but this did not work (the body of the if always executes).

So instead I used "ui:repeat", where the backing bean value is either null or a
generic object to give the effect of an "if":

<ui:repeat var="notUsed" value="#{mainToolBar.upper}">
<ui:include src="#{mainToolBar.upperSideBarPath}

"/>
<div class="menu_separator"> </div>
</ui:repeat>

This works.

If "c:if" does not work in a template, it seems that a "ui:if" in facelets is
both easy to implement and useful. Admittedly I am new to facelets, and so have
the uneasy feeling that maybe I am missing something fundamental...






[FACELETS-266] Cannot use method binding in custom components and tags Created: 10/Oct/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: alexanderibelov Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 266

 Description   

It is impossible to use method binding in tag files and component files (I mean
components, created in *.xhtml files). Facelets are looking for ValueExpression
and cannot found set- and get- methods.



 Comments   
Comment by youngm [ 10/Oct/07 ]

I believe this is by design. For a work around look here:

http://andrewfacelets.blogspot.com/2006/06/creating-composite-controls-with-jsf.html





[FACELETS-265] Faster reflection for EL functions for better performance Created: 09/Oct/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: 1.1.15

Type: Bug Priority: Major
Reporter: mgrouch Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 265

 Description   

Use (or at least make it optional) optimized reflection
(with cglib) in facelets function mapper.



 Comments   
Comment by jhook [ 09/Oct/07 ]

Do you have a patch you could provide which we could bring back to the EL-impl?





[FACELETS-263] MethodExpression dont work in composition component Created: 28/Sep/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: 1.1.11
Fix Version/s: 1.1.15

Type: Bug Priority: Trivial
Reporter: Gilliard Cordeiro Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 263

 Description   

(sorry, I dont speak english )

maycompany.taglib.xml
<tag>
<tag-name>mycomponent</tag-name>
<source>mycomponent.xhtml</source>
</tag>

in my mycomponent.xhtml

...
<h:commandButton value="#

{value}" action="#{myAction}"/>
...

in may client xhtml

...
<my:mycomponent value="Test" myAction="#{Bean.action1}"/>
...

On execute facelets find the Bean.getAction1(), but action1 is a action and not
a property.

For use this feature a have a workaround:

in my mycomponent.xhtml
...
<h:commandButton value="#{value}

" action="#

{myBean[myAction]}

"/>
...

in my client xhtml

<my:componet value="Test" myBean="#

{Bean}

" myAction="action1"/>

but is very bad when I'm developing wrapper components.



 Comments   
Comment by Ryan Lubke [ 20/Feb/08 ]

This looks similar to issue 273.





[FACELETS-262] serializable facelets / persistent facelet cache Created: 26/Sep/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.2_03
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: hannesh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 262

 Description   

A persistent facelet cache would eliminate the compilation overhead
on application restart. This requires serializable facelets.






[FACELETS-260] DefaultFaceletFactory: facelet cache w/ ltd. memory consumption Created: 26/Sep/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.2_03
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: hannesh Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 260

 Description   

The memory consumption of the facelet cache isn't limited which might
be a problem for large apps. A quick solution seems to be the usage of
LinkedHashMaps instead HashMaps. This donsn't control the memory consumption
but the number of facelets and might be good enough. Unfortulatelly the
LinkedHashMap has to be synchronized. On the other hand we can eliminate
rehashing.

public DefaultFaceletFactory(Compiler compiler, ResourceResolver resolver,
long checkInterval,
final int faceletsCacheSize, final int
relativeLocationsCacheSize) {
ParameterCheck.notNull("compiler", compiler);
ParameterCheck.notNull("resolver", resolver);
this.compiler = compiler;
if (faceletsCachSize == -1)

{ this.facelets = new HashMap(); this.faceletsIsSynchronized = false; }

else {
this.facelets =
Collections.synchronizedMap(new LinkedHashMap((int)Math.ceil
(faceletsCacheSize / 0.75) + 1,
0.75f, true) {
private boolean
removeEldestEntry(Map.Entry eldest)

{ return size() > faceletsCacheSize; }

});
this.faceletsIsSynchronized = true;
}
if (relativeLocationsCacheSize == -1)

{ this.relativeLocations = new HashMap(); this.relativeLocationsIsSynchronized = false; }

else {
this.relativeLocations
= Collections.synchronizedMap(new LinkedHashMap((int)Math.ceil
(relativeLocationsCacheSize / 0.75) + 1,
0.75f, true) {
private boolean
removeEldestEntry(Map.Entry eldest)

{ return size() > relativeLocationsCacheSize; }

});
this.relativeLocationsIsSynchronized = true;
}
this.resolver = resolver;
this.baseUrl = resolver.resolveUrl("/");
log.fine("Using ResourceResolver: " + resolver);
this.checkInterval = (checkInterval >= 0) ? checkInterval * 1000 : -1;
log.fine("Using Check Intervel: " + this.CheckInterval);
}

public Facelet getFacelet(String uri) throws IOException, FaceletException,
FacesException, ELException {
URL url = (URL) this.relativeLocations.get(uri);
if (url == null) {
url = this.resolveURL(this.baseUrl, uri);
if (url == null)

{ throw new IOException("'" + uri + "' not found."); }

else if (this.relativeLocationsIsSynchronized)

{ this.relativeLocations.put(uri, url); }

else

{ Map newLoc = new HashMap(this.relativeLocations); newLoc.put(uri, url); this.relativeLocations = newLoc; }

}
return this.getFacelet(url);
}

public Facelet getFacelet(URL url) throws IOException, FaceletException,
FacesException, ELException {
ParameterCheck.notNull("url", url);
String key = url.toString();
DefaultFacelet f = (DefaultFacelet) this.facelets.get(key);
if (f == null || this.needsToBeRefreshed(f)) {
f = this.createFacelet(url);
if (this.faceletsIsSynchronized)

{ this.facelets.put(key, f); }

else

{ Map newFacelets = new HashMap(this.facelets); newFacelets.put(key, f); this.facelets = newFacelets; }

}
return f;
}



 Comments   
Comment by markcolletteice [ 05/Jan/09 ]

Some ICEfaces + Facelets users have run into this issue. They reported:

Long term use of the application finds memory accumulating in a HashMap, owned
by DefaultFaceletFactory, referenced by D2DFaceletsViewHandler. When the user
logs out, not all of the memory is released by this class.





[FACELETS-259] ui:repeat element stops repeating Created: 26/Sep/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.2
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: jmaguire Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 259

 Description   

Related to bug#213 which has been marked as resolved.
Facelets 1.2, MyFaces 1.5, Java 1.5 Update 9, Solaris 10, Weblogic 9.2

Had this issue with Facelets 1.1 and updated to 1.2, after 1/2hr of load testing
on the application we found that the problem with the ui:repeat element
re-occurred.



 Comments   
Comment by Ryan Lubke [ 20/Feb/08 ]

Please confirm the issue exists with 1.1.14.

Thank you.

Comment by Ryan Lubke [ 20/Feb/08 ]
      • Issue 247 has been marked as a duplicate of this issue. ***




[FACELETS-253] Facelets internal taglibs not loaded last Created: 11/Sep/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Task Priority: Major
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File FaceletViewHandler.patch     Text File taglib.patch    
Issuezilla Id: 253

 Description   

Implicit loading of tag lib descriptors from archives (META-INF) is used by
Facelets to load internal implementations as well. These implementations can't
necessarily be overridden since location compared to another similarly loaded
taglibs is based on classloader hierarchy

Id' suggest that com.sun.facelets.util.Classpath.search wouldn't be used for
internal implementations since the implementation xml files are just pointers to
classes which could be instantiated separately in
com.sun.facelets.compiler.Compiler.initialize().

Until then a workaround is to use parent last classloading mechanism and placing
jsf-facelets.jar as a parent.



 Comments   
Comment by tuomas_kiviaho [ 11/Sep/07 ]

Created an attachment (id=100)
Internal taglib load patch

Comment by tuomas_kiviaho [ 11/Sep/07 ]

Patch just adds internal taglib implementations as last in the list. I consider
the new tag lib package dependencies in Compiler introduced by the patch as
downside.

Comment by tuomas_kiviaho [ 11/Sep/07 ]

Created an attachment (id=101)
ViewHandler patch resolving forced internal taglibs

Comment by tuomas_kiviaho [ 11/Sep/07 ]

This additional patch requires minor change in the version number I believe. It
leaves tag lib loading completely in hands of FaceletsViewHandler thus removing
odd package dependencies caused by the taglib.patch. It also allows the whole
load mechanism to be overridden. It also would remove the lazy initialization
required by the Compiler. I guess this may have been intentional approach in the
first place making the patch useless but nevertheless changes in
com.sun.facelets.FaceletViewHandler.initializeCompiler may not be considered
backward compatible. Hence I separated the patches.

Comment by youngm [ 01/Jul/08 ]

Is this fixed with this issue released in 1.1.15?

https://facelets.dev.java.net/issues/show_bug.cgi?id=315

Comment by youngm [ 01/Jul/08 ]

cced myself

Comment by tuomas_kiviaho [ 02/Jul/08 ]

Issue 315 fixes classloading in general which never has been a problem for me.

I've already got used to the workaround of placing jsf-facelets.jar to container
level so this issue can be closed.





[FACELETS-251] Source tag parameters declaration Created: 30/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: mgrouch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 251

 Description   

Add source tag input parameters declaration section inside source tag file.
Somewhat similar to JSTL source tags (or Ant macros, or XSLT template parameters)

Currently writing a source tag is like writing a function with body only
(no input parameters are declared, no function spec)

Regards






[FACELETS-250] Render time analog for ui:include is needed Created: 28/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: New Feature Priority: Major
Reporter: mgrouch Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 250

 Description   

ui:include is build time tag, so you can't pass src parameter value at render time.

Render time analog for ui:include is needed.

it would be nice to have something like

<ui:includeView src="#

{bean.viewUrl}

"/>

and be able to result to viewUrl at render time.






[FACELETS-249] support for method binding for templates Created: 28/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: carmello Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://carmello.freewebpage.org/facelets-methodbinding-patch.zip


Attachments: Zip Archive facelets-methodbinding-patch.zip    
Issuezilla Id: 249

 Description   

The zip file contains the modified files plus one new file calles
MethodBindingDescriptor. This new class holds the info about the methodbinding
(name, return class, parameter classes) so a method binding can be created with
that info.
I added some new tags to the dtd so you can specify in your taglib file which
attributes needs methodbindings. You are offcourse free to choice another syntax
to specify the info in the taglib.

Feel free to contact me if you have questions about the patch.

Evert



 Comments   
Comment by carmello [ 28/Aug/07 ]

Created an attachment (id=98)
the patch files (java files + dtd)





[FACELETS-248] Tag analog to JSTL's c:import Created: 26/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: New Feature Priority: Major
Reporter: mgrouch Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 248

 Description   

Tag analog to JSTL's c:import

Facelets are missing this functionality.

Ex:
<c:import url="http://othersite.com/index.jsp" />

It should allow passing parameters, proxying the request to absolute URL. Do
same type of functionality as c:import (which is superset of jsp:include)

Right now it is very difficult to get this functionality in JSF.

Thanks






[FACELETS-246] Facelets Templating Bug Created: 25/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: neilac333 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 246

 Description   

I have run this by the forum, and it does indeed seem like this is a bug.
According to the documentation, anything found between <ui:composition> and
<ui:define> in a template client is ignored. However, I have found cases where
properly named <ui:insert>/<ui:define> pairs do not result in content insertion
into the template. Essentially, when the <ui:define> tag is "buried" under
certain markup, the TemplateManager is unable to find it. I have not identified
precisely all cases where this is true.

Here are two examples:

Example 1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk"
xmlns:ice="http://www.icesoft.com/icefaces/component">
<ui:composition template="/template.jspx">
<head>
<ui:define name="title">Main Page</ui:define>
</head>
<body>
<form>
<ui:define name="mainFormContent">
<label for="inputBox" jsfc="ice:outputLabel">Enter something here: </label>
<input type="text" jsfc="ice:inputText" id="inputBox"
partialSubmit="true" value="#

{backingBean.givenValue}"/>
<input jsfc="ice:commandButton" type="submit" value="Submit"
id="submitButton" action="success"/>
<br/>
<label for="output" jsfc="ice:outputLabel">You typed: </label>
<ice:outputText id="output" rendered="#{backingBean.givenValue != null}">#{backingBean.givenValue}

</ice:outputText>
</ui:define>
</form>

<ui:define name="navigationContent">Here is real navigation stuff.</ui:define>
</body>
</ui:composition>
</html>

---------------------------------------------

Example #2

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk"
xmlns:ice="http://www.icesoft.com/icefaces/component">
<body>
<ui:composition template="/template.jspx">

<ui:define name="title">Main Page</ui:define>

<form>
<ui:define name="mainFormContent">
<label for="inputBox" jsfc="ice:outputLabel">Enter something here: </label>
<input type="text" jsfc="ice:inputText" id="inputBox"
partialSubmit="true" value="#

{backingBean.givenValue}"/>
<input jsfc="ice:commandButton" type="submit" value="Submit"
id="submitButton" action="success"/>
<br/>
<label for="output" jsfc="ice:outputLabel">You typed: </label>
<ice:outputText id="output" rendered="#{backingBean.givenValue != null}">#{backingBean.givenValue}

</ice:outputText>
</ui:define>

<ui:define name="navigationContent">Here is real navigation stuff.</ui:define>
</form>

</ui:composition>
</body>
</html>






[FACELETS-245] JSTL namespace uri incorrect Created: 24/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: soudmaijer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File AbstractTagLibrary.patch    
Issuezilla Id: 245

 Description   

According to the documentation:

3.2.3. JSTL Support

Facelets includes limited support for JSTL 'tags' within the Core and Function
library only. Here is the link to Function and Core documentation from JSTL:

The Function library is implemented, according to the spec in its entirety.

But if you check the core jstl JavaDoc it states:

JSTL core
Standard Syntax:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

XML Syntax:
<anyxmlelement xmlns:c="http://java.sun.com/jsp/jstl/core" />

But the following URI: http://java.sun.com/jsp/jstl/core doesn`t work with
facelets and should work in my opinion. A work around is to use
http://java.sun.com/jstl/core as the URI.



 Comments   
Comment by tuomas_kiviaho [ 11/Sep/07 ]

Created an attachment (id=99)
Added patch allowing multiple namespaces in AbstractTagLibrary





[FACELETS-243] JSTL c:set does not work with <tag>body</tag> variant Created: 15/Aug/07  Updated: 11/Feb/09

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Critical
Reporter: lilianne_blaze Assignee: driscoll
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 243

 Description   

<c:set var="x" value="y"/> works.
<c:set var="x">y</c:set> doesn't, apparently the implementation simply isn't
aware of that possibility.



 Comments   
Comment by Ed Burns [ 02/Feb/09 ]

take ownership

Comment by driscoll [ 11/Feb/09 ]

take ownership.





[FACELETS-242] SAXCompiler configuration not possible Created: 13/Aug/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File SAXCompiler.patch    
Issuezilla Id: 242

 Description   

External DTD on SVG images cause tremendous overhead but setValidating doesn't
necessarily do that. Instead I must use implementation specific setFeature like
"http://apache.org/xml/features/nonvalidating/load-external-dtd" but there is no
access to these methods from Compiler api. To make things worse the property
feature is already in use as service provider for the Compiler.



 Comments   
Comment by tuomas_kiviaho [ 13/Aug/07 ]

Created an attachment (id=95)
Exposing feature instantion to sub classes

Comment by tuomas_kiviaho [ 14/Aug/07 ]

SAXCompiler.patch makes Compiler.featureInstance accessible from SAXCompiler.
Preset features can be delivered though this mechanism without tampering with
Services API.

Comment by tuomas_kiviaho [ 14/Aug/07 ]

A more appropriate approach would be API change by getting rid of feature
instantiation methods altogether and use standard Services API for
ExpressionFactory instantiation.

Then a new feature property could be introduced to access parser factories so
that there wouldn't be need extend the factory class as is with the
SAXCompiler.patch

Comment by tuomas_kiviaho [ 26/Sep/07 ]

Any changes getting this applied. SVG images have just too big DTD to get proper
response times and xerces needs special features to be set even when not
validating to ignore the DTD completely. Removing the DTD manually isn't a
proper workaround for me.





[FACELETS-237] Columns in h:dataTable get duplicated Created: 26/Jul/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: juergen_zimmermann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive testcase-datatable.zip    
Issuezilla Id: 237

 Description   

My platform: Tomcat 6.0.13, JSF RI 1.2_04 P02, JDK 1.6.0_02

I've put together a small testcase (internationalized for English and
German):
1) Search for customers and sort by id: can be done several times
without any problems. Then search for customers and sort by first
name results in duplication of the columns
2) Search for customers and sort by first name: can be done several times
without any problems. Then search for customers and sort by id results
in duplication of the columns

Testcase will be uploaded after submitting this issue.



 Comments   
Comment by juergen_zimmermann [ 26/Jul/07 ]

Created an attachment (id=91)
Testcase for duplication of columns

Comment by juergen_zimmermann [ 26/Jul/07 ]

Didn't know how to specify the facelet version: 1.1.13





[FACELETS-231] ui:repeat doesn't call set method for ListDataModel Created: 24/Jun/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: UNKNOWN
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: johnpeeb Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 231

 Description   

I have a ListDataModel which is bound to a ui:repeat which contains multiple
h:inputText's. The ListDataModel is a private field in a Spring Managed bean
which Facelets accesses using the spring DelegatingVariableResolver. Although
the values of the ListDataModel are successfully updated, the set method of the
bean is not called to do it. It does, however call the get method. My guess is
that it updates reference returned by the get method. This presents problems.
The platform is WinXP SP2 with Tomcat 5.5.17 (the one bundled with netbeans)
using the myfaces 1.1.4 and facelets 1.1.12.



 Comments   
Comment by johnpeeb [ 25/Jun/07 ]

It appears that the same problem occurs with t:dataList (tomahawk).





[FACELETS-227] ConcurrentModificationException in UI Debug DevTools Created: 18/May/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: trillion Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 227

 Description   

When using the ui:debug tag, the following error may occur infrequently. Seems
like it may be a thread-safety issue (session being modified during
DevTools.writeVariables).

May 18, 2007 2:04:49 PM com.sun.facelets.FaceletViewHandler handleRenderException
SEVERE: Error Rendering View[/foo/Bar.xhtml]
java.util.ConcurrentModificationException
at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:365)
at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:384)
at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:383)
at java.util.AbstractMap.hashCode(AbstractMap.java:557)
at
com.sun.faces.context.BaseContextMap$Entry.hashCode(ExternalContextImpl.java:471)
at java.util.HashMap.hash(HashMap.java:264)
at java.util.HashMap.put(HashMap.java:382)
at java.util.HashSet.add(HashSet.java:194)
at com.sun.faces.context.SessionMap.entrySet(ExternalContextImpl.java:603)
at java.util.AbstractMap.size(AbstractMap.java:68)
at java.util.TreeMap.putAll(TreeMap.java:314)
at java.util.TreeMap.<init>(TreeMap.java:156)
at com.sun.facelets.util.DevTools.writeVariables(DevTools.java:158)
at com.sun.facelets.util.DevTools.writeVariables(DevTools.java:147)
at com.sun.facelets.util.DevTools.debugHtml(DevTools.java:135)
at com.sun.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:92)
at com.sun.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:81)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:232)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:580)
at foo.bar.util.faces.CustomViewHandler.renderView(CustomViewHandler.java:55)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214)
at
com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64)
at foo.bar.util.SessionTimeoutFilter.doFilter(SessionTimeoutFilter.java:29)
at
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:15)
at foo.bar.util.PersistenceFilter.doFilter(PersistenceFilter.java:37)
at
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:17)
at foo.bar.UploadFilter.doFilter(UploadFilter.java:81)
at
com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:619)
at
com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)
at
com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866)
at
com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:302)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:190)
at
oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
at
com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
at java.lang.Thread.run(Thread.java:595)



 Comments   
Comment by Ryan Lubke [ 20/Feb/08 ]

Please confirm the version of the RI you're using.

Comment by trillion [ 22/Feb/08 ]

This occurred in 1.1_02-b08.





[FACELETS-225] wrong template client order on stack if nesting templates Created: 27/Apr/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: el_moellere Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 225

 Description   

Suppose you have a page (test.xhtml) that should have a red border ...

<ui:composition template="redborder.xhtml">
<ui:define name="body">BODY</ui:define>
</ui:composition>

... by using the following template file (redborder.xhtml) that itself should
have a blue border ...

<ui:composition template="blueborder.xhtml">
<ui:define name="body">
<div style="border: red">
<ui:insert name="body" />
</div>
</ui:define>
</ui:composition>

... by using another template file (blueborder.xhtml)...

<div style="blue">
<ui:insert name="body" />
</div>

... then the resulting page would have only the blue border because the stack
gets built in the wrong order by the ui:composition (and also ui:decorate) tag.
The evaluation of the ui:insert in the blue-border-template finds the template
client test.xhtml on top of the stack (followed by the template client
redborder.xhtml) and therefore the wrong "body" is inserted.

This unexpected behaviour could be fixed by changing the extendClient method
calls in CompositionHandler and DecorateHandler to pushClient.



 Comments   
Comment by kenpaulsen [ 14/Jun/07 ]

IMO, This is not a bug... it's a feature.

redborder.xhtml shouldn't have an insert. The insert behavior searches for body
from the outer-most file (test.xhtml) to the inner-most. This allows for the
user to override the insert at the more specific (outer-most – test.xhtml) level.

In this example you have (ignore the insert in red):

test -> red -> blue

Suppose you also have:

foo -> red -> blue

However, lets say "foo" doesn't provide a "body" define. This shows that "red"
has a "default" body defined, which "test" overrides. foo doesn't override it,
so it gets the default body.

I suspect a lot of people depend on this behavior. I do not think this behavior
should be changed and think it works as it should.

Ken





[FACELETS-223] FaceletTestCase should be documented and packaged Created: 22/Mar/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Critical
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 223

 Description   

FaceletTestCase (and the related mock objects) are very useful, but it'd be
great if they were documented somewhere obvious (like the documentation itself),
and if there was a simple JAR called something like "jsf-facelets-test").






[FACELETS-221] Bugfix for JRUN 4.0 Created: 21/Mar/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Task Priority: Critical
Reporter: kohlhaas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 221

 Description   

I've found a bug in the JRun 4.0 implementation of ResourceURLStreamHandler
jrunx.resource.ResourceURLStreamHandler which prevents to use the source
attribute in a Tagfile e.g.

<facelet-taglib>
<namespace>http://suretec.de/tags</namespace>
<tag>
<tag-name>label-with-help</tag-name>
<source>tags/label-with-help.xhtml</source>
</tag>
</facelet-taglib>

The bug happens in the file TagLibraryConfig in the following section

247 else if ("source".equals(qName))

{ String path = this.captureBuffer(); URL url = new URL(this.source, path); impl.putUserTag(this.tagName, url); }

The created URL url is correct but the URL contains an
jrunx.resource.ResourceURLStreamHandler which points to the source variable
instead of the complete url this.source + path. When the tagfile is parsed later
(first use of the tag) in the SAXCompiler, the openStream method of the
jrunx.resource.ResourceURLStreamHandler is used and
the SAXParser parses the tag-libary file WEB-INF/suretec.taglib.xml instead of
the tagfile WEB-INF/tags/label-with-help.xhtml which will insert the taglib
content from above in you resulting html.

To fix this I simply replaced

247 URL url = new URL(this.source, path);

with

247 URL url = new URL( new URL(this.source, path).toExternalForm());

this creates a completly new jrunx.resource.ResourceURLStreamHandler with the
correct reference.

Regards Christopher






[FACELETS-216] ForEach begin=2002 end=2012 Created: 26/Feb/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Task Priority: Major
Reporter: mhenmi2 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 216

 Description   

I want to write yearly select
<c:forEach var="item" begin="$

{2007 - 5}

" end="$

{2007 + 5}

" >
but byte[] overflow in ForEachHandler.java.

I change the ForEachHandler.java as below.

ValueExpression srcVE = null;
if (this.items != null)

{ srcVE = this.items.getValueExpression(ctx, Object.class); src = srcVE.getValue(ctx); }

else {
int siz = Math.abs((e - s) / m) + 1;
if (siz > 1000) throw new IllegalArgumentException();
int[] b = new int[siz];
for (int i = 0; i < b.length; i++)

{ b[i] = s + i * m; }

src = b;
}

if (src != null) {
Iterator itr = this.toIterator(src);
if (itr != null) {
int i = 0;

/* move to start COMMENT !!
while (i < s && itr.hasNext())

{ itr.next(); i++; }

*/



 Comments   
Comment by mhenmi2 [ 27/Feb/07 ]

public void apply(FaceletContext ctx, UIComponent parent)
throws IOException, FacesException, FaceletException, ELException {

if (this.items != null)

{ applyItems(ctx, parent); }

else

{ applyNoItems(ctx, parent); }

}

public void applyItems(FaceletContext ctx, UIComponent parent)
throws IOException, FacesException, FaceletException, ELException {

int s = this.getBegin(ctx);
int e = this.getEnd(ctx);
int m = this.getStep(ctx);
Integer sO = this.begin != null ? new Integer(s) : null;
Integer eO = this.end != null ? new Integer(e) : null;
Integer mO = this.step != null ? new Integer(m) : null;

boolean t = this.getTransient(ctx);
Object src = null;
ValueExpression srcVE = null;
if (this.items != null)

{ srcVE = this.items.getValueExpression(ctx, Object.class); src = srcVE.getValue(ctx); }

if (src != null) {
Iterator itr = this.toIterator(src);
if (itr != null) {
int i = 0;

/* move to start*/
while (i < s && itr.hasNext())

{ itr.next(); i++; }

String v = this.getVarName(ctx);
String vs = this.getVarStatusName(ctx);
VariableMapper vars = ctx.getVariableMapper();
ValueExpression ve = null;
ValueExpression vO = this.capture(v, vars);
ValueExpression vsO = this.capture(vs, vars);
int mi = 0;
Object value = null;
try {
boolean first = true;
while (i <= e && itr.hasNext()) {
value = itr.next();
// set the var
if (v != null) {
if (t || srcVE == null)

{ ctx.setAttribute(v, value); }

else

{ ve = this.getVarExpr(srcVE, src, value, i); vars.setVariable(v, ve); }

}

// set the varStatus
if (vs != null) {
IterationStatus itrS = new IterationStatus(first, !itr.hasNext
(),i, sO, eO, mO);
if (t || srcVE == null)

{ ctx.setAttribute(vs, itrS); }

else

{ ve = new IterationStatusExpression(itrS); vars.setVariable(vs, ve); }

}

// execute body
this.nextHandler.apply(ctx, parent);

// increment steps
mi = 1;
while (mi < m && itr.hasNext())

{ itr.next(); mi++; i++; }

i++;

first = false;
}
} finally {
if (v != null)

{ vars.setVariable(v, vO); }

if (vs != null)

{ vars.setVariable(vs, vsO); }

}
}
}
}

public void applyNoItems(FaceletContext ctx, UIComponent parent)
throws IOException, FacesException, FaceletException, ELException {

int s = this.getBegin(ctx);
int e = this.getEnd(ctx);
int m = this.getStep(ctx);
Integer sO = this.begin != null ? new Integer(s) : null;
Integer eO = this.end != null ? new Integer(e) : null;
Integer mO = this.step != null ? new Integer(m) : null;

boolean t = this.getTransient(ctx);

ValueExpression srcVE = null;
if (this.items != null) throw new IllegalStateException();
if (m == 0) throw new IllegalArgumentException();

int i = s;

String v = this.getVarName(ctx);
String vs = this.getVarStatusName(ctx);
VariableMapper vars = ctx.getVariableMapper();
ValueExpression ve = null;
ValueExpression vO = this.capture(v, vars);
ValueExpression vsO = this.capture(vs, vars);
int mi = 0;
Object value = null;
try {
boolean first = true;
while ((m > 0 && i <= e) || (m < 0 && i >= e)) {
value = new Integer;
// set the var
if (v != null) {
if (t || srcVE == null)

{ ctx.setAttribute(v, value); }

}
int nextI = i + m;
boolean flag = (m > 0 && nextI <= e) || (m < 0 && nextI >= e);
// set the varStatus
if (vs != null) {
IterationStatus itrS = new IterationStatus(first, !flag,i, sO, eO,
mO);
if (t || srcVE == null)

{ ctx.setAttribute(vs, itrS); }

}
// execute body
this.nextHandler.apply(ctx, parent);
// increment steps
i+= m;
first = false;
}
} finally {
if (v != null)

{ vars.setVariable(v, vO); }

if (vs != null)

{ vars.setVariable(vs, vsO); }

}
}





[FACELETS-214] fragment trims after end tag, but not before start tag. Created: 19/Feb/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: wayfarer3130 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 214

 Description   

The fragment include is supposed to not trim either before or after the tag, but
in fact it trims everything after the ending tag.
The test case I'm using is:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<ui:fragment xmlns:ui="http://java.sun.com/jsf/facelets">
<xsl:template match="/">
<html xmlns="http://www.w3.org/1999/xhtml">
... (Anything in here)
</html>
</xsl:template>
</ui:fragment>
</xsl:stylesheet>

It does not include the ending line in the output.






[FACELETS-211] <ui:repeat> needs an Exception and a clear message when attempting to iterate over build-time tags Created: 07/Feb/07  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: bmargolis Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 211stacktrace.txt    
Issuezilla Id: 211

 Description   

I'm getting a stack overflow when I try to do the following:

<ui:repeat value=#

{myBean.subComponents} var="subcomponent">
<ui:include src="#{subcomponent.myXHTMLName}"/>
</ui:repeat>

I verified that this works:

<ui:repeat value=#{myBean.subComponents}

var="subcomponent">
<h:outputText value="#

{subcomponent.myXHTMLName}

"/>
</ui:repeat>

and this works:

<ui:repeat value=#

{myBean.subComponents}

var="subcomponent">
<ui:include value="hardcodedReference.xhtml"/>
</ui:repeat>

and this works:

<ui:include src="#

{myBean.myXHTMLName}

"/>

where myBean has the following getter:

public String getMyXHTMLName()

{ return subcomponents.get(0); }

The stack overflow only occurs when using an el expression in an include that
has been nested in a repeat.



 Comments   
Comment by jhook [ 07/Feb/07 ]

ui:repeat is a runtime evaluation while ui:include is a compiletime-- I realize
it's confusing, but basically the doc gets included at compile time, then the
rendering happens afterwards-- so Facelets isn't causing a StackOverflow, just
allowing you to do so-- which comes with the territory of allowing recursion.

Comment by bmargolis [ 08/Feb/07 ]

I don't understand. How can the src attribute of <ui:include> in this example:

<ui:include src="#

{myBean.myXHTMLName}

"/>

be evaluated at compiletime if the value is coming from a bean, given that the
accessor's return value won't be known until runtime? And how is it that this:

<c:forEach items=$

{myBean.subComponents}

var="subcomponent">
<ui:include value="#

{subcomponent.myXHTMLName}

"/>
</c:forEach>

is (surprisingly) working without any problems? There is obviously some
recursion going on, but if it was happening in the bean, the <c:forEach> would
be generating a stack overflow too. Whether you choose to fix this right away
or not is not that crucial to me, personally, since I have found a JSTL-based
workaround. This problem should be fixed, though, if <ui:repeat> is truly
supposed to be a replacement for <c:forEach>.

Judging from the longest stack trace I've ever seen in my life, some recursion
is happening somewhere in the facelets library or in the el reference
implementation. I didn't post the stack trace because it's so long, but I'll
copy it to a file and attach it so that you can see what I mean.

Comment by bmargolis [ 08/Feb/07 ]

Created an attachment (id=69)
StackOverflow stack trace

Comment by bmargolis [ 09/Feb/07 ]

After reading the FAQ, I have come to understand that your usage of compile-time
refers to the component tree's compile time, and I see why <c:forEach> is
working. The fact that this is an FAQ indicates that I'm far from being the
first developer to run into this problem. Isn't there some way you can detect
this condition and generate a FaceletsSpecificationViolationException or
something along those lines? Forcing developers to work around a given
implementation's limitations is not ideal, but at least those limitations can be
communicated directly in the stack trace/error message rather than being buried
in an FAQ on a wiki page somewhere.

Comment by tsuberag [ 10/Oct/11 ]

Looks like construction:
<ui:repeat value=#

{myBean.subComponents}

var="subcomponent">
<ui:include src="#

{subcomponent.myXHTMLName}

"/>
</ui:repeat>

interpreted as something like:
for (Component component : myBean.subComponents)

{ <static code generated from page myBean.subComponents[0].myXHTMLName> }

but should be interpreted like:
for (Component component : myBean.subComponents)

{ dynamicExecutePage(component.myXHTMLName); }

Recursion page executing should be implemented for input tag, instead of static page including.





[FACELETS-209] TagAttributeException after deploy - dissapears if i restart Glassfish Created: 29/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: raresp Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File MetaTagHandler.java.patch    
Issuezilla Id: 209

 Description   

com.sun.facelets.tag.TagAttributeException is thrown after I redeploy my web-app.

This usually happens when I modify something inside a facelet component or a JSF
custom component. In such cases this exception is thrown on the first attribute
encountered in that component even if the syntax is 100% correct.
In fact after I restart glassfish everything works well.

Here is an example of error message and the stack trace

/WEB-INF/components/cms/richTextBox.xhtml @15,29 normalStyle="editableOff"
object is not an instance of declaring class

com.sun.facelets.tag.TagAttributeException:
/WEB-INF/components/cms/richTextBox.xhtml @15,29 normalStyle="editableOff"
object is not an instance of declaring class
at
com.sun.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:53)
at com.sun.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:36)
at com.sun.facelets.tag.MetaTagHandler.setAttributes(MetaTagHandler.java:62)
at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:140)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:119)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
at com.sun.facelets.tag.UserTagHandler.apply(UserTagHandler.java:81)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.tag.ui.DefineHandler.apply(DefineHandler.java:58)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:128)
at
com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:306)
at
com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:279)
at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:109)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:510)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:553)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at
com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at
com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:49)
... 60 more

I use Facelets 1.1.11, JSF 1.2 and the latest patched Glasfish M1.

facelets.DEVELOPMENT is on
facelets.REFRESH_PERIOD = 1



 Comments   
Comment by ramazanyich2 [ 16/Jul/07 ]

Created an attachment (id=90)
it is a problem inside metataghandler. It doesn't take into account classloaders. Proposed patch works for me in JBOSS server





[FACELETS-208] add varStatus to ui:repeat Created: 26/Jan/07  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: www
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Critical
Reporter: jamese Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File uirepeat-varstatus-patch.txt    
Issuezilla Id: 208

 Description   

The ui:repeat tag needs varStatus support like the c:forEach JSTL tag has. This
is necessary because you often need to reference controls in javascript.

See this thread for more details:
http://www.nabble.com/ui%3Arepeat-and-varStatus-tf3028548.html#a8414395



 Comments   
Comment by sbublava [ 25/Apr/07 ]

Created an attachment (id=72)
This patch implements varStatus for ui:repeat. The code works for be, but hasn't been tested with jsfc attributes or nested repetitions. Documentation changes are not included.

Comment by Ryan Lubke [ 06/Jun/07 ]
      • Issue 140 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 03/Feb/09 ]

Duplicate of 328

      • This issue has been marked as a duplicate of 328 ***
Comment by rogerk [ 29/Jul/09 ]

Fixed.

Comment by rogerk [ 29/Jul/09 ]

varStatus was added to JSF 2.0 facelets derivative not facelets itself.
Need to implement varStatus in facelets.





[FACELETS-207] Facelets 1.2 Ajax encode error Created: 25/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: UNKNOWN
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: Gilliard Cordeiro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 207

 Description   

Facelets 1.2 use encode UTF-8 in AJAX requests, and I have errors in
encode/decode user inputs using latim americam encode.






[FACELETS-204] h:inputHidden value="#{EL}" inside a facelet component gives illegal syntax Created: 19/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: raresp Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 204

 Description   

Situation
1. I have a facelet component (named richtextbox)
2. One of its parameters is "richTextPath".
3. Inside this component i have a <h:inputHidden value="#

{richTextPath}" ../>

The problem.
At render time everything is rendered correctly but when an actionListener is
triggered from inside the component the following error messages are displayed
by JSF:

/WEB-INF/components/cms/richTextBox.xhtml @21,63 value="#{richTextPath}

":
/app/stest.xhtml @11,121 richTextPath="/app/richtexts/services/left": Illegal
Syntax for Set Operation /WEB-INF/components/cms/richTextBox.xhtml @21,63
value="#

{richTextPath}": /app/stest.xhtml @11,121
richTextPath="/app/richtexts/services/left": Illegal Syntax for Set Operation

---------------
here is the component code
---------------
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:c="http://java.sun.com/jstl/core"
xmlns:axz="http://axz.com/jsf/axz">

<axz:editable mode="#{currentSession.cmsMode}" framedStyle="editableOn"
normalStyle="editableOff">
<h:form id="#{name}">
<f:attribute name="linkEntry" value="#{acessCM.link.entry}" />
<!-- <h:inputHidden name="contextName" value="#{contextName}" /> -->

<h:inputHidden value="#{richTextPath}

" id="rtp"
valueChangeListener="#

{cmsSession.richTextPathChanged}

" />

<axz:editableToolbar style="editableToolbarOn">

<!-- rendered="#

{richTextPath == null}

" -->
<h:commandButton image="/cms/media/file16.gif" title="New content"
actionListener="#

{cmsSession.createRichText}

" >
<f:attribute name="name" value="#

{name}" />

</h:commandButton>
<h:commandButton image="/cms/media/fileSelect16.gif"
onclick="selectRichTextDialog('#{name}

:rtp');"
title="#

{richTextPath} - select other" />
<h:commandButton image="/cms/media/pencil16.gif"
actionListener="#{cmsSession.prepareArticleForEdit}" />
<h:commandButton image="/cms/media/disk16.png"
actionListener="#{cmsSession.savePreparedArticle}" />
<h:commandButton image="/cms/media/refresh16.gif"
actionListener="#{cmsSession.prepareArticleForEdit}" />

</axz:editableToolbar>


<axz:wysiwyg name="#{name}" contentPath="#{richTextPath}

"
style="style" />

<hr />

</h:form>
</axz:editable>

</ui:composition>
--------------






[FACELETS-203] Trancient facets are removed twice Created: 15/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: lexi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 203

 Description   

Hi.

I have a problem with ComponentSupport.removeTransient(...).

I have a component structure with lots of facets. I have noticed that the
application is becoming somehow slow when it comes to rendering these faceted
structures.

I've investigated and it turns out that removeTransient(...) method is very
slow. I've checked the source code and found an interesting thing: facets of
each of the components are processed twice:

public static void removeTransient(UIComponent c) {
UIComponent d, e;
if (c.getChildCount() > 0) {
for (Iterator itr = c.getChildren().iterator(); itr.hasNext() {
d = (UIComponent) itr.next();

////// The first time here

if (d.getFacets().size() > 0) {
for (Iterator jtr = d.getFacets().values().iterator(); jtr
.hasNext() {
e = (UIComponent) jtr.next();
if (e.isTransient())

{ jtr.remove(); }

else

{ removeTransient(e); }

}
}
if (d.isTransient())

{ itr.remove(); } else { removeTransient(d); }
}
}
////// The second time on the next step of recursion here
if (c.getFacets().size() > 0) {
for (Iterator itr = c.getFacets().values().iterator(); itr
.hasNext() {
d = (UIComponent) itr.next();
if (d.isTransient()) { itr.remove(); }

else

{ removeTransient(d); }

}
}
}

This is not simply 2x number of facets. This is much much worse, probably
exponential growth. I do not see any particular reason why facets should be
processed twice. I guess the first processing should be removed. I'll try
removing it, test again and then report.

Bye.
/lexi






[FACELETS-202] Multiple bodies & default content for composition components Created: 14/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: vajav Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 202

 Description   

Hello,

please forgive me if this is already filled but i haven't found anything

So: I would really love to have the option to set overwriteable default content
in composition components (see
https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=6385 from Andre)
and the possibility to insert more than one body in composition components (see
https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=6400 from Rick).

In short: composition components should have the same possibilities like templates.

Last but not least i would like to see the possibility to use composition
components recursively (I'm not 100% sure if this is possible ATM and i did
something wrong or not).






[FACELETS-200] Problem with h:form attributes Created: 11/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: JSF RI 1.2
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: esnunes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 200

 Description   

I have a problem with this scenario.

Page: index.xhtml
— cut here —
...
<my:form fileUpload="true">
...
</my:form>
— cut here —

Component: form.xml
— cut here —
...
<!--
<h:form id="frm"
enctype="#

{fileUpload?'multipart/form-data':'application/x-www-form-urlencoded'}

">
-->
<h:form id="frm"
enctype="#

{fileUpload?'multipart/form-data':'application/x-www-form-urlencoded'}

">
...
— cut here —

In JSF RI 1.2 the JSF render this:
— cut here —
...
<!--
<h:form id="frm" enctype="multipart/form-data">
-->
<form id="frm" name="frm" method="post" action="index.jsf"
enctype="application/x-www-form-urlencoded">
...
— cut here —

I dont have this problem with myfaces 1.1.x implementation. The source comment
is rendered okey but the h:form dont.






[FACELETS-199] Problem with relative paths in include component - again... Created: 10/Jan/07  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: esnunes Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 199

 Description   

The problem with relative paths in "ui:include" component continue the same as
described in this forum:

http://www.nabble.com/Re:-Problem-with-relative-paths-p2388604.html

Eduardo S. Nunes
esnunes@gmail.com



 Comments   
Comment by esnunes [ 10/Jan/07 ]

I tested with versions 1.1.11, 1.1.12 and 1.2(last build). All versions had the
same behavior.





[FACELETS-195] Converting from 1.0.14 to 1.1.12 Compostiion problem Created: 20/Dec/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: masewarner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 195

 Description   

I am having a problem converting from Facelets 1.0.14 to Facelets 1.1.12
I was using
Tomcat 5.5.17
JSF 1.1_02-b08
Facelets 1.0.14

I am now using
Tomcat 5.5.20
JSF 1.2_03-b09-FCS
Facelets 1.1.12

When I called the following tag it worked fine in 1.0.14:
<f:facet name="footer">
<a:paging entity="$

{MktBlb.led.page}

" />
</f:facet>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:c="http://java.sun.com/jstl/core">
<ui:composition>
<!-- Paging navigation controls -->

<h:panelGrid id="navFooter" columns="9" cellspacing="5" cellpadding="3" >
<h:commandButton id="navFooterFirst" image="#

{entity.firstImage}"
action="#{entity.firstPageAction}" />
<h:graphicImage id="navFooterImg1" value="../images/spacer.gif"
width="10" height="5"/>
<h:commandButton id="navFooterPrev" image="#{entity.prevImage}"
action="#{entity.prevPageAction}" />
<h:graphicImage id="navFooterImg2" value="../images/spacer.gif"
width="10" height="5"/>
<h:outputText id="navFooterStatusText" value="#{entity.statusText}"
style=""/>
<h:graphicImage id="navFooterImg3" value="../images/spacer.gif"
width="10" height="5"/>
<h:commandButton id="navFooterNext" image="#{entity.nextImage}"
action="#{entity.nextPageAction}" />
<h:graphicImage id="navFooterImg4" value="../images/spacer.gif"
width="10" height="5"/>
<h:commandButton id="navFooterLast" image="#{entity.lastImage}"
action="#{entity.lastPageAction}" />
</h:panelGrid>

</ui:composition>
</html>

Now when I call this tag in 1.1.12 under JSF 1.2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:c="http://java.sun.com/jstl/core"
version="2.0">
<ui:composition>
<!-- Paging navigation controls -->

<h:panelGrid id="navFooter" columns="9" cellspacing="5" cellpadding="3" >
<h:commandButton id="navFooterFirst" image="#{entity.firstImage}

"
action="#

{entity.firstPageAction}

" />
<h:graphicImage id="navFooterImg1" value="/images/spacer.gif" width="10"
height="5"/>
<h:commandButton id="navFooterPrev" image="#

{entity.prevImage}

"
action="#

{entity.prevPageAction}

" />
<h:graphicImage id="navFooterImg2" value="/images/spacer.gif" width="10"
height="5"/>
<h:outputText id="navFooterStatusText" value="#

{entity.statusText}

"
style=""/>
<h:graphicImage id="navFooterImg3" value="/images/spacer.gif" width="10"
height="5"/>
<h:commandButton id="navFooterNext" image="#

{entity.nextImage}

"
action="#

{entity.nextPageAction}

" />
<h:graphicImage id="navFooterImg4" value="/images/spacer.gif" width="10"
height="5"/>
<h:commandButton id="navFooterLast" image="#

{entity.lastImage}"
action="#{entity.lastPageAction}" />
</h:panelGrid>

</ui:composition>
</html>

Only the last image="#{entity.lastImage}

" is being called at render time
None of the other calls to resolve the entity methods are being called.

How can I fix this?






[FACELETS-194] components unable to send binary output Created: 18/Dec/06  Updated: 22/Jun/07

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: rogerkeays Assignee: Ryan Lubke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File facelets-194-SNAPSHOT.war     GZip Archive facelets-194-src.tar.gz    
Issuezilla Id: 194

 Description   

The FaceletsViewHandler renderResponse method sets up a ResponseWriter
before any part of the tree is rendered. That means our components are
unable to send binary output. AFAICT that breaks the JSF 1.2 spec 6.1.7:
/"JSF supports output that is generated as either a byte stream or a
character stream..."/



 Comments   
Comment by rogerkeays [ 18/Dec/06 ]

It seems that this now works in 1.1.11. Unfortunately it seems I don't have the
correct permissions to change this defect to INVALID.

Comment by rogerkeays [ 10/Jan/07 ]

Correction: this doesn't work in 1.1.11. I was using the myfaces extension
filter which installs a response wrapper that overrides the default
getOutputStream(). Since this wrapper never throws an IllegalStateException the
problem appeared fixed.

Without this filter, the exception is

SEVERE: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalStateException: getWriter() has already been called for this
response
at org.apache.catalina.connector.Response.getOutputStream(Response.java:568)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:180)
at figbird.cms.components.UISendBlob.encodeBegin(UISendBlob.java:89)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:881)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:889)
at
com.sun.faces.extensions.avatar.components.PartialTraversalViewRoot.encodeAll(PartialTraversalViewRoot.java:244)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)

Comment by Ryan Lubke [ 15/Jun/07 ]

What version of the JSF 1.2 RI have you tested this with?
Is this still the case with the 1.2_04 P02 release?

Comment by rogerkeays [ 21/Jun/07 ]

jsf ri 1.2_04-p02 doesn't fix this problem

Comment by rogerkeays [ 21/Jun/07 ]

Created an attachment (id=84)
test webapp to reproduce the problem

Comment by rogerkeays [ 21/Jun/07 ]

Created an attachment (id=85)
test webapp source code

Comment by Ryan Lubke [ 22/Jun/07 ]

I'll take this one on.





[FACELETS-193] ui:define behaviour changed from 1.1.11 to 1.1.12 Created: 12/Dec/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: idueppe Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: File facelets-issue-1.1.11.war     File facelets-issue-1.1.12.war    
Issuezilla Id: 193

 Description   

In version 1.1.12 the behaviour of ui:define changed comparing to 1.1.11.

In the attached example the ui:define section "navigation" is defined twice.ice.
With 1.1.11 the ui:define section of desktop.xhtml is displayed, but 1.1.12
displays the default ui:define section of layout.xhtml.



 Comments   
Comment by idueppe [ 12/Dec/06 ]

Created an attachment (id=65)
In this demo /facelets-1.1.11/desktop.jsf the desktop - navigation is displayed

Comment by idueppe [ 12/Dec/06 ]

Created an attachment (id=66)
In this demo /facelets-1.1.12/desktop.jsf the layout-navigation is displayed

Comment by jhook [ 18/Dec/06 ]

starting





[FACELETS-190] UIDebug causes character encoding problems with RI 1.1 Created: 05/Dec/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: adamwiner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 190

 Description   

FaceletViewHandler.restoreView() calls UIDebug.debugRequest() calls getRequestParameterMap().get().
Because of a lousy choice made by the servlet spec, this means that subsequent calls to
setCharacterEncoding() are ignored. No big deal if setCharacterEncoding() has already been called, but in
the JSF RI 1.1, setCharacterEncoding() is called from their ViewHandlerImpl.restoreView() method - which
will only be called after this method.

The bug does not exist against MyFaces - it calls setCharacterEncoding() while the FacesContext is being
created - or against the JSF 1.2 RI, which calls setCharacterEncoding() during the Restore View lifecycle
phase, before calling ViewHandler.restoreView().

Thanks to Matthias Wessendorf for the analysis here.






[FACELETS-189] Problem with german umlaute Created: 05/Dec/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: labo Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 189

 Description   

Using one of the german Umlaute like ä, ö , ü
ends in a FaceletException -> Invalid byte 2 of 3-byte UTF-8 sequence.

###########################################################################

05.12.2006 13:14:47 org.apache.catalina.core.ApplicationDispatcher invoke
SCHWERWIEGEND: Servlet.service() for servlet Faces Servlet threw exception
com.sun.facelets.FaceletException: Error Parsing /WEB-INF/layout/news.xhtml:
Error Traced[line: 9] Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:234)
at com.sun.facelets.compiler.Compiler.compile(Compiler.java:105)
at
com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:197)
at
com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:144)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:293)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
at com.sun.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:60)
at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:73)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:503)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:546)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:383)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:703)
at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:670)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:43)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
05.12.2006 13:14:47 org.apache.catalina.core.StandardWrapperValve invoke






[FACELETS-181] DefaultFaceletFactory.getFacelet() is not thread safe ! Created: 28/Nov/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Task Priority: Trivial
Reporter: oeuillot Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 181

 Description   

Field facelets of class DefaultFaceletFactory is accessed without any
concurrent thread protection !

A solution :

public Facelet getFacelet(URL url) throws IOException,
FaceletException,FacesException, ELException {
ParameterCheck.notNull("url", url);
synchronized(this.facelets) { // ++++
DefaultFacelet f = (DefaultFacelet) this.facelets.get(url);
if (f == null || this.needsToBeRefreshed(f))

{ f = this.createFacelet(url); this.facelets.put(url, f); }

return f;
} // +++++
}



 Comments   
Comment by jhook [ 28/Nov/06 ]

I'll probably look at clone on modify instead, putting synchronization blocks
there would affect scalability a bit.

For Facelets 1.2, I'll probably use concurrenthashmap

Comment by oeuillot [ 28/Nov/06 ]

It is a very urgent issue !
The structure of this hashMap can be damaged by 2 put in the same time,
and you can't known the consequences ....





[FACELETS-179] Trinidad partial rendering not working on MS Windows Mobile for Pocket PC 2003 Created: 17/Nov/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: nickarls Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: Other


Attachments: Zip Archive mobile.zip    
Issuezilla Id: 179

 Description   

Using facelets with Trinidad partialSubmit/partialTriggers results in blank
page on MS Windows Mobile for Pocket PC 2003. The same configuration works on a
desktop machine. Configuring out facelets results in both platforms working.



 Comments   
Comment by nickarls [ 17/Nov/06 ]

Created an attachment (id=61)
Basic Trinidad and Trinidad/Facelets testcase.





[FACELETS-178] Add a hook for streaming XML Created: 16/Nov/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Critical
Reporter: dmlloyd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 178

 Description   

Currently, dynamic page generation with facelets is a big pain. I'm talking
about including an XML stream that is generated on the fly. The only way I've
figured out to accomplish it is by creating a custom URL type and tying the
resulting stream handler to an InputStream that is the result of the XML
generation (which usually comes from a byte[]), passing the whole works into
FacletContext.includeFacelet(UIComponent,URL).

It would be much better if there was, say, a
FaceletContext.includeFacelet(UIComponent,javax.xml.stream.XMLStreamReader) or
FaceletContext.includeFacelet(UIComponent,org.xml.sax.XMLReader).

This would be very helpful to anyone making components that are compositions of
other components, or who are including dynamic content that is generated at runtime.






[FACELETS-174] Components can't output ~facelets.VIEW_STATE~ Created: 19/Oct/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Trivial
Reporter: rogerkeays Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 174

 Description   

I recently had to include the string facelets.VIEW_STATE in a post to a
facelets-powered defect tracker. The problem, of course is that it gets
substituted to a hidden input field by the FaceletsViewHandler.

Would it be better to use a key like <facelets.VIEW_STATE/>? That way if
components actually wanted to display this string they would have to use
<...> and it wouldn't get substituted. I'm not away of any XML dialect
where this is a valid element






[FACELETS-169] Add support for <f:phaseListener> Created: 16/Oct/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: New Feature Priority: Major
Reporter: dmlloyd Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 169

 Description   

Right now, attempting to use <f:phaseListener> from facelets gives:

<f:phaseListener> Tag Library supports namespace: http://java.sun.com/jsf/core,
but no tag was defined for name: phaseListener

This would be a nice tag to add.






[FACELETS-163] unnecessary import of com.sun.faces.util.DebugUtil Created: 15/Sep/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Task Priority: Major
Reporter: ajesse Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 163

 Description   

Playing around with the facelets-build I found that com.sun.faces.util.DebugUtil
is imported in two classes (com.sun.facelets.tag.ui.UITestCase and
com.sun.facelets.FaceletTestCase) but not used.

As these classes reference packages not found in the minimal dependencies listed
(refer to jsf-ri impl) the import-statements should be removed.

PS: looking at the eclipse-pointers there seem to be more unused
import-statements around...



 Comments   
Comment by jhook [ 23/Sep/06 ]

changing to task from defect





[FACELETS-162] Calling HttpServletResponse.reset() causes IllegalStateException in portlet context Created: 14/Sep/06  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: enchos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File bug162.txt    
Issuezilla Id: 162

 Description   

When facelets is in developmentMode and trys to handle an exception, it calls
HttpServletResponse.reset(), which causes an IllegalStateException in my portlet
enviroment, WebSphere Portal 5.1. My guess for the error: The portal has already
sent content to the client, therefore calling reset is not legal. A check if
content has already been sent may suffice.
The real problem with this: I don't get to see the causing exception.



 Comments   
Comment by jhook [ 23/Sep/06 ]

starting, attempting to wrap clause in "httpResp.isCommitted()"

Comment by enchos [ 24/Sep/06 ]

Wrapping in isCommitted() helps. But unfortunatly there are several other places
where Facelets tries to set headers where it isn't allowed to do so. While it is
possible to wrap most of them with a committed check, this didn't work for the
ui:debug popup.

Comment by falcopaul [ 31/Oct/06 ]

Created an attachment (id=60)
Very likely solution to this bug

Comment by youngm [ 08/Apr/07 ]

As falcopaul suggests try creating a larger buffer. If problem persists we'll
reopen.

Comment by enchos [ 11/Apr/07 ]

The buffer setting doesn't help at all in a portlet enviroment (see initial
comment). The portlet container simply throws this exception when trying to use
the buffer:
java.lang.IllegalStateException: portlet container does not support buffering





[FACELETS-161] facelets composition template="/index.htm" with dwr2.0 ajax framework work conflict Created: 10/Sep/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: icypure Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 161

 Description   

When I use facelets1.1.5 with myface1.1.2 and dwr2.0 build web
applications,then use
facelets composition template="/index.htm" with dwr2.0 ajax framework work
conflict,make dwr2.0 to generate [Object errors],but I remove
template="/index.htm" ,so dwr work well. I think facelets framework view tech
should work with ajax framework very well






[FACELETS-158] facelets bean shell bsh doesn't work with latest retroweaver libs Created: 02/Sep/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: mgrouch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 158

 Description   

facelets bean shell bsh doesn't work with latest retroweaver libs,
I had to download very old retroweaver-ng version in order to make it work.
--MG






[FACELETS-156] Hole in JSTL forEach syntax verification Created: 01/Sep/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Trivial
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ForEachHandler.patch    
Issuezilla Id: 156

 Description   

I had declared 'items' attribute by mistake as 'value' and got mysterious
ArrayIndexOutOfBoundsException when temporary iteration source was tried to be
installed with Integer.MAX_VALUE + 1.

The specification states (as below) that both 'begin' and 'end' are required
when 'items' doesn't exist so the patching could be something similar as
proposed at the bottom.

Syntax 1: Iterate over a collection of objects
<c:forEach[var=�varName�] items=�collection� [varStatus=�varStatusName�]
[begin=�begin�] [end=�end�] [step=�step�]>
body content
</c:forEach>
Syntax 2: Iterate a fixed number of times
<c:forEach [var=�varName�][varStatus=�varStatusName�] begin=�begin� end=�end�
[step=�step�]>
body content
</c:forEach>

  • * *

#P facelets
Index: src/java/com/sun/facelets/tag/jstl/core/ForEachHandler.java
===================================================================
RCS file:
/cvs/facelets/src/java/com/sun/facelets/tag/jstl/core/ForEachHandler.java,v
retrieving revision 1.8
diff -u -r1.8 ForEachHandler.java
— src/java/com/sun/facelets/tag/jstl/core/ForEachHandler.java 19 Mar 2006
03:11:34 -0000 1.8
+++ src/java/com/sun/facelets/tag/jstl/core/ForEachHandler.java 1 Sep 2006
06:56:17 -0000
@@ -94,11 +94,11 @@
this.varStatus = this.getAttribute("varStatus");
this.tranzient = this.getAttribute("transient");

  • if (this.items == null && this.begin != null && this.end == null)
    Unknown macro: {+ if (this.items == null && (this.begin == null || this.end == null)) { throw new TagAttributeException( this.tag, - this.begin, - "If the 'items' attribute is not specified, but the 'begin' attribute is, then the 'end' attribute is required"); + this.items, + "If the 'items' attribute is not specified, both the 'begin' attribute and the 'end' attribute are required"); } }


 Comments   
Comment by tuomas_kiviaho [ 26/Sep/07 ]

Created an attachment (id=104)
ForEachHandler.patch

Comment by tuomas_kiviaho [ 26/Sep/07 ]

Refreshed the patch against current trunk.





[FACELETS-155] Optimization for DefaultFaceletFactory.needsToBeRefreshed(..) Created: 26/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: enorman Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 155

 Description   

For facelets whose source is a (non-local) URL, the connection should utilize
the 'ifModifiedSince' field so the URL target can do less work to return the
lastModified timestamp.

The modified method is below:

protected boolean needsToBeRefreshed(DefaultFacelet facelet) {
if (this.refreshPeriod != -1) {
long ttl = facelet.getCreateTime() + this.refreshPeriod;
if (System.currentTimeMillis() > ttl) {
try

{ URLConnection facetConnection = facelet.getSource().openConnection(); facetConnection.setIfModifiedSince(ttl); long atl = facetConnection.getLastModified(); return atl > ttl; }

catch (Exception e)

{ throw new FaceletException( "Error Checking Last Modified for " + facelet.getAlias(), e); }

}
}
return false;
}






[FACELETS-153] string index out of bounds exception Created: 21/Aug/06  Updated: 14/Jun/07

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: testtest Assignee: Ryan Lubke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 153

 Description   

Unlike the default jsf impl 1.1 facelts viewrenderer expects an extension on
the "to-view-id" does not contain an extension it throws an exception

string index out of bounds exception -1

caused due to line 746 of the FaceletViewHandler

String facesSuffix = actionId.substring(actionId.lastIndexOf('.'));

this should have a catch instead of an expectation such as:

if(actionId.lastIndexOf('.')>-1){
String facesSuffix = actionId.substring(actionId.lastIndexOf('.'));
}

since it is the substring that throws the exception when there is none

also be careful since many files these days contain periods even when not an
extension

to be honest dont know the reason for this code anyways

if (extCtx.getRequestPathInfo() == null)

{ String facesSuffix = actionId.substring(actionId.lastIndexOf('.')); String viewSuffix = this.getDefaultSuffix(context); viewId = actionId.replaceFirst(facesSuffix, viewSuffix); }

You are replacing the to-view-id's file extension with the default suffix init
parm - question is why?



 Comments   
Comment by Ryan Lubke [ 14/Jun/07 ]

It replaces the FacesServlet extension mapping with javax.faces.DEFAULT_SUFFIX
in order to know the actual resource to dispatch the request to.

Facelets requiring the extension mapping of the FacesServlet is a chosen design,
therefore, I think it's a misconfiguration to use anything but extension mapping.

A better error message could be returned for the case where there is no extension.





[FACELETS-151] disabling javascript in facelets Created: 10/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: www
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: New Feature Priority: Major
Reporter: jdoperei Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 151

 Description   

Hello all,
is there anyway by which we can disable javascript creation with facelets?
We are not using myfaces so the org.apache.myfaces.ALLOW_JAVASCRIPT parameter
doesn't work.

Thank's in advance






[FACELETS-150] Conflicting prefix of namespace Created: 09/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: jsf
Affects Version/s: ALL
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: m4c0 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 150

 Description   

Hi there,

I tryed to use JSF+Facelets+Blueprints, and I found that both Facelets and
Blueprints uses the "ui" prefix as default. IMHO, since both products will
became part of JavaEE in near future, I guess somebody will have to change the
prefix. I'll send this issue to both projects, just in case.

Regards,
Eduardo






[FACELETS-149] Mavenisizing 2.0 pom.xml for the project Created: 08/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File pom.xml    
Issuezilla Id: 149

 Description   

It would be nice to see a real pom.xml instead/alongside of the current template.



 Comments   
Comment by tuomas_kiviaho [ 08/Aug/06 ]

Created an attachment (id=53)
Just an example.





[FACELETS-148] Failsafe JSF version checking for ELAdapter Created: 08/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Task Priority: Major
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ELAdapter.patch    
Issuezilla Id: 148

 Description   

ELAdapter retrieves ELContext from Application if JSF API is 1.2. This is ok,
but this seems to be the one of the places where the backwards compatibility is
just throwing of UnsupportedOperationException when the JSF implementation is
1.1. This simple patch fall back to adapting the ELContext in such case.



 Comments   
Comment by tuomas_kiviaho [ 08/Aug/06 ]

Created an attachment (id=52)
ELAdapter.patch





[FACELETS-147] ui:define not recognized if in same file as ui:insert Created: 07/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: jaypeevoss Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 147

 Description   

Contents of file A.xhtml:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets">
<body>
<ui:insert name="b"/>
</body>
</html>

Contents of file B.xhtml:

<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets" template="A.xhtml">

<ui:define name="b">
<ui:insert name="c"/>
</ui:define>

</ui:composition>

Contents of file C.xhtml:

<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets" template="B.xhtml">

<ui:define name="c">
<ui:insert name="d"/>
</ui:define>

</ui:composition>

Contents of file D.xhtml:

<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets" template="C.xhtml">

<ui:define name="d">Success!</ui:define>

</ui:composition>

Calling D.jsf gives the expected result. The same works if the <ui:define>
line from D.xhtml is moved inside the <ui:composition> element of B.xhtml,
but not if moved to the <ui:composition> element of C.xhtml.






[FACELETS-145] Changing component tree not possible through ui:repeat or c:forEach Created: 01/Aug/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: ve_rao Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive facelets-issues.zip     Text File UIRepeat.patch    
Issuezilla Id: 145

 Description   

To modify the component tree each time the page rendered, it appears that the
<ui:repeat> and <c:forEach> tags may not be applicable currently. Here are two
problems. I have created a test case project. Instructions for running the test
case given at the end of this report

-------------------------------------------------------------------
-------- Facelets Problem 1 : rendered=false code executed --------
-------------------------------------------------------------------

My code inside a "rendered" flag is getting invoked even when the condition
is false. I am iterating over a list of Graphics objects to display
information about each by calling the object specific methods. The code
works fine if I use only <h:outputText>. If I use <h:inputText> however, the
rendered property does not seem to be taking effect.

<ui:repeat var="graphicsObj" value="#

{gfx.graphicsObjList}

">

<h:panelGroup rendered="#

{graphicsObj.objType == 'circle'}

" >
[Circle] Radius: <h:outputText value="#

{graphicsObj.radius}"/>
</h:panelGroup>

<h:panelGroup rendered="#{graphicsObj.objType == 'rectangle'}" >
[Rectangle] Length: <h:outputText value="#{graphicsObj.length}"/>
</h:panelGroup>

</ui:repeat>

The above works fine, as expected. However, if I change from <h:outputText>
to <h:inputText>, it complains :

javax.faces.el.PropertyNotFoundException: /facelets-render-problem.xhtml @24,54
value="#{graphicsObj.radius}

": Bean: Rectangle, property: radius

So, the first block of code is getting executed for a Rectangle object when
using a <h:inputText> but not when using <h:outputText>.

---------------------------------------------------------------------
----- Facelets Problem 2 : Problems with c:forEach component tree —
---------------------------------------------------------------------

To overcome the above problem, I am using <c:forEach> and <c:if> as in
the code below. It solves the problem of displaying <h:inputText>
conditionally. However, if the graphics list is modified during an
action callback, and the page is re-rendered, I see the following
problem. This problem appears to be the same nature as in the
ui:repeat.

01:12:00,953 ERROR [RendererUtils] Property not found - called by component :

{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /cforEach- problem.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id2][Class: javax.faces.component.html.HtmlOutputText,Id: _id23]}

javax.faces.el.PropertyNotFoundException: /cforEach-problem.xhtml @30,74
value="#

{graphicsObj.length}

": Bean: Circle, property: length

---------------------------------------------------------------------
----------- Installing and Running the Test Case project ------------
---------------------------------------------------------------------

The attached zip file contains the test cases for the above two
problems. JBoss and Seam are used for the probject. To run the
application, please edit the build.properties, and access the
application at http://localhost:xxxx/facelets-issues



 Comments   
Comment by ve_rao [ 01/Aug/06 ]

Created an attachment (id=51)
Contains the full test case project

Comment by buckmin [ 03/Jan/08 ]

Created an attachment (id=109)
JSF Specs tell in UIData like components, state saving of EditableValueHolders should be done by saving their localValue, not Value. This resolves the exceptions.





[FACELETS-139] developerMode assumes response with text/html content type support Created: 17/Jul/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Trivial
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 139

 Description   

I get following stacktrace when applying developer mode in a portlet that
doesn't support text/html content type. HTML debug dump could catch and warn
about result of the content type setting.

java.lang.IllegalArgumentException: Specified content type 'text/html' is not
supported.
at
org.apache.pluto.internal.impl.RenderResponseImpl.setContentType(RenderResponseImpl.java:124)
at
com.sun.facelets.FaceletViewHandler.handleRenderException(FaceletViewHandler.java:675)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:646)

Workaround: disabling of developer mode or overriding
FaceletViewHandler.handleRenderException






[FACELETS-138] multiple ResourceResolvers Created: 17/Jul/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: impl
Affects Version/s: ALL
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: brondsem Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File multiple resource resolvers - documentation.patch     Text File multiple resource resolvers.patch    
Issuezilla Id: 138

 Description   

facelets.RESOURCE_RESOLVER as a semicolon-delimited list of resolvers



 Comments   
Comment by brondsem [ 17/Jul/06 ]

Created an attachment (id=48)
implements a list of resource resolvers

Comment by brondsem [ 17/Jul/06 ]

Created an attachment (id=49)
documentation update





[FACELETS-136] docbook needs href'd links Created: 10/Jul/06  Updated: 02/Aug/12

Status: Open
Project: facelets
Component/s: www
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Bug Priority: Major
Reporter: mkienenb Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 136

 Description   

Table 1.1. Facelets Dependencies should have real links for the items in the
links column.

There's a bunch of plain-text "links" in the body of the document that should be
made into real links as well. Links to examples, and downloads, and such.



 Comments   
Comment by mkienenb [ 10/Jul/06 ]

oops. premature submit.





[FACELETS-135] Would like to specify when a Facelet should not be cached Created: 07/Jul/06  Updated: 02/Aug/12

Status: Reopened
Project: facelets
Component/s: impl
Affects Version/s: Facelets 1.1
Fix Version/s: early access

Type: Improvement Priority: Major
Reporter: randy_simon Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 135

 Description   

We are using Facelets as the basis for a page assembly framework. Essentially
what is happening is that a user is creating a page.xhtml file where the
contents of the file is simply a combination of <ui:composition>,
<ui:decorate>, <ui:define> and custom tags.

By creating a custom implementation of the ResourceResolver this was fairly
straight-forward. Now the issue…

Consider the page “pageA.xhtml�. Now let’s say that you have two users
accessing this page “user1� and “user2�. The first time the page is accessed
by user1 the facelet (com.sun.facelets.Facelet) does not already exist in the
cache of facelets maintained by the FaceletFactory implementation
(com.sun.facelets.impl.DefaultFaceletFactory) so the call to getFacelet(String
uri) ends up creating the facelet and putting it in the cache. When user2
tries to access pageA.xhtml the page is found in the cache and loaded.
Everything is good so far.

Now, user2 decides that he wants to change the page which is done in memory.
So user2 gets his own copy of the page and subsequent requests for the page
result in pulling the page object from the session instead of the DB. While
user2 is editing the page, perhaps adding a new component to the page, user1
refreshes the page and sees the new component which is bad because user2 hasn’t
actually saved his changes yet.

The problem specifically is in this code in DefaultFaceletFactory.

public Facelet getFacelet(URL url) throws IOException, FaceletException,
FacesException, ELException {
ParameterCheck.notNull("url", url);
DefaultFacelet f = (DefaultFacelet) this.facelets.get(url);
if (f == null || this.needsToBeRefreshed(f))

{ f = this.createFacelet(url); this.facelets.put(url, f); }

return f;
}

Since the facelets cache is application scope, when the page renders for user2
the constructed Facelet is saved in the cache so that any request for a page
with the same url results in the getting the latest version of the Facelet even
though the changes made were only meant to be seen by the editing user.

One hacky way to solve this would be to mangle the url for user2 so that it is
different from the read only version. However, if multiple users are editing
the same page at the same time I need to mangle the url differently and we
could end up with many copies in the cache that would equate to a memory leak.

What I would like is to do is one of two things:
1. Somehow specify that the facelet should be cached in session scope
instead of application scoped.
2. Somehow specify that the facelet should just not be cached at all.

I would imagine that #2 is a little simpler.

One way that I could do this would be to just provide my own implementation of
the FaceletContext, FaceletFactory and Facelet classes. However, this seems
like overkill when really all I want to do is override the getFacelet(URL)
method. Overriding is not an option since DefaultFaceletFactory is a final
class.

I think what I really need is a way to hook into the behavior of the getFacelet
(URL). Perhaps in web.xml I could just specify that all urls that start with
some token (eg. /edit/*) should not be cached. Then, in my custom
ResourceResolver I could change the resolve URLs differently for Facelets that
I do not want cached. It doesn’t have to be a token either, it could be a
query parameter or a specify protocol instead.

I am wondering if any one else has come across this issue. If so, perhaps they
have a better idea on how to solve it. I would be more than happy to add this
enhancement myself if you think that my solution is sufficient.

Thanks,
Randy



 Comments   
Comment by jhook [ 14/Jul/06 ]

You can override the FaceletViewHandler and provide your own extended
FaceletFactory to your application that selectively caches based on other
business rules (override the method below basically)

Comment by randy_simon [ 14/Sep/06 ]

Thanks you for your comments. I find that the problem with your suggestion is
that DefaultFace