Re: MyFaces interview
Kito D. Mann schrieb: Hello everyone, I'd like to conduct a new e-mail interview with one or two people from the MyFaces Core team. The last one was in 2004 (http://www.jsfcentral.com/articles/geiler-04-04.html), and at that time, it made sense to interview Manfred, since he is the founder and was very heavily involved at the time. Who would be a good choice this time around? Thomas, Martin, Sean or Mike?
Re: MyFaces interview
Kito D. Mann schrieb: Hello everyone, I'd like to conduct a new e-mail interview with one or two people from the MyFaces Core team. The last one was in 2004 (http://www.jsfcentral.com/articles/geiler-04-04.html), and at that time, it made sense to interview Manfred, since he is the founder and was very heavily involved at the time. Who would be a good choice this time around? Matthias probably also is a good choice.
Re: MyFaces interview
thx, but I'd like to see Martin for several reasons (JavaOne session, JSR work etc) -Matthias On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Kito D. Mann schrieb: Hello everyone, I'd like to conduct a new e-mail interview with one or two people from the MyFaces Core team. The last one was in 2004 (http://www.jsfcentral.com/articles/geiler-04-04.html), and at that time, it made sense to interview Manfred, since he is the founder and was very heavily involved at the time. Who would be a good choice this time around? Matthias probably also is a good choice. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (MYFACES-1550) generated MyFaces id's produce duplicates which throw exceptions in container, rendering existing apps unusable
[
https://issues.apache.org/jira/browse/MYFACES-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477251
]
Guy Coleman commented on MYFACES-1550:
--
I'm using JSP.
generated MyFaces id's produce duplicates which throw exceptions in
container, rendering existing apps unusable
---
Key: MYFACES-1550
URL: https://issues.apache.org/jira/browse/MYFACES-1550
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.5
Environment: MyFaces 1.1.5, WindowsXP, Tomcat5.5.20
Reporter: Lisanchez
Priority: Blocker
Fix For: 1.1.5
Pages that once worked (1.1.5) stopped working for some reason (within the
past week). The issue seems to be with generated id's on components.
You will see this where you load a page and then reload the same page through
a hyperlink or rendering for the second time.
There seems to be some correlation with the f:facet tag. I have a page with
a t:dataTable and several columns that use the f:facet tag to provide the
column header. The page loads just fine initially but if I reload, I get a
blank screen and the following message in my Tomcat log file.
If I remove the column header and the facet tag, I do not see the error.
About a week ago there were no problems with this page so it is something new
that has been introduced and should be fixed.
---
Mar 1, 2007 2:29:16 PM com.sun.facelets.FaceletViewHandler
handleRenderException
SEVERE: Error Rendering View[/web/Summary.xhtml]
java.lang.IllegalStateException: Client-id : _id32 is duplicated in the faces
tr
ee. Component : _id30:_id31:_id32, path: {Component-Path : [Class:
javax.faces.c
omponent.UIViewRoot,ViewId: /web/Summary.xhtml][Class: org.ap
ache.myfaces.custom.document.Document,Id: _id12][Class:
javax.faces.component.ht
ml.HtmlForm,Id: _id30][Class:
org.apache.myfaces.component.html.ext.HtmlDataTabl
e,Id: _id31][Class: javax.faces.component.UIColumn,Id: _id32][Class:
javax.faces
.component.html.HtmlOutputText,Id: _id32]}
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:329)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:341)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:338)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:338)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:341)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
ateIds(JspStateManagerImpl.java:341)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerialized
View(JspStateManagerImpl.java:286)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
a:601)
at
com.presence.util.bb.customjsf.PtViewHandler.renderView(PtViewHandler
.java:107)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderRes
ponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:
132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.do
FilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerR
equestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(Extensions
Filter.java:190)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at
Re: MyFaces Fusion Naming
Arash Rajaeeyan schrieb: and may be thats because shale has chosen a different approach? No... Actually I think the fusion conversation system is one level lower than shale dialog. While shale dialog basically follows the approach - configuration of dialog scopes, have something which can keep objects in ram during the dialog. the fusion conversation system is along the lines of: providing a programmatic accessible scope mechanism based on spring 2.0s basic scope control which also is able to handle orm entity manager control, no dialog configuration whatsoever (except for a spring bean entry). Nothing speaks against accessing this programmatic control from a configuration based dialog system, and only a few things currently prevent it from being accessible from other webframeworks outside of the jsf scope. But as Mario said, who knows what the future will bring.
[jira] Created: (MYFACES-1552) Rendering less JavaScript for each button
Rendering less JavaScript for each button - Key: MYFACES-1552 URL: https://issues.apache.org/jira/browse/MYFACES-1552 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.5 Reporter: Martin Marinschek Assigned To: Martin Marinschek Fix For: 1.1.6-SNAPSHOT I extracted the javascript of a button out to make sure it uses up less html-code on the page. There is now one central javascript-method rendered where before the javascript calls were made per button. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1552) Rendering less JavaScript for each button
[ https://issues.apache.org/jira/browse/MYFACES-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved MYFACES-1552. Resolution: Fixed Rendering less JavaScript for each button - Key: MYFACES-1552 URL: https://issues.apache.org/jira/browse/MYFACES-1552 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.5 Reporter: Martin Marinschek Assigned To: Martin Marinschek Fix For: 1.1.6-SNAPSHOT I extracted the javascript of a button out to make sure it uses up less html-code on the page. There is now one central javascript-method rendered where before the javascript calls were made per button. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1549) MyFaces-API issue: getValue of UIInput
[
https://issues.apache.org/jira/browse/MYFACES-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477314
]
Martin Marinschek commented on MYFACES-1549:
Direct access to UIOutput getLocalValue:
http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIInput.java?view=diffrev=513319r1=513318r2=513319
regards,
Martin
MyFaces-API issue: getValue of UIInput
--
Key: MYFACES-1549
URL: https://issues.apache.org/jira/browse/MYFACES-1549
Project: MyFaces Core
Issue Type: Bug
Components: JSR-127
Affects Versions: 1.1.5
Reporter: Martin Marinschek
Assigned To: Martin Marinschek
Fix For: 1.1.6-SNAPSHOT
UIOutput currently has the following code:
public Object getValue()
{
if (_value != null) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
}
UIInput has the following code:
public void setValue(Object value)
{
setLocalValueSet(true);
super.setValue(value);
}
My problem (pseudo code):
1) user enters an empty string in an input-component:
2) conversion and validation phase: -- setValue(null);
isLocalValueSet = true; setSubmittedValue(null);
3) validation fails in some component on the page -- update model
phase is skipped
4) renderer calls getValue(); -- getValue() evaluates the
value-binding, as the local-value is 'null', and I get the
default-value of the bean shown again
proposed solution:
UIInput overwrites getValue of UIOutput:
public Object getValue()
{
if (isLocalValueSet()) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1549) MyFaces-API issue: getValue of UIInput
[
https://issues.apache.org/jira/browse/MYFACES-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477317
]
Martin Marinschek commented on MYFACES-1549:
Reduced state-array size again, and tried the fix from the other side as well:
the code in RendererUtils has the same problem.
http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIInput.java?view=diffrev=513799r1=513798r2=513799
regards,
Martin
MyFaces-API issue: getValue of UIInput
--
Key: MYFACES-1549
URL: https://issues.apache.org/jira/browse/MYFACES-1549
Project: MyFaces Core
Issue Type: Bug
Components: JSR-127
Affects Versions: 1.1.5
Reporter: Martin Marinschek
Assigned To: Martin Marinschek
Fix For: 1.1.6-SNAPSHOT
UIOutput currently has the following code:
public Object getValue()
{
if (_value != null) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
}
UIInput has the following code:
public void setValue(Object value)
{
setLocalValueSet(true);
super.setValue(value);
}
My problem (pseudo code):
1) user enters an empty string in an input-component:
2) conversion and validation phase: -- setValue(null);
isLocalValueSet = true; setSubmittedValue(null);
3) validation fails in some component on the page -- update model
phase is skipped
4) renderer calls getValue(); -- getValue() evaluates the
value-binding, as the local-value is 'null', and I get the
default-value of the bean shown again
proposed solution:
UIInput overwrites getValue of UIOutput:
public Object getValue()
{
if (isLocalValueSet()) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: MyFaces interview
I'm not really heavily involved at this time. I'd be a poor choice. On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Kito D. Mann schrieb: Hello everyone, I'd like to conduct a new e-mail interview with one or two people from the MyFaces Core team. The last one was in 2004 (http://www.jsfcentral.com/articles/geiler-04-04.html), and at that time, it made sense to interview Manfred, since he is the founder and was very heavily involved at the time. Who would be a good choice this time around? Thomas, Martin, Sean or Mike?
Re: Status of subForm: time for promotion?
is there a test case ? On 3/2/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Other than a volunteer, is there anything holding up the promotion of subForm? I went through the issue tracker and created a subForm component category and moved relevent issues into it. I only see one open issue for subForm, and I don't consider it a blocker to promotion: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has documentation: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has an example: http://example.irian.at/example-sandbox-20070301/subForm.jsf -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Status of subForm: time for promotion?
Does that bug even still exist? I'm using subForm successfully in app that is nearing production. :D Mike Kienenberger wrote: Other than a volunteer, is there anything holding up the promotion of subForm? I went through the issue tracker and created a subForm component category and moved relevent issues into it. I only see one open issue for subForm, and I don't consider it a blocker to promotion: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has documentation: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has an example: http://example.irian.at/example-sandbox-20070301/subForm.jsf
Re: MyFaces Fusion Naming
On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: and may be thats because shale has chosen a different approach? No... Actually I think the fusion conversation system is one level lower than shale dialog. While shale dialog basically follows the approach - configuration of dialog scopes, have something which can keep objects in ram during the dialog. the fusion conversation system is along the lines of: providing a programmatic accessible scope mechanism based on spring 2.0s basic scope control which also is able to handle orm entity manager control, no dialog configuration whatsoever (except for a spring bean entry). Nothing speaks against accessing this programmatic control from a configuration based dialog system, and only a few things currently prevent it from being accessible from other webframeworks outside of the jsf scope. But as Mario said, who knows what the future will bring. One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? It looks like the core value add you wanted (managing the persistence tier resources at a per-conversation level instead of per-request) could have been done with SWF just as easily as writing your own conversation scope stuff. Craig
Re: MyFaces Fusion Naming
Hi Craig! One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? Don't know much about SWF, but we had a meeting with Jürgen Höller from interface21 where he helped designing the integration of the conversation scope with Spring including the persistence stuff. If SWF would have been possible to do this he would have said it. Also Fusion do depend on Spring 2, but not that hard ... for sure, it uses its possibility to create custom scopes and makes use of their persistence framework, though, its still modular enough that - if JSF will ever allow custom scopes - it can be plugged in there too. What might be possible is, that SWF make use of this new scope too - Fusion is also designed in a way that you can replace the web framework (in the important area). Maybe (I hope for the future) shale-dialog can make use of this scope too, and can provide a solution for the persistence that way. Ciao, Mario
Re: MyFaces Fusion Naming
Well... don't lets discuss that much about why another thing... Perhaps all these existing techniques can get their profit from the other one and can also give valuable feedback to web beans / jsr 299. I am happy that *Fusion* (or Kleber) has no dependency to WebFlow. I would prefer a closer connection to the Shale (Basic) Dialog. However... it's good to have the choice... Take a look at ORM or web frameworks... there are more than one, doing 99% same like the other... also the advent of JSF didn't stop that (like GWT for instance). Thx, Matthias On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig! One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? Don't know much about SWF, but we had a meeting with Jürgen Höller from interface21 where he helped designing the integration of the conversation scope with Spring including the persistence stuff. If SWF would have been possible to do this he would have said it. Also Fusion do depend on Spring 2, but not that hard ... for sure, it uses its possibility to create custom scopes and makes use of their persistence framework, though, its still modular enough that - if JSF will ever allow custom scopes - it can be plugged in there too. What might be possible is, that SWF make use of this new scope too - Fusion is also designed in a way that you can replace the web framework (in the important area). Maybe (I hope for the future) shale-dialog can make use of this scope too, and can provide a solution for the persistence that way. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (MYFACES-1553) CONVERTER_ID for DoubleConverter doesn't match 1.2 spec
CONVERTER_ID for DoubleConverter doesn't match 1.2 spec --- Key: MYFACES-1553 URL: https://issues.apache.org/jira/browse/MYFACES-1553 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The JSF 1.2 API says that the value of DoubleConverter.CONVERTER_ID should be javax.faces.DoubleTime -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1553) CONVERTER_ID for DoubleConverter doesn't match 1.2 spec
[ https://issues.apache.org/jira/browse/MYFACES-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved MYFACES-1553. - Resolution: Invalid that is / was a bug in the spec: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=176 CONVERTER_ID for DoubleConverter doesn't match 1.2 spec --- Key: MYFACES-1553 URL: https://issues.apache.org/jira/browse/MYFACES-1553 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1553.patch The JSF 1.2 API says that the value of DoubleConverter.CONVERTER_ID should be javax.faces.DoubleTime -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
SubmitOnEvent doesn't work as child of h:selectOneMenu without
explicit id. If 'id=choiceInput' is removed from the example code
below, no submit occurs.
sandbox:subForm id=choiceForm
h:selectOneMenu id=choiceInput
value=#{page.choice}
f:selectItems
value=#{page.choiceList}/
sandbox:submitOnEvent
for=executeChoiceSelected
event=change /
/h:selectOneMenu
h:commandButton id=executeChoiceSelected
style=display:none
value=Submit
/h:commandButton
/sandbox:subForm
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
Hi Mike!
SubmitOnEvent doesn't work as child of h:selectOneMenu without
explicit id. If 'id=choiceInput' is removed from the example code
below, no submit occurs.
Strange thing, I tested it now with the following thing
h:selectOneMenu
value=#{configuratorData.selectedComponent}
f:selectItems
value=#{configuratorData.components} /
s:submitOnEvent
event=change
for=showPieces /
/h:selectOneMenu
and it worked. At least with the latest sandbox.
AFAIK you use a older version of the sandbox, is this true for this
project too? Maybe I changed something in the meantime.
If not, could you please check if the submitOnEvent javascript code has
been rendered to the html, must look like something like:
setTimeout(orgApacheMyfacesSubmitOnEventRegister('change','','_idJsp14:_idJsp19','_idJsp14:showPieces');,
50)
Thanks!
Ciao,
Mario
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
My copy of the sandbox is so old, it doesn't even have the component :-)
I manually copied it into my project on Jan 24th, though.
Here's what the non-working html contains:
==
script type=text/javascript
function chooseMemberForm_submit() {
var form = document.forms['masterForm'];
var el = document.createElement(input);
el.type = hidden;
el.name = org.apache.myfaces.custom.subform.submittedId;
el.value = chooseMemberForm;
form.appendChild(el);
form.submit();
}
/script
script type=text/javascript language=JavaScript
setTimeout(orgApacheMyfacesSubmitOnEventRegister('change','','masterForm:connectPageForm:chooseMemberForm:_id48','masterForm:connectPageForm:chooseMemberForm:executeChoseMember');,
0)
/script
select size=1 name=masterForm:connectPageForm:chooseMemberForm:_id48
option value=com.gvea.utilities.web.jsf.converter.NULL_OPTION_VALUE
lt; Choose member gt;
/option
option value=63
Member #3456
/option
option value=83
Member #8034
/option
/select
input type=submit
onclick=clear_masterForm();if(window.getScrolling!=undefined){document.forms['masterForm'].elements['autoScroll'].value=getScrolling();}
value=Go!
name=masterForm:connectPageForm:chooseMemberForm:executeChoseMember
id=masterForm:connectPageForm:chooseMemberForm:executeChoseMember
==
Here's what the working html contains:
==
script type=text/javascript
function chooseMemberForm_submit() {
var form = document.forms['masterForm'];
var el = document.createElement(input);
el.type = hidden;
el.name = org.apache.myfaces.custom.subform.submittedId;
el.value = chooseMemberForm;
form.appendChild(el);
form.submit();
}
/script
script type=text/javascript language=JavaScript
setTimeout(orgApacheMyfacesSubmitOnEventRegister('change','','masterForm:connectPageForm:chooseMemberForm:memberInput','masterForm:connectPageForm:chooseMemberForm:executeChoseMember');,
0)
/script
select size=1
name=masterForm:connectPageForm:chooseMemberForm:memberInput
id=masterForm:connectPageForm:chooseMemberForm:memberInput
option value=com.gvea.utilities.web.jsf.converter.NULL_OPTION_VALUE
lt; Choose member gt;
/option
option value=63
Member #3456
/option
option value=83
Member #8034
/option
/select
input type=submit
onclick=clear_masterForm();if(window.getScrolling!=undefined){document.forms['masterForm'].elements['autoScroll'].value=getScrolling();}
value=Go!
name=masterForm:connectPageForm:chooseMemberForm:executeChoseMember
id=masterForm:connectPageForm:chooseMemberForm:executeChoseMember
==
On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi Mike!
SubmitOnEvent doesn't work as child of h:selectOneMenu without
explicit id. If 'id=choiceInput' is removed from the example code
below, no submit occurs.
Strange thing, I tested it now with the following thing
h:selectOneMenu
value=#{configuratorData.selectedComponent}
f:selectItems
value=#{configuratorData.components} /
s:submitOnEvent
event=change
for=showPieces /
/h:selectOneMenu
and it worked. At least with the latest sandbox.
AFAIK you use a older version of the sandbox, is this true for this
project too? Maybe I changed something in the meantime.
If not, could you please check if the submitOnEvent javascript code has
been rendered to the html, must look like something like:
setTimeout(orgApacheMyfacesSubmitOnEventRegister('change','','_idJsp14:_idJsp19','_idJsp14:showPieces');,
50)
Thanks!
Ciao,
Mario
Re: MyFaces Fusion Naming
Hi Craig! That's where I don't understand Fusion enough to comment ... it originally appeared to me that the key value add was allocating the entity manager on the way in (when you created the conversation), and cleaning up afterwards when the conversation ended. Yes, this is one of the things we do, the other thing is, that we have to ensure for each call into the conversation scoped bean that this entity manager has been set to the thread so that the following classes will see this entity manager. This is where the Spring aop stuff provides REALLY nice things. That way, its possible to work with multiple conversations within one request; not that you can exchange the beans load by each other. You say, this should be solved at the servlet spec. And I think with our solution we are really close to it. The basic conversation scope works as if it is provided by the servlet spec. You have an additional scope and finding the scope context (multi window awareness) works through an url parameter which will be added by an servlet response wrapper (just like the session id without cookies). Thats why we are not bound to JSF in this area, there is simply no JSF code to achieve this. All I need is access to e.g the request map and session map, that has been refactored into a framework adapter, and if I would like to spend a servlet filter I can avoid even this. Ciao, Mario
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
Hi Mike! Yes, it looked reasonable to me as well. I'm using firefox 1.5.0.10. Let me see if I get any errors. Nope. no javascript errors. Trying in IE 6. Yep. works here. So it's a firefox compatiblity issue. Does that help?:-) Unhappily no, as I use firefox 95% the day, so I did for the test, and it works here. Not that I really think it has something to do with it, but maybe there is something bad in your browser cache. Please try Ctrl-Shift-Reload, this should refetch all resources, regardless if its in the cache. Wondering, Mario
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
Not sure if this is relevent, but there are some errors when I first load the page, even though there's no errors when I select a row. = Error: clear_masterForm is not defined Source File: http://localhost:8089/faces/pages/connect.xhtml Line: 1 Error: Selector expected. Ruleset ignored due to bad selector. Source File: http://localhost:8089/faces/pages/connect.xhtml Line: 140 Error: inputComponent has no properties Source File: http://localhost:8089/pages/submitOnEvent.js Line: 80 = I'm not sure what control-shift-reload is -- my keyboard is missing that key :-) But I tried holding down control-shift while hitting the reload button with the mouse. No difference. Tried the same thing while choosing reload from the menu. No difference. Doesn't seem like there'd be anything cached since I've only had the one copy of the submitOnEvent.js installed. On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Mike! Yes, it looked reasonable to me as well. I'm using firefox 1.5.0.10. Let me see if I get any errors. Nope. no javascript errors. Trying in IE 6. Yep. works here. So it's a firefox compatiblity issue. Does that help?:-) Unhappily no, as I use firefox 95% the day, so I did for the test, and it works here. Not that I really think it has something to do with it, but maybe there is something bad in your browser cache. Please try Ctrl-Shift-Reload, this should refetch all resources, regardless if its in the cache. Wondering, Mario
[jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ] Jeff Bischoff commented on TOMAHAWK-914: I have attached all-in-one.patch, which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply. If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information. [4] http://wiki.apache.org/myfaces/Contributing_Patches Regards, Jeff Bischoff P.S. Any chance we can also merge this fix into the Tomahawk 1.1.5 release branch? :) t:dataTable style attributes don't work with Facelets - Key: TOMAHAWK-914 URL: https://issues.apache.org/jira/browse/TOMAHAWK-914 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.5, Facelets 1.1.11 Reporter: Jeff Bischoff Attachments: all-in-one.patch, HtmlDataTable.java.diff, JSFAttr.java.diff Problem: style and styleClass attributes on t:dataTable do not work in Facelets due to use of fully-qualified names in the map. Fix: Patch attached to resolve this by changing the names as stored in the map. Includes code to accept hacks based on the old behaviour, but warns that it is now deprecated. Bonus: Also includes fix for problem in Facelets where the EL can not return a null style. This is due to changes in the EL spec, and prevents the former (very useful) style rollover behaviour. Fix works by converting any empty String returned by the EL in these Style attributes into null. (Reverse Coercion) Background: After converting my application from JSP to Facelets, I set out to make my rowStyleClass attribute on t:dataTable work like it used to. First, I had to get the attribute working in Facelets. With considerable discussion on the user list (see [1] and [2]) and a lot of help from Mike, I think we've identified some pretty simple code changes to enable this and other similar attributes. I plan to introduce a patch for this, probably tomorrow. What happened next was that during testing of this change, I could confirm that the attribute did indeed now work, but I was baffled by unexpected behaviour. My EL expression which had previously returned null in certain situations was now returning the empty String. I went to Facelets list for some clarification on this (see [3]) and it turned out to be a requirement of the new EL spec to coerce the nulls into empty string. Getting an empty String instead of null for this ValueBinding lookup creates a problem because the extended dataTable treats a null value differently and goes looking at the more standard style attributes like rowClasses. With an empty string returned, it assumes it needs to look no further. As a user, there is no way for me to specify that under certain conditions, it should fallback to the other style attributes, e.g. rowClasses. The best fix we have collectively come up with so far is to coerce the empty string back into a null in the dataTable, so that the renderer does the right thing. I don't see too much downside to this approach, as an empty style string has no relevance in CSS. However, I feel a proposed change like this requires extra discussion before making a decision on it. It's another one of those situation where we have to decide how we want to handle unexpected results due to changes in the newer specs. [1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875 [2] http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html [3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941 Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces-API issue: getValue of UIInput
Yeah, exactly. Did you read my mail from before? Plus my new
issue-evaluation?
No, I read your mail after sending a reply about the converter, anyway
you're right about the bug Martin.
In this case, I'd strongly recommend that you run this by the spec
folks. If nothing else, we should get a clarification for the next
revision.
I agree with Mike
On 3/2/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
In this case, I'd strongly recommend that you run this by the spec
folks. If nothing else, we should get a clarification for the next
revision.
On 3/1/07, Martin Marinschek [EMAIL PROTECTED] wrote:
I didn't find anything in the spec.
JavaDoc of getValue in UIOutput says:
Gets the value of this UIComponent. First, consult the local value
property of this component. If non-null return it. If non-null, see if
we have a ValueBinding for the value property. If so, return the
result of evaluating the property, otherwise return null.
This description is obviously wrong (two times If non-null..), but
if you correct this obvious mistake, it speaks against my solution.
But then, reading the spec on a more general level it says:
3.1.4 Value Binding Expressions
Properties and attributes of standard concrete component classes may be
value
binding enabled. This means that, rather than specifying a literal value
as the
parameter to a property or attribute setter, the caller instead
associates a
ValueBinding (see Section 5.3.3 ValueBinding) whose getValue() method
must
be called (by the property getter) to return the actual property value
to be returned
if no value has been set via the corresponding property setter. If a
property or
attribute value has been set, that value must be returned by the
property getter
(shadowing any associated value binding expression for this property).
and this would clearly indicate I'm on the right track. Properly
reading this would mean we are wrong-doers for every component
attribute of every component, even if the chance is rather small that
the issue arises for normal attributes (it might definitely happen
though).
regards,
Martin
On 3/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
What's the spec say about UIInput's getValue()? If it's silent, I'd
say your solution makes sense.
On 3/1/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Wanted to discuss a small thing with you:
UIOutput currently has the following code:
public Object getValue()
{
if (_value != null) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext())
: null;
}
UIInput has the following code:
public void setValue(Object value)
{
setLocalValueSet(true);
super.setValue(value);
}
My problem (pseudo code):
1) user enters an empty string in an input-component:
2) conversion and validation phase: -- setValue(null);
isLocalValueSet = true; setSubmittedValue(null);
3) validation fails in some component on the page -- update model
phase is skipped
4) renderer calls getValue(); -- getValue() evaluates the
value-binding, as the local-value is 'null', and I get the
default-value of the bean shown again
proposed solution:
UIInput overwrites getValue of UIOutput:
public Object getValue()
{
if (isLocalValueSet()) return _value;
ValueBinding vb = getValueBinding(value);
return vb != null ? (Object)vb.getValue(getFacesContext())
: null;
}
everyone d'accord?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
Hi! Ok, its getting hot now, there is a difference between your two html snippets: not working select size=1 name=masterForm:connectPageForm:chooseMemberForm:_id48 working select size=1 name=masterForm:connectPageForm:chooseMemberForm:memberInput id=masterForm:connectPageForm:chooseMemberForm:memberInput As you can see, the first lacks the id. Though, the last version of submitOnEvent uses getElementsByName, though from the java script error in your last pos I see that you must use another version of it. I manually copied it into my project on Jan 24th, though. There must be something went wrong, only the first version dated with 10.10.2006 used getElementById by accident. So, you should be able to fix this problem when you copy the latest version of submitOnEvent.js in your project. But I guess it's simply load it from your old sandbox jar, no? So you might replace it from within. Ciao, Mario
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Jeff, I think a single diff file is easier, so go ahead and update the documentation. On 3/2/07, Jeff Bischoff (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ] Jeff Bischoff commented on TOMAHAWK-914: I have attached all-in-one.patch, which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply. If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information. [4] http://wiki.apache.org/myfaces/Contributing_Patches Regards, Jeff Bischoff
Re: MyFaces interview
Martin, Matthias, Bruno. On 3/2/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm not really heavily involved at this time. I'd be a poor choice. On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Kito D. Mann schrieb: Hello everyone, I'd like to conduct a new e-mail interview with one or two people from the MyFaces Core team. The last one was in 2004 (http://www.jsfcentral.com/articles/geiler-04-04.html), and at that time, it made sense to interview Manfred, since he is the founder and was very heavily involved at the time. Who would be a good choice this time around? Thomas, Martin, Sean or Mike?
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, its getting hot now, there is a difference between your two html snippets: not working select size=1 name=masterForm:connectPageForm:chooseMemberForm:_id48 working select size=1 name=masterForm:connectPageForm:chooseMemberForm:memberInput id=masterForm:connectPageForm:chooseMemberForm:memberInput As you can see, the first lacks the id. Well, yes. That's what I'd expect to see. On the working one, I have id=memberInput and on the non-working one, I've deleted that value. So the two are equivalent. Or are you saying that there should be a id=masterForm:connectPageForm:chooseMemberForm:_id48? Though, the last version of submitOnEvent uses getElementsByName, though from the java script error in your last pos I see that you must use another version of it. I manually copied it into my project on Jan 24th, though. There must be something went wrong, only the first version dated with 10.10.2006 used getElementById by accident. So, you should be able to fix this problem when you copy the latest version of submitOnEvent.js in your project. But I guess it's simply load it from your old sandbox jar, no? So you might replace it from within. No, there's no submitOnEvent.js in my sandbox. I had to manually add it elsewhere to my project and point to it manually. That's why I get these errors :-) 15:17:12.375 ERROR! [SocketListener0-1] org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader.serveResource(MyFacesResourceLoader.java:143) 16 Unable to find resource resource/submitOnEvent.js for component submitOnEvent.SubmitOnEventRenderer. Check that this file is available in the classpath in sub-directory /resource of the package-directory. I will go ahead and grab the latest version of this from svn and copy it into my project and let you know if anything changes.
[jira] Commented: (TOMAHAWK-915) Base default event used by submitOnEvent on enclosing component type
[ https://issues.apache.org/jira/browse/TOMAHAWK-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477449 ] Mario Ivankovits commented on TOMAHAWK-915: --- Mike, I've committed something which should do the trick, though, I've no time to try it yet. If you find some time could you please do it? Else I'll do it in the next few days. Thanks! Good night :) Mario Base default event used by submitOnEvent on enclosing component type Key: TOMAHAWK-915 URL: https://issues.apache.org/jira/browse/TOMAHAWK-915 Project: MyFaces Tomahawk Issue Type: Improvement Components: submitOnEvent Affects Versions: 1.1.5-SNAPSHOT Reporter: Mike Kienenberger Priority: Minor One thing that I had issues with for submitOnEvent is that the default event is keyPress. I didn't realize that the default event wouldn't work for a selectOneUI. Let's add intelligent default event values. keyPress for a UIInput, change for a UISelectOne, and so on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SubmitOnEvent doesn't work as child of h:selectOneMenu without explicit id
Hey Mario. Thanks for taking the time to step through this with me. You are correct -- the version I had was quite different from the version in trunk. The bug goes away once I upgrade to the new version. I must have downloaded the wrong version by mistake. On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Ok, its getting hot now, there is a difference between your two html snippets: not working select size=1 name=masterForm:connectPageForm:chooseMemberForm:_id48 working select size=1 name=masterForm:connectPageForm:chooseMemberForm:memberInput id=masterForm:connectPageForm:chooseMemberForm:memberInput As you can see, the first lacks the id. Though, the last version of submitOnEvent uses getElementsByName, though from the java script error in your last pos I see that you must use another version of it. I manually copied it into my project on Jan 24th, though. There must be something went wrong, only the first version dated with 10.10.2006 used getElementById by accident. So, you should be able to fix this problem when you copy the latest version of submitOnEvent.js in your project. But I guess it's simply load it from your old sandbox jar, no? So you might replace it from within. Ciao, Mario
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Done. :D Mike Kienenberger wrote: Jeff, I think a single diff file is easier, so go ahead and update the documentation. On 3/2/07, Jeff Bischoff (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ] Jeff Bischoff commented on TOMAHAWK-914: I have attached all-in-one.patch, which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply. If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information. [4] http://wiki.apache.org/myfaces/Contributing_Patches Regards, Jeff Bischoff
Version info for javascript files?
As I was dealing with the submitOnEvent error, one thing I noticed is that there's no svn info in the javascript file. This made it hard to know what revision of the file I was working with. Should we be including an id tag in there, or was it left out intentionally?
[jira] Created: (TOMAHAWK-915) Base default event used by submitOnEvent on enclosing component type
Base default event used by submitOnEvent on enclosing component type Key: TOMAHAWK-915 URL: https://issues.apache.org/jira/browse/TOMAHAWK-915 Project: MyFaces Tomahawk Issue Type: Improvement Components: submitOnEvent Affects Versions: 1.1.5-SNAPSHOT Reporter: Mike Kienenberger Priority: Minor One thing that I had issues with for submitOnEvent is that the default event is keyPress. I didn't realize that the default event wouldn't work for a selectOneUI. Let's add intelligent default event values. keyPress for a UIInput, change for a UISelectOne, and so on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: @PreDestroy, Servlet API,
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is implemented
by j2ee containers. I wonder if each container will end up looking for
different interfaces. How would MyFaces find Geronimo's implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load(clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I know
nothing
about right now), I think we are all good here. Wouldn't MyFaces then
be
observing the requirements (in plain java) around @PostConstruct after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application) are the
only candidates for this, and it would be more awkward to do that from
the
container. I say all of this in an open manner, so anyone feel free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken. I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the injection.
Tomcat provides an example of how this can be done. The following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid importing
classes from javax.annotation classes since servlet 2.5 containers are
required to support them. Is this so that MyFaces 1.2 can support
servlet 2.4 containers?
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I ended up going with Servlet/Request/Context attribute listeners
for
@PreDestroy. This did not involve importing
javax.annotation.PreDestroy, so
people w/out application servers don't have to worry about
ClassDefNotFoundErrors. This also keeps us compatible with the
reference
implementation in terms of timing, although I really wish they'd
change
the
wording in the spec.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Sorry if I'm behind on this discussion but what are the current
thoughts on how dependency injection will be implemented for
managed
beans? The reason I'm curious is because PreDestroy and
PostConstruct
annotations are used to deal with injected resources, so from a
timing
perspective it would be important to process all these annotations
accordingly.
Best wishes,
Paul
On 2/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I'm weighing options about invoking @PreDestroy methods
(@PostConstruct
is
done BTW). I haven't made up my mind yet but here's where I'm
at on
this.
As far as *when* this happens, the request is easy, in
FacesServelet.service(). Session and app scope are more
difficult
decisions.
A
variable default for event used by submitOnEvent?
Mario, One thing that I had issues with for submitOnEvent is that the default event is keyPress. Until I found the hidden wiki docs for submitOnEvent (I've made them more visible now :-), I didn't realize that the default wouldn't work for a selectOneUI. Is there any chance we can have intelligent default event values? keyPress for a UIInput, change for a UISelectOne, and so on? Or is that too much to try to do?
Re: variable default for event used by submitOnEvent?
Hi Mike! Is there any chance we can have intelligent default event values? Yea, this is a great idea, should work. Could you please open a jira for it. Ciao, Mario
getAlign() and setAlign() not in JSF 1.2 spec
I see that the datafld, dataformatas, and datasrc properties were removed from HtmlDataTable in rev 513533. Should the align property also be removed from HtmlDataTable and HtmlPanelGrid since its not in spec? Best wishes, Paul
Re: @PreDestroy, Servlet API,
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is implemented
by j2ee containers. I wonder if each container will end up looking for
different interfaces. How would MyFaces find Geronimo's implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I know
nothing
about right now), I think we are all good here. Wouldn't MyFaces then
be
observing the requirements (in plain java) around @PostConstruct after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application) are the
only candidates for this, and it would be more awkward to do that from
the
container. I say all of this in an open manner, so anyone feel free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the injection.
Tomcat provides an example of how this can be done. The following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid importing
classes from javax.annotation classes since servlet 2.5 containers are
required to support them. Is this so that MyFaces 1.2 can support
servlet 2.4 containers?
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I ended up going with Servlet/Request/Context attribute listeners
for
@PreDestroy. This did not involve importing
javax.annotation.PreDestroy, so
people w/out application servers don't have to worry about
ClassDefNotFoundErrors. This also keeps us compatible with the
reference
implementation in
Re: @PreDestroy, Servlet API,
Are any of these class names or context params start w/ javax.faces ? If
so, we can move the conversation back into the issue tracker and I'll close
the @PostConstruct issue once Paul says it's good to go. I don't see the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't MyFaces
then
be
observing the requirements (in plain java) around @PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application)
are the
only candidates for this, and it would be more awkward to do that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to
the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would
also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the
injection.
Tomcat provides an example of how this can be done. The
following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid
importing
classes from javax.annotation classes since servlet 2.5containers are
required to support them. Is this so that MyFaces 1.2 can
support
servlet 2.4
/etc/hosts points to a wrong myfaces.zones.apache.org ip address
some of the builds are currently failing because the lookup for myfaces.zones.apache.org failes on the zone host. I've looked into the /etc/hosts config file and IMO there is a wrong ip address defined. AFAIK the entry should be something like: 127.0.0.1 myfaces.zones.apache.orgloghost That would work if the current ip address for the zone box is changing again. But we need someone with root rights to change that file. -- Mathias
Re: @PreDestroy, Servlet API,
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
Are any of these class names or context params start w/ javax.faces ? If
so, we can move the conversation back into the issue tracker and I'll close
the @PostConstruct issue once Paul says it's good to go. I don't see the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider }
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't MyFaces
then
be
observing the requirements (in plain java) around @PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application)
are the
only candidates for this, and it would be more awkward to do that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to
the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would
also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the
injection.
Tomcat provides an example of how this can be done. The
following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the
Re: @PreDestroy, Servlet API,
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to bow down here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
Are any of these class names or context params start w/ javax.faces? If
so, we can move the conversation back into the issue tracker and I'll
close
the @PostConstruct issue once Paul says it's good to go. I don't see
the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces
used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider }
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection
on a
managed bean when MyFaces brings that bean into service? This
would
allow MyFaces to maintain control of the timing while allowing
the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret
the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept
the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't
MyFaces
then
be
observing the requirements (in plain java) around
@PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct
and
@Predestroy.
This makes sense because scoped (request, session,
application)
are the
only candidates for this, and it would be more awkward to do
that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically
referring to
the
portion of the JSF spec that discusses injecting resources
where
certain annotations are found in a managed bean. So, while
scanning
for the
Re: MyFaces Fusion Naming
Matthias Wessendorf schrieb: Well... don't lets discuss that much about why another thing... Perhaps all these existing techniques can get their profit from the other one and can also give valuable feedback to web beans / jsr 299. I am happy that *Fusion* (or Kleber) has no dependency to WebFlow. I would prefer a closer connection to the Shale (Basic) Dialog. Actually I personally think this is one area which is very important, Shale as excellent configuration patterns which are currently missing in fusion and a closer tie could benefit both frameworks I guess. Fusion started out from the idea of being able to have something conversational without having to have an entire configuration system, but there are many usecases where a conversation system can solve a lot of issues. So I personally now think, that having both and also having persistence control in it is probably the best way to go. No configuration for the easy usecases (which are the usual 50-70% and having something with more control on the configuration side for the more complicated ones. Funny that Seam started off as well configuration less, and now has moved into a we support both approach. However... it's good to have the choice... Take a look at ORM or web frameworks... there are more than one, doing 99% same like the other... also the advent of JSF didn't stop that (like GWT for instance). Actually there are not too many choices of such systems currently You only have seam and fusion/kleber which can do full persistencecontext control. I personally think, Seam is a work of pure genious, it is seldom that a first approach does most of the things right. But Seam itself, has too string tie ins into ejb3 and into jsf (I love ejb3 and I am not an enemy of JSF obviously, but I still see it as a problem) probably and makes some automatic assumptions which are perfectly ok for a framework which tries to ease things, but often you do not want to lose this control entirely. For instance one area of this we make the assumptions for you in Seam is the passing from the master to the detail which happens automatically. I once did a testprogram in Seam and thought afterwards to myself, what has happened here, I want to know... While it was good for the end user who does not want to think about it, something in there broke to my knowledge simply the way the tomahawk handles the tables, so tomahawk was incompatible to seams handling of master detail relationships. I am not going into detail here, because I neither remember the exact automatisms nor the exact details why the tomahawk table does not work. One of the problems I have faced the last week, was to find a way to handle the master detail relationships the way I wanted to have them, in a transparent way, which does not take away control. I had two ways I either could preinitialize the detail conversation in the master and load the detail or I could use the updateActionListener like I would anyway, I opted for a simple updateActionListener. Fusion was low level enough to leave me the control and did not take assumptions on how to handle things from me. I personally would love to see JSR299 go that way, not too make to many assumptions but keep it basic so that others can build upon it. This is too important to push a lot into it, that is probably one of the reasons why the servlets have served us so well for a long time, they kept things basic. And Craig, I agree, scoping should belong at the lowest level possible, but for now I am happy that there are solutions which ease the burden of taking away the endless request, merge, lazy loading, object keeping problems which have plagued us 10 years too long. Orm mappers are a joy to use, if you do not have to fight against them due to endless lazy loading, merge problems.
