Re: submittedValue vs. Converter.getAsObject
Hi, is there any progress in this area? As I can see, there was no official response to this problem at jsr-314-open. Should we create request for JSF 2.2? Full thread: http://www.mail-archive.com/dev@myfaces.apache.org/msg48796.html I found another scenario where generic Object - Object conversion is useful: rowKey concept. Many renderkits use rowKey (Object) as replacement of indices (int) (DataModel.getRowKey instead of DataModel.getRowIndex). But a elegant type responsible for Object - rowKey (Object) is not available now. In my use cases, I need two different conversion chains: 1) for non-String based client: Object (a @Entity mostly) - rowKey (Object) and back. 2) HTML client: Object (@Entity) - rowKey (Object) (serves as key in trinidad CollectionModel for example) and then rowKey (Object) - clientRowKey (String) for HTML. In the second case, responsible types are: A) javax.faces.convert.Converter : Object (@Entity) - clientRowKey (String) B) org.apache.myfaces.trinidad.render.ClientRowKeyManager: rowKey (Object) - clientRowKey (String) C) ... this is the missing Object - Object conversion type. type A) - Converter can delegate it's resposibility to chain of C)s and one B). WDYT? Kočičák Hi Ok, good to know that. Anyway, I think a full solution should something like the proposed solution. Let's see what happen, and if it is not included maybe we could include it on a project in myfaces (myfaces commons or tomahawk maybe). regards, Leonardo Uribe Martin Koci píše v Čt 23. 09. 2010 v 21:40 +0200: Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-3061) Failure rendering the whole page by ajax due to ui:debug
Failure rendering the whole page by ajax due to ui:debug - Key: MYFACES-3061 URL: https://issues.apache.org/jira/browse/MYFACES-3061 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Reporter: Nick Belaevski The following code: h:head /h:head h:body h:form ui:debug / h:commandLink value=Ajax f:ajax render=@all / /h:commandLink /h:form /h:body Fails to update page correctly in Chrome browser. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTVAL-128) Deregistration of SubNameMappers doesn't work
[ https://issues.apache.org/jira/browse/EXTVAL-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002052#comment-13002052 ] Gerhard Petracek commented on EXTVAL-128: - thx for the cleanup - please commit it Deregistration of SubNameMappers doesn't work - Key: EXTVAL-128 URL: https://issues.apache.org/jira/browse/EXTVAL-128 Project: MyFaces Extensions Validator Issue Type: Bug Components: Core Affects Versions: 1.2.4, 2.0.4, 1.1.4 Reporter: Gernot Binder Priority: Minor Attachments: EXTVAL-128.patch, EXTVAL-128_2.patch, EXTVAL-128_rubus.patch ExtValUtils#deregisterValidationStrategyToMetaDataTransformerNameMapper; and ExtValUtils#denyValidationStrategyToMetaDataTransformerNameMapper; don't work due to the sub-name mapper approach workaround: it's possible to use InvocationOrder -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Result (was: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.3)
thank you for voting! 5 binding +1 votes (pmc): - Matthias Wessendorf - Jakob Korherr - Mark Struberg - Werner Punz - Gerhard Petracek 1 non-binding +1 vote: - Martin Koci no -1 votes regards, gerhard 2011/2/28 Werner Punz werner.p...@gmail.com +1 Am 28.02.11 20:30, schrieb Mark Struberg: +1 I've tested it the whole day with my real world app already. LieGrue, strub --- On Mon, 2/28/11, Jakob Korherrjakob.korh...@gmail.com wrote: From: Jakob Korherrjakob.korh...@gmail.com Subject: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.3 To: MyFaces Developmentdev@myfaces.apache.org Date: Monday, February 28, 2011, 5:42 PM +1 Regards, Jakob 2011/2/28 Matthias Wessendorfmat...@apache.org: +1 (build the source drop) -M On Mon, Feb 28, 2011 at 2:23 PM, Gerhardgerhard.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 2011/2/28 Gerhard Petracekgpetra...@apache.org Hi, I was running the needed tasks to get the 4th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Examples Please take a look at the 0.9.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-063 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-063/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.3/myfaces-extcdi-parent-0.9.3-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
staging repositories
hi mike and werner, i saw [1] and [2] - they are closed but not released since a quite long time. regards, gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-017/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-047/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [myfaces site] community information
hi bart, thx for forwarding the e-mail! imo it shouldn't be a problem since we already refer to your book in our wiki. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/3 Bart Kummel b...@kummelweb.nl Hi all, Thanks for the reviews so far. Although next weekend is going to be busy for my, I hope to find some time to continue the work on the text. As noted before, the text is based on my book, so I had to ask the publisher permission for this re-use. Last week I got an official answer from them, as quoted below. Best regards, Bart Kummel Hi Bart, Apologies for the late reply. You can re-use some text from my book as long as it leads to a good promotion for your book and thus, increases the sales of your book. Thanks, Richard Richard Dias *Marketing Research Executive* | Packt Publishing | www.PacktPub.com http://www.packtpub.com/*MSN:* richa...@packtpub.com On Thu, Feb 17, 2011 at 14:07, Gerhard gerhard.petra...@gmail.com wrote: great intro +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/17 Jakob Korherr jakob.korh...@gmail.com Hi, So I think the format is good. If more depth is needed, we can always add some extra references to more in-depth articles or Wikis. Totally agreed! We should keep it short and simple. I guess no-one likes to read endless texts (even if you are very interested in MyFaces).. Regards, Jakob 2011/2/17, Jan-Kees van Andel jankeesvanan...@gmail.com: Hey, I like the way it's written. Well structured and the Overview table gives a nice overview. Also the Getting Started guide is well readable. There seems to be a bit overlap with some other Wiki pages, but I don't think that's a big issue... So I think the format is good. If more depth is needed, we can always add some extra references to more in-depth articles or Wikis. Regards, Jan-Kees 2011/2/17 Jakob Korherr jakob.korh...@gmail.com Hi Bart, I just read the Welcome to the Apache MyFaces Project site and I really like it, especially the brief history and the project overview table. Great work :) The other stuff also looks pretty good, but I want the read it in more detail in the next days. Regards, Jakob 2011/2/17, Bart Kummel b...@kummelweb.nl: Hi all, I did not get any reply on my previous mail yet. Before I continue adding documentation to the Draft pages on the wiki, I would really appreciate to hear if I'm going in the right direction so far. I'm not looking for detailed, in-depth documentation reviews yet. I'd just like to hear if this is the kind of stuff you're looking for. Do I have enough details? Or too much details perhaps? Please let me know! I will be on vacation for a week, starting tomorrow. I've planned to continue the documentation work after I return. Best regards, Bart Kummel On Sat, Feb 12, 2011 at 16:28, Bart Kummel b...@kummelweb.nl wrote: Hi all, Today, I have been adding some initial stuff to http://wiki.apache.org/myfaces/Drafts/Site/ and some pages below that. Most of the texts are slightly adapted texts from my book. Please let me know what you think about this. Feel free to edit the pages to correct errors or add useful info. I hope to add some more stuff in the weeks to come. FYI: I have signed an ICLA aggreement and sent it to the Apache secretary. I got a confirmation that it was received. Best regards, Bart On Sat, Feb 5, 2011 at 17:55, Bart Kummel b...@kummelweb.nl wrote: Hi all, This sounds good from my perspective as an author. I'll discuss this with the publisher first now. I'll keep y'all posted. Best regards, Bart On Fri, Feb 4, 2011 at 18:21, Gerhard gerhard.petra...@gmail.com wrote: imo pinging the legal mailing list is a great idea. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/4 Mark Struberg strub...@yahoo.de Hi! First of all: thanks Bart, that would be way cool if you could help us with pimping our documentation! For the legal question: Actually contains of 2 parts: All people who like to write articles in our Wiki need to have a CLA [1] on file. This is just to make sure that the ASF cannot get blamed for 'stealing' things from somewhere. Just send the signedscanned iCLA to secret...@apache.org and that's all from the ASF side. The other legal aspect is if you can reuse parts of your book. Please ask for the ok of your publisher.
[jira] Created: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map
Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map Key: PORTLETBRIDGE-185 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman In handling a resource request we reacquire the bridge request scope. If we find the scopeId to use but the scope has since been removed from the ScopeMap (or never put there in the first place) you get an NPE. This happen because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the (Map) object pulled from the scopeMap using the scopeId key without checking first if this object is null (wasn't found). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-185. Resolution: Fixed Fix Version/s: 2.0.1 Turns out the actual use case that caused this occurred because of a concurrency interaction inside a series of requests that occur after a renderredirect and include an concurrent render and resource request. The use case problem is the bridge was creating the scopeId early in the render but not actually giving it a representation in the ScopeMap until later. When a concurrent resource request is run -- it can hit this case where it picks up this new scopeId but doesn't find the entry. Fix was actually quite involved -- in that it also showed that in this use case the bridge was overally aggressively creating new scopes. So now the scope activation/resolution has been reworked to make this work/simpler. Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map Key: PORTLETBRIDGE-185 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.1 In handling a resource request we reacquire the bridge request scope. If we find the scopeId to use but the scope has since been removed from the ScopeMap (or never put there in the first place) you get an NPE. This happen because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the (Map) object pulled from the scopeMap using the scopeId key without checking first if this object is null (wasn't found). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-184) Bridge NPE in resolving scope during resource request if scope has been removed from cache
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-184.
Resolution: Duplicate
Inadvertently opened duplicate second bug: PORTLETBRIDGE-185 and updated/marked
that one fixed.
Bridge NPE in resolving scope during resource request if scope has been
removed from cache
--
Key: PORTLETBRIDGE-184
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-184
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
If the Bridge receives a scopeid in the incoming request during a resource
request and that scope isn't in the cache (it has been removed) then the
bridge throws a NPE as it doesn't include a check to ensure that the map
returned from looking up the scopeId isn't null.
Code currently reads like this:
private String getResourceRequestScopeId(ExternalContext extCtx,
PortletRequest request)
{
// get the render scope this resource request is contained in
String scopeId = getRequestScopeId(request);
if (scopeId == null)
{
// first request is a resource request
// create a scope and store in the session until an action occurs
// pass null as we aren't a StateAwareResponse
return initBridgeRequestScope(request, null);
}
// Check to see if this resource request is targeting the same view or a
different one
MapString, Object m = getScopeMap(scopeId);
MapString, String childResourceScopeMap = (MapString, String)
m.get(CHILD_RESOURCE_REQUEST_SCOPE_MAP);
String scopeIdKey = (String) m.get(SCOPE_VIEW_KEY);
String childIdKey = getScopeViewKey(extCtx);
Instead code should check for null return from geetScopeMap and if null init
a new bridge RequestScope.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
