[jira] Commented: (MYFACES-2431) NotSerializableException on state serialization
[ https://issues.apache.org/jira/browse/MYFACES-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12802739#action_12802739 ] Michael Kurz commented on MYFACES-2431: --- The problem is fixed with current version in trunk. NotSerializableException on state serialization --- Key: MYFACES-2431 URL: https://issues.apache.org/jira/browse/MYFACES-2431 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Kurz I have troubles with the serialization of the state in the session. Every time the state should be stored the following exception is thrown in DefaultFaceletsStateManagementHelper.serializeView(): java.io.NotSerializableException: javax.faces.component.UIPanel. This seems to happen on all pages of my app. This has some nasty side effects like the death of the view scope for instance. Setting org.apache.myfaces.SERIALIZE_STATE_IN_SESSION in the web.xml resolves this issue but this is not so easy to find out... Anyway, something seems to be wrong here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2497) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields -- Key: MYFACES-2497 URL: https://issues.apache.org/jira/browse/MYFACES-2497 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Ingo Hofmann Similar issue as seen in 1.1.6 and 1.2.6. 1.) set property javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL = true. 2.) Have an input field with required=true. 3.) User enters empty string. 4.) After submitted the form, the input field shows its previous value (is not empty, as entered before and expected). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACESTEST-2) when i use apache-ode-jbi component invoke a external webservice in servicemix,error is unknown endpoint
when i use apache-ode-jbi component invoke a external webservice in
servicemix,error is unknown endpoint
-
Key: MYFACESTEST-2
URL: https://issues.apache.org/jira/browse/MYFACESTEST-2
Project: Apache MyFaces Test
Issue Type: Bug
Environment: servicemix3.3,apache-ode-jbi-1.3.3
Reporter: liminjing
hello everyone:
i write an bpel process named example.bpel,which invoke an external webservice,
i use service-http component to bind the external webservice , it deployed
successful,but when i call the bpel process in client,it display the following
error:
org.apache.ode.bpel.iapi.Scheduler$JobProcessorException: java.lang.RuntimeExcep
tion: org.apache.ode.bpel.iapi.ContextException: Unknown endpoint: {http://servi
ce.flow.cvicse.com}CSService:CS
at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:452)
at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerIm
pl.java:441)
at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleSchedu
ler.java:411)
at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleSchedu
ler.java:405)
at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(Simpl
eScheduler.java:218)
at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleSchedule
r.java:404)
at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleSchedule
r.java:401)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: org.apache.ode.bpel.iapi.ContextException
: Unknown endpoint: {http://service.flow.cvicse.com}CSService:CS
at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:4
64)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntime
ContextImpl.java:875)
at org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(Pa
rtnerLinkMyRoleImpl.java:206)
at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java
:237)
at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.ja
va:408)
at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:439)
... 11 more
Caused by: org.apache.ode.bpel.iapi.ContextException: Unknown endpoint: {http://
service.flow.cvicse.com}CSService:CS
at org.apache.ode.jbi.JbiEndpointReference.getServiceEndpoint(JbiEndpoin
tReference.java:99)
at org.apache.ode.jbi.JbiEndpointReference.toXML(JbiEndpointReference.ja
va:64)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.invoke(BpelRuntimeC
ontextImpl.java:777)
at org.apache.ode.bpel.runtime.INVOKE.run(INVOKE.java:100)
at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:4
51)
... 17 more
-
i think the error maybe caused by the endpoint , i use xbean.xml in the
servicemix-http su,it following:
beans xmlns:http=http://servicemix.apache.org/http/1.0;
xmlns:Me=http://service.flow.cvicse.com;
http:endpoint service=Me:CSService
endpoint=Me:CS
role=provider
locationURI=http://localhost:8081/ConcatString/services/CS?wsdl;
defaultMep=http://www.w3.org/2004/08/wsdl/in-out;
soap=true
wsdlResource=classpath:CS.wsdl /
/beans
---
2 the cs.wsdl in the ode component is
?xml version=1.0 encoding=UTF-8 ?
wsdl:definitions targetNamespace=http://service.flow.cvicse.com;
xmlns:apachesoap=http://xml.apache.org/xml-soap;
xmlns:impl=http://service.flow.cvicse.com;
xmlns:intf=http://service.flow.cvicse.com;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:smix=http://servicemix.org/wsdl/jbi/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
wsdl:types
schema elementFormDefault=qualified
targetNamespace=http://service.flow.cvicse.com;
xmlns=http://www.w3.org/2001/XMLSchema;
element name=concatString
complexType
sequence
element name=param type=xsd:string /
/sequence
/complexType
/element
element name=concatStringResponse
[jira] Commented: (MYFACES-2497) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields
[
https://issues.apache.org/jira/browse/MYFACES-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12802782#action_12802782
]
Ingo Hofmann commented on MYFACES-2497:
---
Fix:
Add in myfaces-api - javax.faces.component.UIInput.validate(FacesContext
context) the line setValue(null) as you can see below:
String contextParam =
context.getExternalContext().getInitParameter(EMPTY_VALUES_AS_NULL_PARAM_NAME);
if (contextParam != null
contextParam.toLowerCase().equals(true))
{
if (submittedValue.toString().length() == 0)
{
setSubmittedValue(null);
submittedValue = null;
setValue(null);
}
}
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields
--
Key: MYFACES-2497
URL: https://issues.apache.org/jira/browse/MYFACES-2497
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Ingo Hofmann
Attachments: interpret_empty_string_testcase.patch
Similar issue as seen in 1.1.6 and 1.2.6.
1.) set property javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
= true.
2.) Have an input field with required=true.
3.) User enters empty string.
4.) After submitted the form, the input field shows its previous value (is
not empty, as entered before and expected).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2497) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields
[ https://issues.apache.org/jira/browse/MYFACES-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12802791#action_12802791 ] Matthias Weßendorf commented on MYFACES-2497: - MyFAces implements the exact algorithm as defined in the spec. More info here: https://issues.apache.org/jira/browse/TRINIDAD-1601 INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields -- Key: MYFACES-2497 URL: https://issues.apache.org/jira/browse/MYFACES-2497 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Ingo Hofmann Attachments: interpret_empty_string_testcase.patch, interpret_empty_strings_setValue.patch Similar issue as seen in 1.1.6 and 1.2.6. 1.) set property javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL = true. 2.) Have an input field with required=true. 3.) User enters empty string. 4.) After submitted the form, the input field shows its previous value (is not empty, as entered before and expected). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1690) ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called
ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called -- Key: TRINIDAD-1690 URL: https://issues.apache.org/jira/browse/TRINIDAD-1690 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core , 2.0.0.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called by the resource servlet. This makes it extremely difficult for the resource loader to specify the MIME type for a resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoc] Google Summer of Code Idea
Hi all, I sent a couple of mails about MyFaces on Google App Engine GSOC proposal. But after some progress and a conversation with Matthias, I realized that it is too small for GSOC. And I am willing to implement HTML5 Renderkit. Meanwhile, I will work on GAE support in parallel. I will post my patch to JIRA after some -more- tests. Regards, Ali On Wed, Jan 6, 2010 at 11:52 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/1/6 Matthias Wessendorf mat...@apache.org as the mentioned behavior support already said, I'd like to see this ONLY for JSF2.0 (MyFaces 2.0) -Matze On Wed, Jan 6, 2010 at 8:35 AM, Matthias Wessendorf mat...@apache.org wrote: Hi guys, running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. What do folks think about that? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2498) Myfaces should be able to gracefully handle a runtime with the bean validation API on the classpath but no impl
Myfaces should be able to gracefully handle a runtime with the bean validation API on the classpath but no impl --- Key: MYFACES-2498 URL: https://issues.apache.org/jira/browse/MYFACES-2498 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini MyFaces does not tolerate well having the bean validation API on the classpath when there is no JSR 303 impl in place. As it stands currently, we will fail rendering any page that includes validation, whether or not it includes JSR 303 validation. We should fail more gracefully with a warning during the first attempt at initialization by the static method in org.apache.myfaces.ExternalSpecifications. There is already some code commented out which essentially does this check. It appears it was only commented out due to the validation api not being on the myfaces impl classpath. I'll use this bug to uncomment that code and to update the pom to include a dependency on the bean validation api as in the myfaces api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2498) Myfaces should be able to gracefully handle a runtime with the bean validation API on the classpath but no impl
[ https://issues.apache.org/jira/browse/MYFACES-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini resolved MYFACES-2498. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Myfaces should be able to gracefully handle a runtime with the bean validation API on the classpath but no impl --- Key: MYFACES-2498 URL: https://issues.apache.org/jira/browse/MYFACES-2498 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.0-alpha-2 MyFaces does not tolerate well having the bean validation API on the classpath when there is no JSR 303 impl in place. As it stands currently, we will fail rendering any page that includes validation, whether or not it includes JSR 303 validation. We should fail more gracefully with a warning during the first attempt at initialization by the static method in org.apache.myfaces.ExternalSpecifications. There is already some code commented out which essentially does this check. It appears it was only commented out due to the validation api not being on the myfaces impl classpath. I'll use this bug to uncomment that code and to update the pom to include a dependency on the bean validation api as in the myfaces api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RESULT] [VOTE] Release Tobago 1.0.24 second try
The vote has passed with the following results: +1 matzew (binding) weber (binding) lofwyr (binding) bommel (binding) I will proceed with the next steps. Regards Bernd On Mon, Jan 18, 2010 at 11:30 AM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Bernd Bohmann schrieb: Here is my +1 On Sat, Jan 16, 2010 at 11:17 AM, Matthias Wessendorf mat...@apache.org wrote: +1 On Sat, Jan 16, 2010 at 11:14 AM, Volker Weber v.we...@inexso.de wrote: Hi, +1 our app with this rc has passed the tests. Regards, Volker 2010/1/15 Bernd Bohmann bernd.bohm...@atanion.com: Hello, I would like to release Tobago 1.0.24. I have removed the changes for TOBAGO-811 in 1.0.24 and scheduled to 1.0.25. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314193 The version is available at the staging location and the revision number of the release is 898929 and tagged as tobago-1.0.24. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1550) convertDateTime handles type=date incorrectly
[
https://issues.apache.org/jira/browse/TRINIDAD-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803018#action_12803018
]
Yee-Wah Lee commented on TRINIDAD-1550:
---
Agreed that in the case when type=time, the Trinidad converter does generate
value change because it doesn't try to preserve the date values.This is
inconsistent with type=date.
One workaround I can think of is to zero out the hour, minute, second,
millisecond fields of the dateCal. That should work regardless which renderkit
is used.
Or, try to avoid picking up the trinidad date-time converter which may be only
available in JSF 2.0 since the Trinidad framework registers its
datetimeConverter as the default (so that f:convertDateTime picks it up).
convertDateTime handles type=date incorrectly
---
Key: TRINIDAD-1550
URL: https://issues.apache.org/jira/browse/TRINIDAD-1550
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.10-core
Environment: Linux 64-bit, Java 1.5.0_11
Reporter: Eric Price
Priority: Minor
I have a backing bean that contains two HtmlInputText components. One stores
the date part of a Date, the other stores the time part of a Date. When
the user enters the information, the date and time are combined to form
the actual Date.
The bean has the following declarations:
public class DateTestBean {
private HtmlInputText dateInput = null;
private HtmlInputText timeInput = null;
private Date date = null;
private Date time = null;
public DateTestBean() {
dateInput = new HtmlInputText();
timeInput = new HtmlInputText();
date = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
time = (Date)date.clone();
}
}
For my sample program, I have a button on the jsp that calls the action
method setDateAction() to update the date/time values with current values.
That method is shown below:
public String setDateAction() {
Calendar dateCal = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
Calendar timeCal = (Calendar)dateCal.clone();
dateInput.setValue( dateCal.getTime() );
timeInput.setValue( timeCal.getTime() );
date = dateCal.getTime();
time = timeCal.getTime();
return success;
}
There is a corresponding action method associated with a submit button on the
jsp that prints the date/time values when the page is submitted.
public String displayDateAction() {
Object valObj = this.dateInput.getValue();
if (valObj instanceof Date) {
System.out.println( date= + formatDate( (Date)valObj ) );
}
valObj = this.timeInput.getValue();
if (valObj instanceof Date) {
System.out.println( time= + formatDate( (Date)valObj ) );
}
}
Here is the code snipit from the jsp:
t:panelGrid columns=2
t:inputText binding=#{dateTestBean.dateInput} size=10 maxlength=10
immediate=true value=#{dateTestBean.date} title=-MM-dd
id=dateInput
f:convertDateTime type=date pattern=-MM-dd/
/t:inputText
t:inputText binding=#{dateTestBean.timeInput} size=8 maxlength=8
immediate=true value=#{dateTestBean.time} title=HH:mm:ss
id=timeUpStartTimeInput
f:convertDateTime type=time pattern=HH:mm:ss/
/t:inputText
/t:panelGrid
t:panelGrid columns=2
t:commandButton value=Set Date action=#{dateTestBean.setDateAction}/
t:commandButton value=Show Date
action=#{dateTestBean.displayDateAction}/
/t:panelGrid
When I submit the page, I see different values for the date and time
depending on whether or not I'm using the trinidad rendering kit.
When the page loads the date and time fields are set to the correct date
and time values. When the page is submitted, I see the following:
Under MyFaces 1.1.4 (or JSF 1.1), Java 1.5, tomahawk 1.1.3 and assuming the
date was 12:20:32 on Aug 4th 2009, I get:
date = '2009-08-04 00:00:00'
time= '1970-01-01 12:20:32'
Similarly, under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, tomahawk 12-1.1.8 and
assuming the date was 12:20:32 on Aug 4th 2009, I get:
date = '2009-08-04 00:00:00'
time= '1970-01-01 12:20:32'
So if I combine the two values when the page is submitted, I end up with
'2009-08-04 12:20:32', which is the correct submit date/time.
Under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, trinidad-1.2.10, and assuming the
same date/time values are set, I get:
date= '2009-08-04 12:20:32'
time= '1970-01-01 12:20:32'
So the convertDateTime with type=date is not zero-ing out the time field
values, but the one with type=time is zero-ing out the date field values.
I've done a lot of testing and originally thought the problem with with
myFaces 1.2. But I eventually
[jira] Resolved: (MYFACES-2410) f:validateBean does not work as container for EditableValueHolders
[ https://issues.apache.org/jira/browse/MYFACES-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2410. Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Fixed this issue. However, there are some other issues with bean validation. f:validateBean does not work as container for EditableValueHolders -- Key: MYFACES-2410 URL: https://issues.apache.org/jira/browse/MYFACES-2410 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Glassfish v3 prelude and JBoss 6.0.0.M1 Reporter: Jakob Korherr Fix For: 2.0.0-alpha-2 Testing the mojarra bean-validation sample on Glassfish v3 prelude and JBoss 6.0.0.M1, I ran into the following exception: javax.servlet.ServletException: /placeOrder.xhtmlat line 49 and column 109 f:validateBean Parent not composite component or an instance of EditableValueHolder: javax.faces.component.html.htmlf...@494c491b f:validateBean is used as a container of EditableValueHolders in the sample, the following code shoes where the error occurs: h:form f:validateBean validationGroups=beanvalidation.groups.Personal , beanvalidation.groups.Order ui:include src=/WEB-INF/fragments/form.xhtml/ /f:validateBean /h:form where ui:include src=/WEB-INF/fragments/form.xhtml/ includes a form of some h:inputText (-- EditableValueHolder) components. However, f:validateBean is also used inside of some of the h:inputText components and works well at this point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs.
[jira] Created: (MYFACES-2499) f:validateBean disabled=true not processed correctly
f:validateBean disabled=true not processed correctly
--
Key: MYFACES-2499
URL: https://issues.apache.org/jira/browse/MYFACES-2499
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha-2
Reporter: Jakob Korherr
In the following scenario the bean validator should not be applied for the
h:inputText.
h:inputText value=#{bean.text2}
f:validateBean disabled=true /
/h:inputText
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1668) Speed up UIXComponent.getId()
[ https://issues.apache.org/jira/browse/TRINIDAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-1668: - Status: Patch Available (was: Open) Speed up UIXComponent.getId() - Key: TRINIDAD-1668 URL: https://issues.apache.org/jira/browse/TRINIDAD-1668 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-plugins Environment: All Reporter: Blake Sullivan Attachments: JIRA_1668_1_2_12_2.patch Original Estimate: 24h Remaining Estimate: 24h UIComponent.getId() is by far the most requested component attribute. There are a number of reasons for this: 1) The JSF RI has an issue in the JSP-JSF integration which causes getId() to be called n^2 times where n is the number of children a component has 2) getClientId() calls getId() 3) FindComponent calls getId() 4) The tree visiting code trades off calls to getClientId() for calls to getId() FacesBean optimizes attribute Map access at the expense of access directly through the component. The the extent that Renderers are Components are accessing the attributes through the attribute Map, this is fine, however even the Renderers access attributes common to all UIComponents such as id() through the component directly. Considering the huge number of times that the the id is accessed (for some renders, this was 8% of the rendering time), it makes sense to optimize this path. The proposal is to: 1) Store the id an an instance variable on the UIXComponent 2) Add a new capability flag to PropertyKey indicating that the property is actually stored elsewhere using a ValueExpression will be stored as the property's value in the PropertyMap. For access through the FacesBean, the ValueExpression will be evaluated to get/set the actual value 3) For state saving the ValueExpression is used to retrieve the actual value and for state restoration the ValueExpression (which has been rebootstrapped by the UIXComponent) is used to write the value back 4) Instead of setting the id attribute in the FacesBean, UIXComponent stores it locally and sets an ValueExpression implementation into the FacesBean that retrieves the value from the UIXComponent API Changes: PropertyKey: add /** * Capability indicating that values for this property should be * be stored and retrieved through a ValueExpression rather than on the * FacesBean itself */ static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16; /** * Returns codetrue/code if property values for this key are set and get * using a ValueExpression rather than storing the value in the FacesBean. * @return codetrue/code if properties values for this key are retrieved * with a ValueExpression. */ public boolean usesValueExpressionAsImplementation() After this change id retrieval doesn't make the 1% YourKit profiler hot spot cut off -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1668) Speed up UIXComponent.getId()
[ https://issues.apache.org/jira/browse/TRINIDAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-1668: - Resolution: Fixed Status: Resolved (was: Patch Available) Implement JIRA-1668 by storing the id attribute on the UIXComponentBase itself and modifying the UIXFacesBeanImpl to delegate back to the UIXComponentBase for id access through the AttributeMap. I also cleaned up the way that ids and clientIds are generated so that getId() will never return a null id. In order to make the UIXComponentBase change backwards compatible, I moved the UIXFacesBeanImpl and UIXEditableFacesBeanImpl classes to api where our customers can take advantage of them and UIXComponentBase only caches the id locally if it is attached to an UIXFacesBeanImpl directly or indirectly through any levels of FacesBeanWrapppers. In addition, several tests should have been extending FacesTestCase and were not, so those are now fixed. Also, UIXEditableFacesBeanImpl now catches case where it is attached to a non UIXEditableValue component, which caught the fact that we had this incorrect entry: ### DON'T KNOW WHY THE NEXT LINE SHOULD BE NECESSARY! org.apache.myfaces.trinidad.component.UIXSelectRange|org.apache.myfaces.trinidad.ChoiceBar=org.apache.myfaces.trinidadinternal.bean.UIXEditableFacesBeanImpl in the faces-bean.properties Speed up UIXComponent.getId() - Key: TRINIDAD-1668 URL: https://issues.apache.org/jira/browse/TRINIDAD-1668 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-plugins Environment: All Reporter: Blake Sullivan Attachments: JIRA_1668_1_2_12_2.patch Original Estimate: 24h Remaining Estimate: 24h UIComponent.getId() is by far the most requested component attribute. There are a number of reasons for this: 1) The JSF RI has an issue in the JSP-JSF integration which causes getId() to be called n^2 times where n is the number of children a component has 2) getClientId() calls getId() 3) FindComponent calls getId() 4) The tree visiting code trades off calls to getClientId() for calls to getId() FacesBean optimizes attribute Map access at the expense of access directly through the component. The the extent that Renderers are Components are accessing the attributes through the attribute Map, this is fine, however even the Renderers access attributes common to all UIComponents such as id() through the component directly. Considering the huge number of times that the the id is accessed (for some renders, this was 8% of the rendering time), it makes sense to optimize this path. The proposal is to: 1) Store the id an an instance variable on the UIXComponent 2) Add a new capability flag to PropertyKey indicating that the property is actually stored elsewhere using a ValueExpression will be stored as the property's value in the PropertyMap. For access through the FacesBean, the ValueExpression will be evaluated to get/set the actual value 3) For state saving the ValueExpression is used to retrieve the actual value and for state restoration the ValueExpression (which has been rebootstrapped by the UIXComponent) is used to write the value back 4) Instead of setting the id attribute in the FacesBean, UIXComponent stores it locally and sets an ValueExpression implementation into the FacesBean that retrieves the value from the UIXComponent API Changes: PropertyKey: add /** * Capability indicating that values for this property should be * be stored and retrieved through a ValueExpression rather than on the * FacesBean itself */ static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16; /** * Returns codetrue/code if property values for this key are set and get * using a ValueExpression rather than storing the value in the FacesBean. * @return codetrue/code if properties values for this key are retrieved * with a ValueExpression. */ public boolean usesValueExpressionAsImplementation() After this change id retrieval doesn't make the 1% YourKit profiler hot spot cut off -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user. Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs.
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Do they? I always get confused by which is which between skin additions and skin extensions. Anyway, why wouldn't skin A' that extends Skin A pick up all of the extensions and additions to A? Or, is the case you are worried about that the customer has their own skin B that extends skin A but wants to pick up the changes available in A'. However, in that case, isn't the change still essentially one line? Instead of changing trinidad-config to point to A' (since it already points to B), the skinner changes skin B to extend A'? The reason I'm pushing back on this is that the skin files are confusing enough without adding skin versioning into the mix. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:09 PM PT: Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user. Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs.
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
If the application developer is injecting a skin addition into skin A and if skin B (aka version 2) extends from skin B then this is not an issue. However, if the application developer has created their own skin that extends skin A then the end user cannot choose skin B (aka version 2) because the application developer is not also providing a separate skin that extends skin B. One of the main reasons why applications will choose extending a skin over injecting a skin addition is that a skin addition does not guarantee any order in which the definitions will be injected into the skin so if there are competing definitions then it will be a matter of luck whether the application developer's definitions will win. However, by extending a skin, the application developer's definitions are guaranteed to override the existing selector of the base skins (provided the selectors are identical). In an ideal world, we wouldn't have a skin B (version 2) at all and the reasoning that the UI designer came up with the new design would be justification enough for why skin A needs to change. If there is no justification then we should push back on the UI designer or just live with there being a separate unrelated skin. Perhaps this isn't a very common use case to warrant a versioning system? Thanks, Matt On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Do they? I always get confused by which is which between skin additions and skin extensions. Anyway, why wouldn't skin A' that extends Skin A pick up all of the extensions and additions to A? Or, is the case you are worried about that the customer has their own skin B that extends skin A but wants to pick up the changes available in A'. However, in that case, isn't the change still essentially one line? Instead of changing trinidad-config to point to A' (since it already points to B), the skinner changes skin B to extend A'? The reason I'm pushing back on this is that the skin files are confusing enough without adding skin versioning into the mix. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:09 PM PT: Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user. Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivanblake.sulli...@oracle.com blake.sulli...@oracle.comwrote: Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs
Re: FaceletViewHandlingStrategy: cloneWithWriter() results in duplicate ResponseWriters
Just wanted to mention that I have logged this issue here: https://issues.apache.org/jira/browse/MYFACES-2500 Issue 2500. Pretty cool! :-) Andy
[jira] Created: (MYFACES-2500) ResponseWriter clone should not include itself
ResponseWriter clone should not include itself
--
Key: MYFACES-2500
URL: https://issues.apache.org/jira/browse/MYFACES-2500
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Priority: Minor
MyFaces suffers from the problem described here:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1515
Apologies for the Mojarra reference. :-)
In the MyFaces case, the problem exists in two places:
1. org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage
In particular, in renderView(), we do:
ResponseWriter origWriter = createResponseWriter(context);
StateWriter stateWriter = new StateWriter(origWriter, 1024);
Here
try
{
ResponseWriter writer = origWriter.cloneWithWriter(stateWriter);
Instead of wrapping the StateWriter around the ResponseWriter (and then cloning
that ResponseWriter with itself), we should be wrapping the StateWriter around
the Writer returned by ExternalContext.getResponseOutputWriter().
2. org.apache.myfaces.view.facelets.FaceletViewHandler
Again, in renderView, we've got:
ResponseWriter origWriter = this.createResponseWriter(context);
// QUESTION: should we use bufferSize? Or, since the
// StateWriter usually only needs a small bit at the end,
// should we always use a much smaller size?
stateWriter = new StateWriter(origWriter, this.bufferSize != -1 ?
this.bufferSize : 1024);
ResponseWriter writer = origWriter.cloneWithWriter(stateWriter);
So the same issue exists here.
FWIW, not sure whether FaceletViewHandler is still used - perhaps this is now
obsolete?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1691) Skinning framework support for skin versioning
[ https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803065#action_12803065 ] Jeanne Waldman commented on TRINIDAD-1691: -- Why isn't putting the version into the skin-family name good enough? skin-familypurple1.1.12.4/skin-family. It's not quite the same as versioning, since we wouldn't change the version number every time we release. Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1691) Skinning framework support for skin versioning
[ https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803068#action_12803068 ] Matt Cooper commented on TRINIDAD-1691: --- See a thread on this topic here: http://markmail.org/thread/cxzae34pt45k4j4i Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new changes would need to be made in a new skin even though that new skin might be 75% identical to the original skin. There is also a negative impact on customers that generate their own skin definitions when we introduce a new skin name. Every skin (or skin addition) that they have created won't be able to uptake the new designs unless they physically go in and change all references from the old skin name to whatever the new skin's name is. To remedy this while enabling the frozen state of the original designs, the skinning framework must support a concept of versioning. Since the nature of software means that code lines branch into a vast tree structure, the version numbers of the skinning framework must fulfill this need. A simple x.y will not be sufficient, we will require x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch off of the previous code branch, e.g. there will likely be a version that looks like 1.1.12.4. Customers will then need a configuration option where they can specify which version of the skin they want to use. (Presumably near the same location where they specify which skin name they want to use.) Business needs: Some customers need new UI designs applied to existing skins but other customers need the skin to remain unchanged. Versioning will allow customers to optionally buy-into the new UI designs while other customers can happily live with the past designs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoc] Google Summer of Code Idea
+1 2010/1/20 Ali Ok al...@aliok.com.tr Hi all, I sent a couple of mails about MyFaces on Google App Engine GSOC proposal. But after some progress and a conversation with Matthias, I realized that it is too small for GSOC. And I am willing to implement HTML5 Renderkit. Meanwhile, I will work on GAE support in parallel. I will post my patch to JIRA after some -more- tests. Regards, Ali On Wed, Jan 6, 2010 at 11:52 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/1/6 Matthias Wessendorf mat...@apache.org as the mentioned behavior support already said, I'd like to see this ONLY for JSF2.0 (MyFaces 2.0) -Matze On Wed, Jan 6, 2010 at 8:35 AM, Matthias Wessendorf mat...@apache.org wrote: Hi guys, running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. What do folks think about that? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Matt, I don't think that an explicit versioning scheme should be necessary. In your example, we have the base skin A, a version with big enough changes that the designer feels that it should have an new name, B, that extends A and an application extension of A, C. The issue is that the user of the application can't choose B immediately because the C extends the original skin A and not the new skin B. However, it would seem that the same logic that drove the original skin designer to create a new skin B rather than simply modifying skin A should apply in this case. If the changes were big enough for us to need a new skin, doesn't this imply that other extenders of the original skin should need to opt in as well? The changes that skin C made to change A may not be compatible with those made by skin B, so the application needs to verify this before making a new skin C' that extends B instead of A. The grossness here would be if the application wanted to make both skins C and C' available and thus wanted to share overrides between the two. However, the addition of inclusion support would presumably make any refactoring for sharing easy to take advantge of. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:35 PM PT: If the application developer is injecting a skin addition into skin A and if skin B (aka version 2) extends from skin B then this is not an issue. However, if the application developer has created their own skin that extends skin A then the end user cannot choose skin B (aka version 2) because the application developer is not also providing a separate skin that extends skin B. One of the main reasons why applications will choose extending a skin over injecting a skin addition is that a skin addition does not guarantee any order in which the definitions will be injected into the skin so if there are competing definitions then it will be a matter of luck whether the application developer's definitions will win. However, by extending a skin, the application developer's definitions are guaranteed to override the existing selector of the base skins (provided the selectors are identical). In an ideal world, we wouldn't have a skin B (version 2) at all and the reasoning that the UI designer came up with the new design would be justification enough for why skin A needs to change. If there is no justification then we should push back on the UI designer or just live with there being a separate unrelated skin. Perhaps this isn't a very common use case to warrant a versioning system? Thanks, Matt On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Do they? I always get confused by which is which between skin additions and skin extensions. Anyway, why wouldn't skin A' that extends Skin A pick up all of the extensions and additions to A? Or, is the case you are worried about that the customer has their own skin B that extends skin A but wants to pick up the changes available in A'. However, in that case, isn't the change still essentially one line? Instead of changing trinidad-config to point to A' (since it already points to B), the skinner changes skin B to extend A'? The reason I'm pushing back on this is that the skin files are confusing enough without adding skin versioning into the mix. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:09 PM PT: Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user. Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivanblake.sulli...@oracle.com blake.sulli...@oracle.comwrote: Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing component designs of the same existing skin. UI changes like this are sometimes considered to jarring for some customers and they would rather stick with the original designs. This means that skins are eternally frozen after their first release so any new
handling of a HTTP 304 not_modified in JspViewDeclarationLanguage ?
Hi folks! I'm not sure if the following is a desired behaviour, so please comment. I'm using the latest MyFaces-2.0.0-SNAPSHOT together with facelets-1.1.15b1, jetty-6.1.22 and RichFaces-3.3.3-Beta1. When I invoke a page, let's say localhost:8080/page.jsf the first time I call it all is ok. I get the desired page and all is fine. But If I invoke the page again (reloading or pressing enter in the url bar of my browser) the following happens (I'm not sure if this also happens with GET via viewId parameters, but think it will): 1.) The If-Modified-Since timestamp of the http request is still the same as before (and this does not get cleared) and 2.) will be passed over to the RequestDispatcher (to the page.xhtml) in JspViewDeclarationLanguage#buildView(). 3.) Jetty is so smart to detect that nothing has changed and returns a HTTP 304 (such a response contains headers only, NO CONTENT!). This causes a problem in 4.) the RichFaces ajax4jsf Filter which tries to reformat html to solid XML and thus crashes with an Exception because it tries to write to the response (which is immutable due to the 304). 5.) Somehow MyFaces seems to swallow this error (errorResponse is true) and renders the view from the old tree? As said above, I guess we will see this more often in JSF-2 due to the fact that GET will get more common... Question: Is MyFaces aware of handling a 304? Is this an expected response? If yes, then RichFaces folks (Alex Smirnov and Jay Balunas) needs to handle the 304 gracefully in their a4j Filter (might be a good idea anyway) If not, a possible solution would be to simply clean the If-Modified-Since header from the response before dispatching (workaround suggested by Greg Wilkins). Wdyt? A bug? A feature? (Btw: tried it with Mojarra-2.0.1 and all works ok) Hope this post didn't get too confusing ;) LieGrue, strub
Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning
Thanks Blake, that works for me. On Wed, Jan 20, 2010 at 5:41 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Matt, I don't think that an explicit versioning scheme should be necessary. In your example, we have the base skin A, a version with big enough changes that the designer feels that it should have an new name, B, that extends A and an application extension of A, C. The issue is that the user of the application can't choose B immediately because the C extends the original skin A and not the new skin B. However, it would seem that the same logic that drove the original skin designer to create a new skin B rather than simply modifying skin A should apply in this case. If the changes were big enough for us to need a new skin, doesn't this imply that other extenders of the original skin should need to opt in as well? The changes that skin C made to change A may not be compatible with those made by skin B, so the application needs to verify this before making a new skin C' that extends B instead of A. The grossness here would be if the application wanted to make both skins C and C' available and thus wanted to share overrides between the two. However, the addition of inclusion support would presumably make any refactoring for sharing easy to take advantge of. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:35 PM PT: If the application developer is injecting a skin addition into skin A and if skin B (aka version 2) extends from skin B then this is not an issue. However, if the application developer has created their own skin that extends skin A then the end user cannot choose skin B (aka version 2) because the application developer is not also providing a separate skin that extends skin B. One of the main reasons why applications will choose extending a skin over injecting a skin addition is that a skin addition does not guarantee any order in which the definitions will be injected into the skin so if there are competing definitions then it will be a matter of luck whether the application developer's definitions will win. However, by extending a skin, the application developer's definitions are guaranteed to override the existing selector of the base skins (provided the selectors are identical). In an ideal world, we wouldn't have a skin B (version 2) at all and the reasoning that the UI designer came up with the new design would be justification enough for why skin A needs to change. If there is no justification then we should push back on the UI designer or just live with there being a separate unrelated skin. Perhaps this isn't a very common use case to warrant a versioning system? Thanks, Matt On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivanblake.sulli...@oracle.com blake.sulli...@oracle.comwrote: Do they? I always get confused by which is which between skin additions and skin extensions. Anyway, why wouldn't skin A' that extends Skin A pick up all of the extensions and additions to A? Or, is the case you are worried about that the customer has their own skin B that extends skin A but wants to pick up the changes available in A'. However, in that case, isn't the change still essentially one line? Instead of changing trinidad-config to point to A' (since it already points to B), the skinner changes skin B to extend A'? The reason I'm pushing back on this is that the skin files are confusing enough without adding skin versioning into the mix. -- Blake Sullivan Matt Cooper said the following On 1/20/2010 3:09 PM PT: Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user. Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivanblake.sulli...@oracle.com blake.sulli...@oracle.com blake.sulli...@oracle.com blake.sulli...@oracle.comwrote: Matt, Why wouldn't it be sufficient for the new skin the extend the old? What problems does this add other than forcing customers to modify their trinidad-config to use the new skin name in order to opt in? -- Blake Sullivan Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: Skinning framework support for skin versioning -- Key: TRINIDAD-1691 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Matt Cooper UI designers periodically create new UI designs for various components with the goal of these designs being applied to a specific skin. Although the visual design might be completely new for a given component, it is really meant to be available in context of other existing
[jira] Created: (TRINIDAD-1692) remove newlines in css file if in compressed mode
remove newlines in css file if in compressed mode - Key: TRINIDAD-1692 URL: https://issues.apache.org/jira/browse/TRINIDAD-1692 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.2.12-core Reporter: Jeanne Waldman Assignee: Jeanne Waldman When the css styleclasses are compressed, optimize further by removing newlines. From Steve Souder's High Performance Website book, he recommends removing whitespace and comments from the css file to improve performance. The css file has newlines, which can be removed easily. Also, the comment at the top that says when the file is generated can be removed. The comment at the bottom with the number of selectors is useful. I look at that quite often. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] Committers Only - Need review for patches related to mobile development
Hi all, I have a few patches that need to be reviewed before I can commit it. All but one patches are related to mobile development: TRINIDAD-1619 - This patch applies to both desktop as well as mobile. The issue is a column's width is not rendered when all the columns of a table have empty headerText attributes TRINIDAD-1618 – For mobile browsers, styleClass for the detailstamp facet of tr:table is not rendered TRINIDAD-1617 – For mobile browsers, PPR is not supported in tr:panelTabbed TRINIDAD-1616 - Nokia S60 not supporting tr:navigationPane Thanks Mamallan
[jira] Commented: (TRINIDAD-1689) New Trinidad Default Skin - Casablanca
[ https://issues.apache.org/jira/browse/TRINIDAD-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803203#action_12803203 ] Marius Petoi commented on TRINIDAD-1689: I added a new patch with a small correction. I changed the place of the skin CSS and put it into resouces/META-INF/adf/styles. Also, I put the images in resources/META-INF/adf/images/casablanca. These are not included into the patch. In order for it to work, you need to take the images from the zip file and copy them into /resources/META-INF/adf/images/casablanca. You create there two new folders, background and icons and put the images there. New Trinidad Default Skin - Casablanca -- Key: TRINIDAD-1689 URL: https://issues.apache.org/jira/browse/TRINIDAD-1689 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.2.13-core Reporter: Adonis Raul Raduca Assignee: Catalin Kormos Fix For: 1.2.13-core Attachments: casablanca.zip, casablancaIntegration.patch, trinidadAdaptation.patch A new more modern skin with a nice-minimalist look. Also a simple and intuitive way to skin Trinidad components using Casablanca selectors stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1572) Potential Character Encoding problem in the Branch Trinidad-1.0.x
[ https://issues.apache.org/jira/browse/TRINIDAD-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1572: - Resolution: Fixed Fix Version/s: 1.0.12-core Status: Resolved (was: Patch Available) Thanks to Mamallan Uthaman for the patch; was already committed to 1012 branch Potential Character Encoding problem in the Branch Trinidad-1.0.x - Key: TRINIDAD-1572 URL: https://issues.apache.org/jira/browse/TRINIDAD-1572 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.11-core Environment: JSF1.1 Reporter: Mamallan Uthaman Fix For: 1.0.12-core Attachments: TRINIDAD-1572.patch Trinidad-1430 resolved a character encoding introduced by Trinidad-1272. But, unfortunately, the patch for the Trinidad-1430 didn't include the branch Trinidad-1.0.x. Hence, Trinidad-1.0.x remains vulnerable to the character encoding issue mentioned in Trinidad-1430. I will upload a patch to fix this potential problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoc] Google Summer of Code Idea
On Wed, Jan 20, 2010 at 8:34 PM, Ali Ok al...@aliok.com.tr wrote: Hi all, I sent a couple of mails about MyFaces on Google App Engine GSOC proposal. But after some progress and a conversation with Matthias, I realized that it is too small for GSOC. And I am willing to implement HTML5 Renderkit. sounds good to me. Meanwhile, I will work on GAE support in parallel. I will post my patch to JIRA after some -more- tests. that's great. Once the stuff is present, please send out a new mail (different/new thread) so that folks can take a look at the changes. -Matthias Regards, Ali On Wed, Jan 6, 2010 at 11:52 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/1/6 Matthias Wessendorf mat...@apache.org as the mentioned behavior support already said, I'd like to see this ONLY for JSF2.0 (MyFaces 2.0) -Matze On Wed, Jan 6, 2010 at 8:35 AM, Matthias Wessendorf mat...@apache.org wrote: Hi guys, running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. What do folks think about that? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1690) ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called
[ https://issues.apache.org/jira/browse/TRINIDAD-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803211#action_12803211 ] Matthias Weßendorf commented on TRINIDAD-1690: -- hrm, committing this to both version may cause trouble on a forward merge. Do you mind to give a heads-up, once the patch is ready ? we can do a forward merge of TRUNK before you commit this particular fix. ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called -- Key: TRINIDAD-1690 URL: https://issues.apache.org/jira/browse/TRINIDAD-1690 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core , 2.0.0.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson ResourceLoader has protected method protected String getContentType(URLConnection conn) that is never called by the resource servlet. This makes it extremely difficult for the resource loader to specify the MIME type for a resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
