Re: [COMMUNITY] MyFaces += Bernhard Huemer
Welcome Bernhard! Best wishes, Paul On Jan 29, 2008, at 6:20 AM, Manfred Geiler wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/ pom.xml --Manfred
Re: [VOTE] release of myfaces core 1.2.2
+1 Leonardo Uribe wrote: Hi, I was running the needed tasks to get the 1.2.2 release of Apache MyFaces core out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v3.0.2 [1] 2. Maven artifact group org.apache.myfaces.core v1.2.2 [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.2 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, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces122 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- View this message in context: http://www.nabble.com/-VOTE--release-of-myfaces-core-1.2.2-tp15021745p15045113.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: MyFaces logo
Great work! 10 is definitely my favorite. Best wishes, Paul On Nov 30, 2007, at 9:25 AM, Martin Marinschek wrote: Hey everyone, What do you think of a new MyFaces logo, like the one proposed by Adonis in the following pdf? regards, martin -- Forwarded message -- From: Adonis Raduca [EMAIL PROTECTED] Date: Nov 30, 2007 1:19 PM Subject: MyFaces logo To: Catalin Kormos [EMAIL PROTECTED], Catalin Kormos [EMAIL PROTECTED], [EMAIL PROTECTED] Hello We have a nice logo for MyFaces project. The logo consists of two stylized faces in the puzzle-like shape that represents interconnectivity and modular architecture. We achieved an interesting exotic touch using a tribal-like painting style for those faces. I tried to avoid the omnipresent blue color to differentiate from the crowd and especially from ICEfaces product, so I use a warm color combination in the Ubuntu african stile. In the attached file we have 2 shape and 5 color variations of the logo. Personally I recommend the 5th and 10th samples because its good contrast and color balancing. Have a nice weekend ! Adonis -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFacesMyFaces_logo.pdf
Re: [COMMUNITY] MyFaces += Leonardo Uribe
Welcome Leonardo! Best wishes, Paul On Nov 21, 2007, at 5:18 AM, Manfred Geiler wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Leonardo Uribe as the newest MyFaces committer. Leonardo has provided countless patches to Jira issues, and is very active on the mailing lists as well. @Leonardo: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/ pom.xml --Manfred
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543607
]
Paul McMahan commented on MYFACES-1761:
---
Feedback from the MyFaces dev list indicates that changing the
LifecycleProvider interface in a maintenance release will be OK.
During that conversation Bernhard offered to provide an alternative patch that
will bring together the best aspects of both patches already proposed for this
issue. Specifically, his proposal is:
{quote}
what about introducing InjectionTasks? The ManagedBeanBuilder, for example,
could register an InjectionTask that handles the injection of managed
properties. In fact, I'm thinking of a more general approach of your patch so
that others can perform additional injection too.
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
{quote}
See
http://www.nabble.com/Re%3A-external-api-change-OK-for-myfaces-impl-1.2.1--p13733556.html
Handling PostConstruct annotations - wrong order
Key: MYFACES-1761
URL: https://issues.apache.org/jira/browse/MYFACES-1761
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Assignee: Paul McMahan
Fix For: 1.2.1-SNAPSHOT
Attachments: MYFACES-1761-01.diff, MyFaces-1761.patch,
postconstruct-demo.zip
The specification states that managed bean methods annotated with
@PostConstruct have to be called after the object is initialized and after
dependency injection is performed. However, MyFaces calls those methods after
the bean instance is created but before dependency injection is performed
(for example, see
http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order
to resolve this bug the LifecycleProvider interface has to be changed.
Currently there's only one method responsible for creating/initializing a new
bean: newInstance(). This design choice implicates that there's no
possibility to seperate the steps creating the bean and postconstructing
the bean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: external api change OK for myfaces-impl 1.2.1?
On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
However, if you really can't live with the seperation of
initialization and postconstruction, what about introducing
InjectionTasks? The ManagedBeanBuilder, for example, could
register an InjectionTask that handles the injection of managed
properties. In fact, I'm thinking of a more general approach of
your patch so that others can perform additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
Yes, if I understand this new interface correctly then I think it
would provide the best of both worlds. Bravo for an excellent idea!
I actually started this thread to make sure it's OK to change the
LifecycleProvider interface in the upcoming 1.2.1 maintenance
release. No concerns have been raised yet so I think that we can
proceed in that direction.
Would you mind updating the JIRA with this new idea since the rest of
our discussion is recorded there? And if you have a specific
implementation in mind then please feel free to modify my patch. I
really think we are on the right track here.
Best wishes,
Paul
Re: external api change OK for myfaces-impl 1.2.1?
Whenever you have time sounds fine to me. Thanks again for your help
on this.
Best wishes,
Paul
On Nov 13, 2007, at 4:09 PM, Bernhard Huemer wrote:
Hello,
Ok, I'll do that on Thursday, if you don't mind.
regards,
Bernhard
On 11/13/2007 +0100,
Paul McMahan [EMAIL PROTECTED] wrote:
On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
However, if you really can't live with the seperation of
initialization and postconstruction, what about introducing
InjectionTasks? The ManagedBeanBuilder, for example, could
register an InjectionTask that handles the injection of managed
properties. In fact, I'm thinking of a more general approach of
your patch so that others can perform additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
Yes, if I understand this new interface correctly then I think it
would provide the best of both worlds. Bravo for an excellent idea!
I actually started this thread to make sure it's OK to change the
LifecycleProvider interface in the upcoming 1.2.1 maintenance
release. No concerns have been raised yet so I think that we can
proceed in that direction.
Would you mind updating the JIRA with this new idea since the rest
of our discussion is recorded there? And if you have a specific
implementation in mind then please feel free to modify my patch.
I really think we are on the right track here.
Best wishes,
Paul
external api change OK for myfaces-impl 1.2.1?
The LifecycleProvider interface was introduced in MyFaces core 1.2.0 as an integration point that allows Java EE containers to handle annotation processing for JSF managed beans. In order to help containers invoke @PostConstruct methods more consistently with the Java EE RI (glassfish) we are discussing changing this API in: https://issues.apache.org/jira/browse/MYFACES-1761 I attached a patch (MYFACES-1761-01.diff) to that JIRA that would change a method signature from : LifecycleProvider.newInstance(String className) to LifecycleProvider.newInstance(ManagedBean beanConfig) The only known implementer of the LifecycleProvider interface (outside of MyFaces itself) is the Geronimo project, which is in favor of this change. Are there any concerns with changing this external api in the upcoming 1.2.1 maintenance release? BTW, this patch also refactors ManagedBeanBuilder into ManageBeanInitializer so that the existing code in that class can still be used to initialize managed properties. Unless I am mistaken ManagedBeanBuilder was not intended to be externally overridden or extended, so refactoring it should not affect our users. Best wishes, Paul
Re: external api change OK for myfaces-impl 1.2.1?
Bernd, My understanding of the JSF 1.2 spec is that annotation processing for managed beans pertains to the injection of JavaEE managed resources. Now Bernhard raises a good point which is that for JSF developers a more practical use of the term injection could also mean the initialization of managed bean properties from their application config file, and they would expect this initialization to also work in conjunction with the @PostConstruct annotation. While that behavior is not prescribed by the spec, I agree that MyFaces users would intuitively expect it to work that way. His patch enforces this functionality by factoring the implicit handling of @PostConstruct annotations out of the newInstance() method and placing MyFaces in explicit control over when that one particular type of annotation should be processed. However, I think a goal of the LifecycleProvider interface has been and should remain to be providing a clean separation for delegating annotation processing to the container, and that MyFaces should assist rather than orchestrate the overall process of resource injection for this one special case. I think that the advantages of this approach are that it keeps MyFaces more insulated from future changes to the annotation processing specs and it makes MyFaces more portable by giving more flexibility to the container. I also believe that further advantages of this approach will become apparent as standards such as web beans emerge, where the EJB and ManagedBean component models are unified. Best wishes, Paul On Nov 12, 2007, at 2:46 PM, Bernd Bohmann wrote: Hello Paul, what is wrong with Bernhards patch? Instead of handling all of the annotation processing in LifecycleProvider.newInstance(String className) he suggest to add a method LifecycleProvider.postConstruct(Object obj) this method is called after the properties are injected by the annotation provider and the managed bean properties from the jsf impl. Why we should delegate the injection of the none annotation based managed bean properties to the LifecycleProvider? This must be implemented by Geronimo and the MyFaces Default LifecycleProvider. I would prefer only one place for the old style managed bean properties injection. Regards Bernd Paul McMahan schrieb: The LifecycleProvider interface was introduced in MyFaces core 1.2.0 as an integration point that allows Java EE containers to handle annotation processing for JSF managed beans. In order to help containers invoke @PostConstruct methods more consistently with the Java EE RI (glassfish) we are discussing changing this API in: https://issues.apache.org/jira/browse/MYFACES-1761 I attached a patch (MYFACES-1761-01.diff) to that JIRA that would change a method signature from : LifecycleProvider.newInstance(String className) to LifecycleProvider.newInstance(ManagedBean beanConfig) The only known implementer of the LifecycleProvider interface (outside of MyFaces itself) is the Geronimo project, which is in favor of this change. Are there any concerns with changing this external api in the upcoming 1.2.1 maintenance release? BTW, this patch also refactors ManagedBeanBuilder into ManageBeanInitializer so that the existing code in that class can still be used to initialize managed properties. Unless I am mistaken ManagedBeanBuilder was not intended to be externally overridden or extended, so refactoring it should not affect our users. Best wishes, Paul
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541341 ] Paul McMahan commented on MYFACES-1761: --- Thanks Martin. As you can probably tell (and maybe agree?) I am still not convinced by the original claim that the current @PostConstruct support in MyFaces is not compliant with the wording in the JSF spec. In fact I could go so far as to say that changing the current behavior actually introduces a bug because the spec is clear about injection (and therefore the timing of @PostConstruct) being limited to container managed resources. So like you pointed out our next recourse is to look at the TCK and the RI for enlightenment. MyFaces 1.2 passed the TCK so we are OK there. But I don't think that the JSF RI (by itself) can be used to determine the meaning of this language in the spec because IIUC the JSF RI only provides the hooks for dependency injection. Therefore my position is that it is the responsibility of the embedder of MyFaces to ensure compatibility with the *glassfish* RI, and compatibility with glassfish is not the responsibility of MyFaces itself. Testing the JSF RI's resource injection behavior outside of a compliant JavaEE container (such as in tomcat or jetty) is not valid IMHO. MyFaces can help JavaEE containers meet this compatibility requirement by refactoring ManagedBeanBuilder. And furthermore MyFaces can provide (as a feature) default implementations of LifecycleProvider for various non-JavaEE environments that include this functionality. My hope is that we can implement this @PostConstruct behavior while keeping the LifecycleProvider interface intact. LifecycleProvider.newInstance() is the integration point for dependency injection in several JavaEE components in Geronimo, and I do not think that it is necessary to change that interface to provide the desired behavior. Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541068 ] Paul McMahan commented on MYFACES-1761: --- Bernhard, thanks for bringing this up and for the helpful sample which clearly demonstrates the issue. Can you please point me to the language in the spec that you are referring to? Specifically you said: The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. But the language I found in the spec says: JSF implementations running in a Java EE 5 compliant container must support attaching the @PostConstruct and @PreDestroy annotations to aid in awareness of the managed-bean lifecycle. and Methods on managed beans declared to be in request, session, or application scope, annotated with @PostConstruct, must be called by the JSF implementation after resource injection is performed (if any) but before the bean is placed into scope. Reading the spec literally, the @PostConstruct annotation is exclusively provided for the benefit of resource injection in a Java EE 5 container, which as you have pointed out doesn't necessarily know about managed bean properties. I don't see any discussion about the @PostConstuct annotation being related to managed bean properties, so initializing them before calling @PostConstrcut could arguably be non-compliant with the spec. (I'm not taking that position, just considering both sides) I agree that initializing managed properties before calling PostConstruct methods might be a useful feature worth further consideration. But I want to determine first whether we think it is actually required by the spec or its up to us to determine if/how this feature should be implemented. If it's not required by the spec then let's consider how the RI behaves. Something I read in a blog suggests that the RI does in fact provide this feature, which would make me lean towards also providing it in MyFaces. However, the LifeCycleProvider interface you modified is an existing integration point for servlet and Java EE containers, and there are very similar LifeCycleProvider interfaces for several other Java EE components. So let's investigate whether it's possible to provide this feature without changing the interface, perhaps by refactoring the ManagedBeanBuilder so that initialization can occur as an additional step within the LifeCycleProvider.newInstance(). Looking forward to your thoughts on all this! Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541154 ] Paul McMahan commented on MYFACES-1761: --- The original description for this issue says: The specification states that... after the object is initialized and after dependency injection is performed But your quote from the spec says: after the object is *instantiated*, and after injection is performed I take this change in your terminology as agreement that creating (instantiating) the bean does not involve setting its managed properties, correct? Now it seems that you are instead interpreting the term injection to include setting of managed properties from the application config file. But I would have to disagree with that position as well because section 5.4 says (with *emphasis* added by me) : JSF Implementations that are running as a part of Java EE 5 must allow managed bean implementations to use the annotations specified in section 14.5 of the Servlet 2.5 Specification to allow the container to inject references to *container managed resources* into a managed bean instance before it is made accessible to the JSF application. The spec goes on to provide the concise list of annotations where injection is valid - @Resource, @EJB, @WebService, etc. I see no other discussion of injection in the JSF spec. While I can understand your practical usage of this term to include setting of managed properties, IMO that usage is not consistent with the spec which is very clear about injection being limited to a specific list of annotations for referencing container managed resources. I still agree with you that making this change could be appropriate and I think that consistency with the RI is important as well. Earlier when I mentioned the RI I meant Glassfish and not the JSF RI in a standalone servlet container. The JSF spec only discusses dependency injection in JavaEE. Which environment did you test the attached sample in? Your reaction towards my suggestion for keeping the LifecycleProvider interface unchanged is on track with the reason I hope we can agree that we are discussing a feature request and not a myfaces bug. If setting managed properties before calling @PostConstruct is *not* required by the spec, then 3rd party implementations of LifecycleProvider are not required to do it. They can (optionally) use a refactored ManagedBeanBuilder api to initialize the managed bean or even process the application config file themselves. Apache Geronimo would probably do the latter. Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Deployment of MyFaces snapshots to the apache snapshots repo
I deployed the 1.2.1-SNAPSHOT core api and impl jars to the ASF snapshot repo using mvn deploy. Best wishes, Paul On Nov 7, 2007, at 4:24 AM, Bruno Aranda wrote: For me, it would ok to copy them as it seems we are not getting any feedback about the vmbuild... Cheers, Bruno On 06/11/2007, Paul McMahan [EMAIL PROTECTED] wrote: I would like to get the 1.2.1-SNAPSHOT core api and impl jars into Geronimo's TCK testbed. OK if I manually deploy those two jars? Or should we wait for an update on vmbuild from Brett? Best wishes, Paul On Nov 4, 2007, at 7:42 AM, Matthias Wessendorf wrote: Pinged Brett for an update on the VMBUILD srv. -M On 11/4/07, Bruno Aranda [EMAIL PROTECTED] wrote: Hi, What is happening to the deployment of snapshots to the repository? Shouldn't it be automatic? Does someone know how to start deploying them again? They are a bit outdated... Thanks, Bruno -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Good news [was Re: Maven-Snapshots]
Thanks Manfred. Best wishes, Paul On Nov 7, 2007, at 5:43 PM, Manfred Geiler wrote: All continnum snapshots should be working again! --Manfred On Nov 5, 2007 8:44 AM, Martin Marinschek [EMAIL PROTECTED] wrote: Hi all, maven-buffs, our snapshots are available under daily builds again, but not in the maven snapshot repository. Only project that works is - guess it - Tobago! Core and tomahawk snapshots are pretty old (1st september), Trinidad snapshots are very, very old... can someone help out? 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: Deployment of MyFaces snapshots to the apache snapshots repo
I would like to get the 1.2.1-SNAPSHOT core api and impl jars into Geronimo's TCK testbed. OK if I manually deploy those two jars? Or should we wait for an update on vmbuild from Brett? Best wishes, Paul On Nov 4, 2007, at 7:42 AM, Matthias Wessendorf wrote: Pinged Brett for an update on the VMBUILD srv. -M On 11/4/07, Bruno Aranda [EMAIL PROTECTED] wrote: Hi, What is happening to the deployment of snapshots to the repository? Shouldn't it be automatic? Does someone know how to start deploying them again? They are a bit outdated... Thanks, Bruno -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: New wiki ? (was Re: [site] new pages ?)
Over the past couple of years the Geronimo project has discussed this topic a lot. Now that discussion is settled and Confluence is used for practically all of the project's user facing web pages - developer wiki, user documentation, and the main project web site. As you know MoinMoin is an excellent open source product and was in use by Geronimo. Confluence had many of the additional features that were interesting such as deep integration with JIRA, extension support, several export options, WYSIWYG editors, flexible security, etc. The main issues for switching to Confluence were migration of existing docs and infra's position on supporting it. Search for confluence in the mail archives for some interesting discussions. Here's one: http://www.nabble.com/-VOTE--Documentation-in-Confluence%2C- MoinMoin%2C-or..-tf961477s134.html Now after using Confluence for a couple of years I am a strong proponent of it. I think it's definitely worth taking a look at for MyFaces. I would encourage the team to poke around the wiki, doc, and main web site at geronimo.apache.org to see what they think about Confluence. The main costs in switching to it are migrating the existing content and learning how to use it. IMHO successfully clearing both of these hurdles requires consensus and support of the team at large. The Geronimo project was also fortunate enough to have a couple of developers willing to champion that effort. Best wishes, Paul On Nov 5, 2007, at 7:00 AM, Matthias Wessendorf wrote: Do we want to migrate to the cwiki, that some Apache projects are using ? I am not really thrilled on doing the migration... But, what do other think about it ? -Matthias On 11/5/07, Ron Smits [EMAIL PROTECTED] wrote: Understandable, but currently the wiki does not really shine in professionalism or modern looks. I stopped showing it to customers after I had a lot of negative feedback about it. Ron On 11/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: true, I think we discussed that in the past; I am not really interested in converting the pages. So a tool is a must :-) But my point was just adding new pages to have a bit more on get the community involved and not doing a wiki overhaul. -M On 11/5/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I prefer the confluence wiki used by quite a few other apache projects, such as http://cwiki.apache.org/CXF/. Regards, Erik-Berndt -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Matthias Wessendorf Verzonden: maandag 5 november 2007 8:23 Aan: MyFaces Development Onderwerp: Re: [site] new pages ? I think we will continue to use moin-moin wiki, which is OpenSource. -Matthias On 11/4/07, Ron Smits [EMAIL PROTECTED] wrote: Hi Matthias Looks real nice, but if we start doing pages like that could we please do something about the styling of the wiki? Before adding more pages would it not be real nice if we had a nicer looking wiki? JSF is meant to be a good framework to develop modern looking sites. should the wiki not reflect that? Ron On 11/4/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I found these two site: http://geronimo.apache.org/get-involved.html http://geronimo.apache.org/found-a-bug.html I think we should add similar version to our MyFaces homepage as well. It would also be very nice to have a page, that is similar to this as well: http://geronimo.apache.org/events.html WDYT ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [VOTE] Portlet Bridge Specification for JSF (JSR-301) code donation
+1 (non-binding) Best wishes, Paul On Oct 15, 2007, at 7:03 AM, Manfred Geiler wrote: This is the official vote for the acceptance of Oracle's donation of the JSR-301 [1] reference implementation code as a new MyFaces sub module. Please note that - since the codebase is small enough and there are no new committers - the intellectual property issues are handled by IP clearance [2] rather than incubation. You can find the current IP clearance status at [3]. Upon positive vote result the codebase will be imported into SVN at: http://svn.apache.org/repos/asf/myfaces/portlet-bridge/trunk Please note: This vote is for the latest code drop at [4] with the following checksum. MD5: 861076b6accc3728a3e36d4c240cf28f Regards, Manfred Geiler [1] http://jcp.org/en/jsr/detail?id=301 [2] http://incubator.apache.org/ip-clearance/index.html [3] http://incubator.apache.org/ip-clearance/jsr-301-ri.html [4] https://issues.apache.org/jira/browse/MYFACES-1664
Re: [jira] Commented: (JSR301-2) Coding Standards: This project should adopt coding standards similar to MyFaces for consistancy
I don't know of an apache wide standard, the geronimo project uses the following: http://cwiki.apache.org/GMOxDEV/coding-standards.html pretty closely aligned with Sun's. Best wishes, Paul On Sep 28, 2007, at 11:48 AM, Matthias Wessendorf wrote: I haven't really followed such an interesting topic in the past, so here is my question: Is there any apache coding standard thing ? Or is for all Apache Java efforts the SUN paperworks the one to go ? -M On 9/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! There have been a lot of discussions on coding conventions here at MyFaces. I don't think we've reached an agreement so far ;) * indentation is 2 spaces with no tabs I'd say two spaces are too much, one space should be sufficient. ;-) Just kidding. Honestly, if we warm up this discussion I think it would be best to simply stick with the SUN propsed [1] one - even if I don't like them that much (e.g. I like the opening brace on the next like) I've found that many other developer use them (or a derivate) and also newbies are used to them. Ciao, Mario [1] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Yippeee!
Martin, looks like I just missed getting to read your posts as they have been removed by the blog admin :-(If you repost somewhere else then please update this thread because I would like to see your feedback. Best wishes, Paul On Sep 15, 2007, at 2:04 AM, Martin Marinschek wrote: Isn't it nice to read something like this? This blog made my day, see my comments. http://icoloma.blogspot.com/2006/10/myfaces-emperor-has-no- clothes.html regards, Martin
[jira] Commented: (MYFACES-1722) c:forEach does not work with deferred expression
[
https://issues.apache.org/jira/browse/MYFACES-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526549
]
Paul McMahan commented on MYFACES-1722:
---
I transferred this problem from the Geronimo project hoping the MyFaces team
could take a look. I wasn't able to determine the root problem in my debugger
but I think it may be related to the MyFaces resolvers. It could also be
related to the tomcat's implementation of EL that is used by Geronimo.
c:forEach does not work with deferred expression
Key: MYFACES-1722
URL: https://issues.apache.org/jira/browse/MYFACES-1722
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Fedora7, Sun JDK 1.6.0_02, geronimo-tomcat6-jee5-2.0.1
Reporter: Piotr Piotrowski
The following page works on SunApplication Server 9, but does not work on
Geronimo:
[EMAIL PROTECTED] contentType=text/html%
[EMAIL PROTECTED] pageEncoding=UTF-8%
[EMAIL PROTECTED] prefix=f uri=http://java.sun.com/jsf/core%
[EMAIL PROTECTED] prefix=h uri=http://java.sun.com/jsf/html%
[EMAIL PROTECTED] prefix=c uri=http://java.sun.com/jsp/jstl/core%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8
titleJSP Page/title
/head
body
f:view
p
c:forEach var=i items=#{CombinedEL.table}
h:outputText value=#{i}/,
/c:forEach
/p
/f:view
/body
/html
The managed bean looks as follows:
package pp.web;
public class CombinedEL {
public Object[] getTable() {
return new Object[] {a, b, c};
}
}
The error looks like this:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
root cause
javax.faces.FacesException: javax.servlet.jsp.JspTagException: Don't know how
to iterate over supplied items in lt;forEachgt;
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:340)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:850)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
org.apache.jsp.combinedEL_jsp._jspService(combinedEL_jsp.java:90)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:334)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.jsp.JspTagException: Don't know how to iterate over supplied
items in lt;forEachgt;
org.apache.taglibs.standard.tag.common.core.ForEachSupport.toForEachIterator(ForEachSupport.java:274)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.supportedTypeForEachIterator(ForEachSupport.java:238)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.prepare(ForEachSupport.java:155)
javax.servlet.jsp.jstl.core.LoopTagSupport.doStartTag(LoopTagSupport.java:256)
org.apache.jsp.combinedEL_jsp._jspx_meth_c_005fforEach_005f0(combinedEL_jsp.java:157
Re: MyFaces UIData.invokeOnComponent()
No tweaking in my runs of the JSF 1.2 TCK. It is possible that a TCK
patch or exclusion list provided by Sun might have affected this area
of the MyFaces test results in some way. But that seems unlikely.
Ed, can you let us know which TCK version and specific test(s) should
have failed using MyFaces 1.2? Feel free to use the [EMAIL PROTECTED] list
if necessary.
Best wishes,
Paul
On Sep 10, 2007, at 12:00 PM, Martin Marinschek wrote:
Hi Ed,
I haven't been using JSF1.2 so far, except for migrating over stuff
I'm implementing in 1.1 - and surely we haven't been tweaking the TCK.
Very interesting - I'm forwarding to the dev-list.
@Everyone: guys, what's up here??
regards,
Martin
On 9/10/07, Ed Burns [EMAIL PROTECTED] wrote:
Hello Martin,
Ryan alerted me to something the TCK should have caught: the MyFaces
implementation of UIData.invokeOnComponent() is non-existant:
@Override
public boolean invokeOnComponent(FacesContext context, String
clientId, ContextCallback callback) throws FacesException {
// not supported yet
return false;
}
The javadoc for this method is very explicit: [1], and you should
know,
because invokeOnComponent() was your idea in the first place!
Are you handling this in some other way in order to pass the TCK?
Thanks,
Ed
[1] http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/
javax/faces/component/UIData.html#invokeOnComponent
(javax.faces.context.FacesContext,%20java.lang.String,%
20javax.faces.component.ContextCallback)
--
| 155 Business Days until JavaOne 2008
| [EMAIL PROTECTED] | office: 408 884 9519 OR x31640
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: [EMAIL PROTECTED]
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-1709) faces-config.xml validation using an XML Schema
[ https://issues.apache.org/jira/browse/MYFACES-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520869 ] Paul McMahan commented on MYFACES-1709: --- I agree that this is a good improvement for myfaces. As an aside, I also want to point out that the spec says that validating the resource file against the schema is only required for JSF in a Java EE environment. It is recommended but optional for JSF outside the Java EE environment. Geronimo 2.0, for example, which embeds MyFaces 1.2 already performs schema validation at deployment time. So if myfaces implements its own validation then it would be good to do this in a way that is complimentary to the validation that occurs in the Java EE container. From a visual inspection of this patch it looks like this goal is accomplished quite nicely by toggling schema validation via an init parameter, and that it is disabled by default: String validateConfig = context.getInitParameter(VALIDATE_CONFIG); return true.equals(validateConfig); // by default, configuration files won't be validated My only suggestion would be to add a little more doc in the code making it clear that changing the default to true instead of false would have an effect on how MyFaces behaves in a Java EE container which is probably not desirable. If I get a chance to commit this patch then I will add that comment, or you may want to add something along those lines into the patch for anyone else who might be taking a look. faces-config.xml validation using an XML Schema --- Key: MYFACES-1709 URL: https://issues.apache.org/jira/browse/MYFACES-1709 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Attachments: configuration-webapp.zip, MYFACES-1709.patch According to an inline comment (validation set to false during implementation of 1.2, DigesterFacesConfigUnmarshallerImpl) and my personal experience, configuration file validation hasn't been implemented so far. However, as far as I know the JSF specification says that JSF implementations that are part of a Java EE technology-compliant implementation are required to validate the application resource file against the XML schema (section 10.4.2). I'll attach a sample application reproducing the error (the fact that there is no error is incorrect this time) and the corresponding patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces 1.2.0 - trunk ?
On Jul 19, 2007, at 4:24 AM, Matthias Wessendorf wrote: I'd prefer a vote, to be honest. Yeah, we become vote-happy :-))) Votes are cheap :-) Best wishes, Paul
Re: [VOTE] MyFaces 1.2.x become trunk
+1 On Jul 19, 2007, at 9:59 AM, Matthias Wessendorf wrote: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch (1.2.1-SNAPSHOT is the current version). Please cast your vote [ ] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: MyFaces 1.2.0 - trunk ?
+1 Best wishes, Paul On Jul 14, 2007, at 10:18 AM, Matthias Wessendorf wrote: Should we do it now ? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Vote] Release of Apache MyFaces 1.2.0
+1 Best wishes, Paul On Jul 14, 2007, at 11:28 AM, Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.0 release of Apache MyFaces core out. . The artifacts are deployed to my private Apache account ([1] and [2]). Please take a look at the 1.2.0 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, Matthias [1] http://people.apache.org/~matzew/myfaces120/ [2] http://people.apache.org/~matzew/myfaces120/_dist/ [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: JSF 1.2 - release ?
agreed Best wishes, Paul On Jul 12, 2007, at 6:30 AM, Bruno Aranda wrote: Yes, we can exclude it, Cheers, Bruno On 12/07/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the current12 says modules moduleshared/module modulecore/module moduletest-webapp/module /modules I am -1 on releasing the demo On 7/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok... so, will try to start this release thing on Sunday / Monday -M On 6/29/07, Paul McMahan [EMAIL PROTECTED] wrote: On Jun 28, 2007, at 4:38 AM, Matthias Wessendorf wrote: Hi, is the current version of MyFaces 1.2 fine (TCK)? looks good to me, but please see my post on the tck list about jetty. Best wishes, Paul -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: MyFaces PMC += Cagatay Civici
Congrats Catagay! Best wishes, Paul On Jul 10, 2007, at 5:26 AM, Matthias Wessendorf wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Cagatay Civici. Cagatay is working on the Apache MyFaces and Tomahawk stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Cagatay, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Commons-el dependency for tomahawk
On Jul 5, 2007, at 11:01 PM, [EMAIL PROTECTED] wrote: Did commons-el pick up the apache-el to bring it to JSR standard for JEE 5? We have discussed it but AFAIK it hasn't happened. Last I heard was: http://www.nabble.com/Commons-EL-tf3195018.html Best wishes, Paul
Re: JSF 1.2 - release ?
On Jun 28, 2007, at 4:38 AM, Matthias Wessendorf wrote: Hi, is the current version of MyFaces 1.2 fine (TCK)? looks good to me, but please see my post on the tck list about jetty. Best wishes, Paul
Re: JSF 1.2 - no release (was: Re: [vote] release of Trinidad plugins (1.2.0))
I suspect that there is more interest in JSF 1.2 and JEE 5 than the lack of votes for this maven plugin might imply. It's very convenient to have all the JSF components already provided by the container, and resource injection for managed beans is useful as well. There has been some user feedback about JSF integration on the geronimo mailing lists (they especially notice when something is broken :-) and I think the official release of MyFaces 1.2 will be very well received. Best wishes, Paul On Jun 16, 2007, at 10:55 AM, Matthias Wessendorf wrote: Well, to be honest, JavaEE 5 isn't really wide adopted, yet. And in most cases, MyFaces1.1.x + Facelets + Spring just work fine. Jetty/Tomcat is enough :) -Matthias On 6/16/07, Bruno Aranda [EMAIL PROTECTED] wrote: Damn it guys! Is there no interest in releasing MyFaces 1.2? :-( Thanks Matthias, Bruno On 16/06/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, thanks for voting. We don't release these artifacts, since we got only two +1 votes. Means, takes longer to get MyFaces 1.2 out, since these bits are a dependency. Greetings, Matthias On 6/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 120 release of the Trinidad MyFaces Plugins out. This is the first release of the 1.2 plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.0 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/trinidad120plugins/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[jira] Commented: (MYFACES-1656) Wrong coercing in #{} for h:inputText
[
https://issues.apache.org/jira/browse/MYFACES-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502344
]
Paul McMahan commented on MYFACES-1656:
---
From a visual inspection of jetty it looks like it uses the jsp-2.1 RI from
glassfish, which includes the el api.Geronimo uses tomcat's el api, see:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_13/java/javax/el/
(Actually geronimo uses a copy of tomcat's el api, but will soon switch back
over to tomcat's original version now that they are published to maven central
repo)
If we can narrow this problem down to a bug in EL and provide a patch to tomcat
then geronimo will be able to pick up that change.
Wrong coercing in #{} for h:inputText
---
Key: MYFACES-1656
URL: https://issues.apache.org/jira/browse/MYFACES-1656
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0-SNAPSHOT
Environment: geronimo 2.0 - M6, winxp
Reporter: Alexander Zynevich
Attachments: Bad coercing.jpg
I tried to run GuessNumber application on the latest SNAPSHOT of 1.2.0
Looks like is cannot coerce #{integer-value} for string. A week ago this code
worked. Now it prints:
/greeting.jsp(44,3) '#{UserNumberBean.userNumber}'
java.lang.IllegalArgumentException: argument type mismatch
snip from bean:
public void setUserNumber(Integer user_number) {
userNumber = user_number;
System.out.println(Set userNumber + userNumber);
}
public Integer getUserNumber() {
System.out.println(get userNumber + userNumber);
return userNumber;
}
snip from jsp:
h:inputText id=userNo value=#{UserNumberBean.userNumber}
validator=#{UserNumberBean.validate}/
you may download war from GERONIMO-3167
see also screen shot
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (MYFACES-1262) JSR-252 Issue #99: Specified Java EE 5 Generics usage where applicable.
The Java EE TCK actually does verify all the signatures. Today it was announced that the Geronimo application server has passed TCK and it uses MyFaces for JSF 1.2. So we should be OK here. Best wishes, Paul On Jun 5, 2007, at 4:46 PM, Mike Kienenberger wrote: We're talking about the jsf-api method signatures. Either they match the spec/JSF RI api docs, or they don't :-) Yes, it's painful to go through and verify each one (I'd think that the TCK would do that), but I don't see how it can be avoided. On 6/5/07, Bruno Aranda (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1262? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Aranda resolved MYFACES-1262. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT I guess we can close this one, as it is difficult to assess when will be done and the current implementation works fine JSR-252 Issue #99: Specified Java EE 5 Generics usage where applicable. - -- Key: MYFACES-1262 URL: https://issues.apache.org/jira/browse/ MYFACES-1262 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assignee: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Specified Java EE 5 Generics usage where applicable. https://javaserverfaces-spec-public.dev.java.net/issues/ show_bug.cgi?id=99 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
On May 25, 2007, at 4:31 AM, Manfred Geiler wrote: Arguments pro 2.x.y: A20.1. Tomcat does the same. They do not align there container versions to the spec and nobody complains. This is an excellent proposal and clearly takes all the factors we have discussed into account. I would have no hesitation in supporting this approach. Since Tomcat's approach has factored into this proposal I would feel remiss if I did not at least mention one other alternative that is in use at ASF today by the Geronimo project. I don't necessarily mean to imply that Geronimo's approach is better than Manfred's proposal or that it even addresses all the issues our discussion has identified. But I think that for the sake of consistency across ASF that there is merit in at least giving it a moment of consideration. As an implementer of many different Java EE specs[1] the Geronimo project has contended with this issue of using spec vs. release version. Adding some further complication is that fact that each spec is released and maintained independently from each other and from Geronimo's core application server.The current approach Geronimo takes is to use *both* version numbers, making the spec version part of the artifact name, and assigning the release version independently of the spec version. This topic is frequently discussed by the Geronimo team. See [2] and [3] below for background, including some feedback from the Maven team. For example, using this approach Geronimo has released four versions of the JavaMail 1.3.1 specification. The pom.xml for the first version looks like this: artifactIdgeronimo-javamail_1.3.1_spec/artifactId version1.0/version the second like this, and so on: artifactIdgeronimo-javamail_1.3.1_spec/artifactId version1.1/version Maven produces jar names like this: geronimo-javamail_1.3.1_spec-1.0.jar This approach has not been without its detractors. But it has some advantages, two of the most important being that for release management you can account for both spec and release versioning simultaneously, and users can tell the spec and release version by looking at the jar. It has also proven to work fine with Maven (version ranges, dependency resolution, etc), and the Maven team has been actively working with Geronimo to develop and improve the tooling to support this approach [4]. Like I said, I don't mean to derail Manfred's excellent proposal which I think could in fact work better for MyFaces in the end. The main reason I bring this additional information to light is because while MyFaces is for all practical purposes an autonomous project I agree with Manfred that for the sake of consistency we should take what other ASF projects are doing into consideration. Best wishes, Paul [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/ [2] http://tinyurl.com/3yqmzs [3] http://tinyurl.com/yqu6cn [4] http://tinyurl.com/yur73u
[jira] Created: (MYFACES-1644) API signature error problem with UIComponentTagBase
API signature error problem with UIComponentTagBase --- Key: MYFACES-1644 URL: https://issues.apache.org/jira/browse/MYFACES-1644 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT JSF 1.2 javadoc for UIComponentTagBase requires protected static Logger log = Logger.getLogger(javax.faces.webapp); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
1.2 API signature problem with UIComponentTagBase
This line was removed from javax/faces/webapp/UIComponentTagBase as part of rev 540403. protected static Logger log = Logger.getLogger (javax.faces.webapp); From the commit log it seems that line was removed for binary compatibility with the RI. However, the signature test is now failing since that field is required. I assume that misalignment with the spec was unintentional and changed it back in rev 541371. But if binary compatibility with the RI is more preferable then let's discuss changing it back. Best wishes, Paul
[jira] Resolved: (MYFACES-1644) API signature error with UIComponentTagBase
[ https://issues.apache.org/jira/browse/MYFACES-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1644. --- Resolution: Fixed API signature error with UIComponentTagBase --- Key: MYFACES-1644 URL: https://issues.apache.org/jira/browse/MYFACES-1644 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT JSF 1.2 javadoc for UIComponentTagBase requires protected static Logger log = Logger.getLogger(javax.faces.webapp); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1639) Some DTDs hold Sun Microsystems copyrights.
[ https://issues.apache.org/jira/browse/MYFACES-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497687 ] Paul McMahan commented on MYFACES-1639: --- the current12 branch also contains the DTDs. do you think we should copy your hand typed versions into that branch? Some DTDs hold Sun Microsystems copyrights. Key: MYFACES-1639 URL: https://issues.apache.org/jira/browse/MYFACES-1639 Project: MyFaces Core Issue Type: Task Components: General Affects Versions: 1.1.4 Reporter: Grant Smith Assigned To: Grant Smith For now, I will follow GERONIMO's lead and retype the DTDs by hand, with ASF headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
+1 for 1.2, based on the advantages of aligning with spec releases. Best wishes, Paul On May 18, 2007, at 12:41 AM, Zubin Wadia wrote: +1 for 1.2. IMO, Save 2.0 for JSF2.0. It's just easier to explain to non- community members that way and keeps it aligned with the spec releases. Cheers, Zubin. On 5/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred
[jira] Commented: (MYFACES-1633) Incorret view rendering after postback
[ https://issues.apache.org/jira/browse/MYFACES-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496686 ] Paul McMahan commented on MYFACES-1633: --- Bruno, is GERONIMO-3167 a manifestation of this problem? Incorret view rendering after postback -- Key: MYFACES-1633 URL: https://issues.apache.org/jira/browse/MYFACES-1633 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Bruno Aranda Priority: Critical The rendered code and the html code from the page are not ordered correctly. Visual mess. Easily observable when running the simple examples with our 1.2 implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] Create a notifications mailing list
+1 On May 13, 2007, at 3:09 PM, Wendy Smoak wrote: I'd like to create [EMAIL PROTECTED] for automated messages from Continuum. I feel that more people are interested in watching commits than notifications. Particularly in the case of new contributors who may start as users, then watch the dev list, then perhaps want to (just) review commits. Continuum notifications may just be noise at this point. Also, having separate lists gives each person control over the incoming info. For example, you might want to receive commits in email, but watch the notifications on an RSS feed. Thoughts? Thanks, Wendy
Re: publishing 1.2.0-SNAPSHOT
1.2.0 snapshots are updated. Best wishes, Paul On May 7, 2007, at 2:10 PM, Paul McMahan wrote: I notice that the 1.2 snapshots haven't been published since 28- Apr-2007. I think it's due to a build failure on continuum (?) but my 1.2 local build succeeds, so I'm not sure how to address that. Until that gets resolved are there any concerns if I manually publish 1.2 snapshots to the repo? Best wishes, Paul
publishing 1.2.0-SNAPSHOT
I notice that the 1.2 snapshots haven't been published since 28- Apr-2007. I think it's due to a build failure on continuum (?) but my 1.2 local build succeeds, so I'm not sure how to address that. Until that gets resolved are there any concerns if I manually publish 1.2 snapshots to the repo? Best wishes, Paul
[jira] Created: (MYFACES-1622) support headerClass and footerClass at h:column level
support headerClass and footerClass at h:column level
-
Key: MYFACES-1622
URL: https://issues.apache.org/jira/browse/MYFACES-1622
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
headerClass and footerClass attributes specified at the h:column level should
override style attributes specified at the UIData level.
page 7 of JSF 1.2 spec, section titled General changes says:
{quote}
Added headerClass and footerClass attributes at the h:column level. Please
see Section8.5 Standard HTML RenderKit Implementation for more details.
{quote}
Further details are available in the header section of :
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Datajavax.faces.Table.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1622) support headerClass and footerClass at h:column level
[
https://issues.apache.org/jira/browse/MYFACES-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1622.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
support headerClass and footerClass at h:column level
-
Key: MYFACES-1622
URL: https://issues.apache.org/jira/browse/MYFACES-1622
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
Fix For: 1.2.0-SNAPSHOT
headerClass and footerClass attributes specified at the h:column level should
override style attributes specified at the UIData level.
page 7 of JSF 1.2 spec, section titled General changes says:
{quote}
Added headerClass and footerClass attributes at the h:column level. Please
see Section8.5 Standard HTML RenderKit Implementation for more details.
{quote}
Further details are available in the header section of :
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Datajavax.faces.Table.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1607) implement ResourceBundleResolver.getFeatureDescriptors()
implement ResourceBundleResolver.getFeatureDescriptors() Key: MYFACES-1607 URL: https://issues.apache.org/jira/browse/MYFACES-1607 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Flesh out the implementation of ResourceBundleResolver.getFeatureDescriptors() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1607) implement ResourceBundleResolver.getFeatureDescriptors()
[ https://issues.apache.org/jira/browse/MYFACES-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1607. --- Resolution: Fixed implement ResourceBundleResolver.getFeatureDescriptors() Key: MYFACES-1607 URL: https://issues.apache.org/jira/browse/MYFACES-1607 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Flesh out the implementation of ResourceBundleResolver.getFeatureDescriptors() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces community BOF at J1
Sounds like fun. Too bad I can't make J1 this year to meet the team in person. Best wishes, Paul On Apr 27, 2007, at 1:02 PM, Martin Marinschek wrote: Hi *, we (Manfred and me, but get in contact with us if you are at J1, we'll share the stage!) have been accepted for a MyFaces community BOF at J1, and as the community is the most important asset in this project, we'd like to talk about the community. What I've thought about is to do a session where we show a photo of each of the MyFaces committers, nationality (so that we can show how different we are in region), age, and a funny statement with regards to her/him (either what she/he said or what one can say about her/him), and then what she/he's done for the MyFaces project (so we're introducing MyFaces and what it can do by introducing the MyFaces community). Now I've got three questions for you: - Is that an idea you'd approve of? - Would you be willing to send me photos until Tuesday the latest? - Would you be against being shown on a J1 presentation with your photo, plus a funny remark, which will hopefully be tasteful and not disgraceful ;) regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
[ https://issues.apache.org/jira/browse/MYFACES-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1582. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan replaced the copyrighted version with a version typed in by hand from the jsf 1.2 specification web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: web-facesconfig_1_2.xsd web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1604) commandLink with disabled=true should render children and id
commandLink with disabled=true should render children and id Key: MYFACES-1604 URL: https://issues.apache.org/jira/browse/MYFACES-1604 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan A disabled commandLink correctly renders as a span but needs to include id attribute and also render its children. See http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1604) commandLink with disabled=true should render children and id
[ https://issues.apache.org/jira/browse/MYFACES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1604. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT commandLink with disabled=true should render children and id Key: MYFACES-1604 URL: https://issues.apache.org/jira/browse/MYFACES-1604 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT A disabled commandLink correctly renders as a span but needs to include id attribute and also render its children. See http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
[
https://issues.apache.org/jira/browse/MYFACES-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1592.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
patch applied with a minor modification, thanks Martin!
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Martin Haimberger
Fix For: 1.2.0-SNAPSHOT
Attachments: MYFACES-1592.patch
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /mytest.jsp][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it
returns an Object. Changing the type for the value attribute in h.tld as
shown below avoids the exception and passes the currently failing TCK test
for that component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1595) spec compliance for HtmlCommandButton
spec compliance for HtmlCommandButton - Key: MYFACES-1595 URL: https://issues.apache.org/jira/browse/MYFACES-1595 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Per the HtmlCommandButton spec at: http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/component/html/HtmlCommandButton.html need to correct two issues with HtmlCommandButton renderer to match the spec: - render readonly=readonly when button.isReadOnly() returns true, otherwise don't render the attribute - render type=reset when button.getType() returns reset (case sensitive), otherwise render type=submit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1595) spec compliance for HtmlCommandButton
[ https://issues.apache.org/jira/browse/MYFACES-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1595. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT spec compliance for HtmlCommandButton - Key: MYFACES-1595 URL: https://issues.apache.org/jira/browse/MYFACES-1595 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Per the HtmlCommandButton spec at: http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/component/html/HtmlCommandButton.html need to correct two issues with HtmlCommandButton renderer to match the spec: - render readonly=readonly when button.isReadOnly() returns true, otherwise don't render the attribute - render type=reset when button.getType() returns reset (case sensitive), otherwise render type=submit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1594) Passthrough attribute acceptcharset for form not being rendered
[ https://issues.apache.org/jira/browse/MYFACES-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1594. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT applied fix similar to MYFACES-1510 Passthrough attribute acceptcharset for form not being rendered - Key: MYFACES-1594 URL: https://issues.apache.org/jira/browse/MYFACES-1594 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT The attribute acceptcharset for the form is not being rendered. Probably the fix lies in the rendering of the passthrough attributes for the form component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/mytest.jsp][Class: javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it returns
an Object. Changing the type for the value attribute in h.tld as shown below
avoids the exception and passes the currently failing TCK test for that
component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
boolean value for selectBooleanCheckbox
In order to address https://issues.apache.org/jira/browse/ MYFACES-1592 my current thinking is that the value attribute for the selectBooleanCheckbox tag needs to use: deferred-value typeboolean/type /deferred-value instead of: deferred-value/deferred-value Does that sound like the right approach? If so then I'm having some trouble figuring out how to make the maven faces plugin generate the tag this way since the value attribute is already present via inheritance. Any pointers on how to accomplish this? Best wishes, Paul
[jira] Commented: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
[
https://issues.apache.org/jira/browse/MYFACES-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490987
]
Paul McMahan commented on MYFACES-1592:
---
Thanks Martin, I haven't looked at the RI and didn't realize that it also
declares SelectBooleanCheckbox as an object. So based on that observation I
think your approach is right and will apply your patch unless there is some
objection.
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Martin Haimberger
Attachments: MYFACES-1592.patch
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /mytest.jsp][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it
returns an Object. Changing the type for the value attribute in h.tld as
shown below avoids the exception and passes the currently failing TCK test
for that component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1593) javax.el.CompositeELResolver cannot resolve managed beans
javax.el.CompositeELResolver cannot resolve managed beans - Key: MYFACES-1593 URL: https://issues.apache.org/jira/browse/MYFACES-1593 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan With a managed bean defined in faces-config.xml like this: managed-bean managed-bean-name mybean /managed-bean-name managed-bean-class MyBean /managed-bean-class managed-bean-scope request /managed-bean-scope /managed-bean FacesCompositeResolver can resolve the bean but javax.el.CompositeELResolver cannot. It does not insulate the ManagedBeanResolver with the code in VariableResolverToELResolver that sets the propertyResolved flag back to false after ManagedBeanResolver returns null and relies on ScopedAttributeResolver to return it from the proper scope later. For example, this code will fail to resolve the managed bean: PageContext context = JspFactory.getDefaultFactory().getPageContext( ... ); ELResolver resolver = context.getELResolver(); // jasper returns a javax.el.CompositeELResolver MyBean mybean = resolver.getValue(context, null, mybean); // returns null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
On Apr 19, 2007, at 10:25 AM, Martin Marinschek wrote: oh, yes. I had overlooked the return null at the end of the method - that was different before. Brief update here - I ended up changing the behavior of ManagedBeanResolver to go ahead and return the managed bean right away due to : https://issues.apache.org/jira/browse/MYFACES-1593 Best wishes, Paul
[jira] Resolved: (MYFACES-1593) javax.el.CompositeELResolver cannot resolve managed beans
[ https://issues.apache.org/jira/browse/MYFACES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1593. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan javax.el.CompositeELResolver cannot resolve managed beans - Key: MYFACES-1593 URL: https://issues.apache.org/jira/browse/MYFACES-1593 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT With a managed bean defined in faces-config.xml like this: managed-bean managed-bean-name mybean /managed-bean-name managed-bean-class MyBean /managed-bean-class managed-bean-scope request /managed-bean-scope /managed-bean FacesCompositeResolver can resolve the bean but javax.el.CompositeELResolver cannot. It does not insulate the ManagedBeanResolver with the code in VariableResolverToELResolver that sets the propertyResolved flag back to false after ManagedBeanResolver returns null and relies on ScopedAttributeResolver to return it from the proper scope later. For example, this code will fail to resolve the managed bean: PageContext context = JspFactory.getDefaultFactory().getPageContext( ... ); ELResolver resolver = context.getELResolver(); // jasper returns a javax.el.CompositeELResolver MyBean mybean = resolver.getValue(context, null, mybean); // returns null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1588) managed beans are not resolved when scope is none
[
https://issues.apache.org/jira/browse/MYFACES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1588.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
managed beans are not resolved when scope is none
---
Key: MYFACES-1588
URL: https://issues.apache.org/jira/browse/MYFACES-1588
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
Fix For: 1.2.0-SNAPSHOT
When a manged bean is defined in an application's config like this:
managed-bean
managed-bean-nameMyBean/managed-bean-name
managed-bean-classfoo.MyBean/managed-bean-class
managed-bean-scopenone/managed-bean-scope
/managed-bean
the bean should be resolvable from a ValueBinding but instead it returns null
as shown below:
ValueBinding binding = application.createValueBinding(#{MyBean});
binding.getValue(facesContext); // returns null;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: publishing 1.2.0 snapshots to m2 snapshot repo
I verified that the new 1.2.0 snapshots are available in the snapshot repository. Thanks Mathias! Best wishes, Paul On Apr 19, 2007, at 6:51 PM, Mathias Brökelmann wrote: I fixed the continuum setup. The problem where some orphan lock files of the embedded derby database: rm /local/continuum-1.1-SNAPSHOT/data/continuum/database/*.lck and restarted continuum. The build should now be up and the artifacts be deployed to the snapshot repository. 2007/4/19, Wendy Smoak [EMAIL PROTECTED]: On 4/19/07, Paul McMahan [EMAIL PROTECTED] wrote: Looks like the 1.2.0 snapshot was last published to the snapshot repo on 11-Apr-2007.Are the 1.2.0 snapshots no longer being published automatically? No. There's some discussion in the list archives. Apparently no one can log into the zone, and the Continuum nightly builds are failing. One of these days someone will have time to coordinate with infrastructure to reboot it or figure out how to regain access. Solaris is not my native language, unfortunately. Meanwhile any committer should have permission to 'mvn deploy' updated snapshots. -- Wendy -- Mathias
Re: MyFaces and HTML 4.01
On Apr 20, 2007, at 12:24 PM, Mario Ivankovits wrote: Belen, Marco wrote: In order 'choose' an unique prefix, why not re-use a common way to create unique names in Java: Use a package-structure. There for until it can be configured in the web.xml how about using org_apache_myfaces_ as the clientID-prefix. My first reaction on this was: No, please don't as this will greatly increase the size of the rendered html page if you have tables or trees on it. On the other hand, if one would like to have short ids its simple to configure the id on the component level instead of using the autogenerated one - and IMHO its better to use manual component ids then the automatic created one as this makes the rendered page more readable (in case you have to look at the html source) So I'll have not problem to use this big clientId, just, maybe a o_a_m_id would make it too. I had the same reaction about how this change could increase the size of the rendered page. True that it could be configured at the component level, but for the sake of performance how about taking a position that the autogenerated one is as small as reasonably possible and rely on the user to replace it in the case of a collision? i.e. the user optionally lengthens, not shortens, the autogenerated id. Best wishes, Paul
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
Thanks for the review Martin. I agree that the persistence mechanism
for managed beans was already working OK. i.e. when a managed bean
has scope none it was not persisted in a scope. But the problem I
encountered was that the CompositeELResolver was not able to resolve
managed beans with scope none.Managed beans with scope
request, session, or application could be resolved because
after ManagedBeanResolver creates the bean it persists it in a scope,
returns null, and then relies on ScopedAttributeResolver to resolve
it further down the call stack. But when scope is none persisting
the bean in scope was a no-op, so the exchange between
ManagedBeanResolver and ScopedAttributeResolver didn't end up
resolving the bean for CompositeELResolver.
The second change allows ManagedBeanResolver.getValue() to go ahead
and return the managed bean immediately instead of returning null.
The first change (removing none from s_standardScopes) was really
just clean up since that code won't be used.
Best wishes,
Paul
On Apr 18, 2007, at 5:13 PM, Martin Marinschek wrote:
Hi Paul,
if you do the first change (introduce a scope where put does nothing),
I don't see why the second one needs to be done - putting will do
nothing, so you don't need the extra-check for none, right?
regards,
Martin
On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote:
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/
apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
=
=
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope
())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
On Apr 19, 2007, at 10:25 AM, Martin Marinschek wrote: But still - you are short-circuiting the cyclic reference check now - if I have a bean now which has scope none, and has a managed-property referring to the bean again, then we'll run into an infinite loop, right? Yes that's true, and thanks for pointing it out. I'll need to stare at this a bit longer to figure out a better solution. Suggestions are welcome. Best wishes, Paul
publishing 1.2.0 snapshots to m2 snapshot repo
Looks like the 1.2.0 snapshot was last published to the snapshot repo on 11-Apr-2007.Are the 1.2.0 snapshots no longer being published automatically? Best wishes, Paul
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
Cycle reference check should be fixed now in r530517. thanks again for the peer review. Best wishes, Paul On Apr 19, 2007, at 10:25 AM, Martin Marinschek wrote: But still - you are short-circuiting the cyclic reference check now - if I have a bean now which has scope none, and has a managed-property referring to the bean again, then we'll run into an infinite loop, right?
Re: Use 1.2 as current
Manfred's idea sounds good to me. I especially appreciate that it will cause minimal disruption. Best wishes, Paul On Apr 18, 2007, at 7:21 AM, Manfred Geiler wrote: Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. 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
[jira] Created: (MYFACES-1587) generated h.tld doesn't conform to schema
generated h.tld doesn't conform to schema - Key: MYFACES-1587 URL: https://issues.apache.org/jira/browse/MYFACES-1587 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The TLD at target/classes/META-INF/h.tld that is generated ( IIUC ) by the maven plugin does not conform to the schema it references http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd. See GERONIMO-3038 for an exhaustive list of parse errors. The file at core/impl/src/main/tld/myfaces_html.tld appears to be a more accurate version of this TLD but does not end up in the myfaces-impl jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1574) HtmlOutputLink returns the wrong renderer type
[
https://issues.apache.org/jira/browse/MYFACES-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1574.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
Not sure when/how this was fixed but HtmlOutputLink returns the correct
renderer type now.
HtmlOutputLink returns the wrong renderer type
--
Key: MYFACES-1574
URL: https://issues.apache.org/jira/browse/MYFACES-1574
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Matthias Weßendorf
Fix For: 1.2.0-SNAPSHOT
The generated java src for javax.faces.component.html.HtmlOutputLink sets the
renderer type to javax.faces.Label :
public HtmlOutputLink()
{
setRendererType(javax.faces.Label);
}
It should instead set the renderer type to javax.faces.Link
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1588) managed beans are not resolved when scope is none
managed beans are not resolved when scope is none
---
Key: MYFACES-1588
URL: https://issues.apache.org/jira/browse/MYFACES-1588
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
When a manged bean is defined in an application's config like this:
managed-bean
managed-bean-nameMyBean/managed-bean-name
managed-bean-classfoo.MyBean/managed-bean-class
managed-bean-scopenone/managed-bean-scope
/managed-bean
the bean should be resolvable from a ValueBinding but instead it returns null
as shown below:
ValueBinding binding = application.createValueBinding(#{MyBean});
binding.getValue(facesContext); // returns null;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
[jira] Updated: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
[ https://issues.apache.org/jira/browse/MYFACES-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1584: -- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan Status: Resolved (was: Patch Available) DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Resolution: Fixed Status: Resolved (was: Patch Available) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577-2.patch, MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is 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-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486952 ] Paul McMahan commented on MYFACES-1577: --- It was actually the setValue() errors that prompted me to provide the patch. But while working on the patch I also noticed the discrepancy between getValue() and the spec/javadoc so I adjusted its behavior as well. As they say, no good deed goes unpunished :-) I believe that the current behavior of getValue() is consistent with the spec/javadoc and that the test cases are in error. Last week I created GERONIMOTCK-22 and GERONIMOTCK-23 to track challenges for those test cases. But while that gets sorted out I agree that getValue() should be reverted back to its original form which as I recall threw the exceptions like you described. PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Dennis Byrne Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Status: Patch Available (was: Reopened) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Dennis Byrne Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
[ https://issues.apache.org/jira/browse/MYFACES-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1584: -- Status: Patch Available (was: Open) DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
[ https://issues.apache.org/jira/browse/MYFACES-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486574 ] Paul McMahan commented on MYFACES-1582: --- correct reference is GERONIMO-2630 web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: web-facesconfig_1_2.xsd web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Are the web-facesconfig_1_0.dtd and web-facesconfig_1_1.dtd files really SUN confidential/proprietary property?
On Apr 2, 2007, at 5:53 PM, Martin Marinschek wrote: First - it's just a convenience, so you could remove it if you wanted, with the possible disadvantages that Mike mentioned. Second - the files were originally included, I removed them after licensing issues were mentioned - then there was a lengthy discussion (which I don't remember anymore), after which I committed them again as they seemed to be save. Typing them in by hand might be a save way to get around all eventual problems. I attached a hand typed version of web-facesconfig_1_2.xsd to MYFACES-1582. Best wishes, Paul
Re: Are the web-facesconfig_1_0.dtd and web-facesconfig_1_1.dtd files really SUN confidential/proprietary property?
On Apr 2, 2007, at 11:38 AM, David Jencks wrote: Over in geronimo we noticed this text and have responded by: 1. for the schemas that we generate code from (using xmlbeans or jaxb) we checked the schemas into a non-publically-accessible repository (with our tck stuff) and generate the code there, and publish source and binary jars, both without the schemas themselves. 2. We also have an ongoing effort to produce unencumbered schemas. Apparently (IANAL) the actual schema/dtd is not copyrightable as it is an interface specification, the part that is copyrightable is the comments, annotations, etc. So, we have been typing up the schemas ourselves without any of the descriptive material. See this JIRA for more details on the effort in Geronimo that David mentioned. https://issues.apache.org/jira/browse/GERONIMO-2630 Typing the schemas in by hand is tedious but maybe not so bad if we divide and conquer. I'll volunteer to help if there's a consensus around that approach. There is a utility attached to the JIRA that can be used to compare schemas to make sure they are equivalent. Best wishes, Paul
[jira] Created: (MYFACES-1579) VariableResolver throws IllegalStateException because scope is unknown
VariableResolver throws IllegalStateException because scope is unknown -- Key: MYFACES-1579 URL: https://issues.apache.org/jira/browse/MYFACES-1579 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan VariableResolverImpl tries to determine if it was invoked through the faces chain or jsp chain by looking for an attribute (Scope.getClassName()) in the RequestMap. However, that attribute is only set during the span of a call to FacesCompositeELResolver.getValue(). See FacesCompositeELResolver#invoke(), which calls setScope() and then unsetScope(). Therefore the following code always throws IllegalStateException VariableResolver resolver = application.getVariableResolver(); Object result = resolver.resolveVariable(facesContext, param); because when VariableResolverImpl.resolveVariable() looks for the scope in the request map (which happens outside the getValue() call) its always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1579) VariableResolver throws IllegalStateException because scope is unknown
[ https://issues.apache.org/jira/browse/MYFACES-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1579: -- Status: Patch Available (was: Open) VariableResolver throws IllegalStateException because scope is unknown -- Key: MYFACES-1579 URL: https://issues.apache.org/jira/browse/MYFACES-1579 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1579.patch VariableResolverImpl tries to determine if it was invoked through the faces chain or jsp chain by looking for an attribute (Scope.getClassName()) in the RequestMap. However, that attribute is only set during the span of a call to FacesCompositeELResolver.getValue(). See FacesCompositeELResolver#invoke(), which calls setScope() and then unsetScope(). Therefore the following code always throws IllegalStateException VariableResolver resolver = application.getVariableResolver(); Object result = resolver.resolveVariable(facesContext, param); because when VariableResolverImpl.resolveVariable() looks for the scope in the request map (which happens outside the getValue() call) its always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reopened MYFACES-1572: --- still seeing the problem with getRows in generated UIData class. seems that _rowsSet assignment needs to be in setRows() method in the template. getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1572: -- Status: Patch Available (was: Reopened) getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1572.2.patch UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Status: Patch Available (was: Open) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is 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-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484691 ] Paul McMahan commented on MYFACES-1572: --- correction -- I meant to say the patch moves assignment of _rowsSet to the *setRows()* method getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1572.2.patch UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1574) HtmlOutputLink returns the wrong renderer type
HtmlOutputLink returns the wrong renderer type
--
Key: MYFACES-1574
URL: https://issues.apache.org/jira/browse/MYFACES-1574
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
The generated java src for javax.faces.component.html.HtmlOutputLink sets the
renderer type to javax.faces.Label :
public HtmlOutputLink()
{
setRendererType(javax.faces.Label);
}
It should instead set the renderer type to javax.faces.Link
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1575) MethodBinding.invoke() should provide cause exception
[ https://issues.apache.org/jira/browse/MYFACES-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1575: -- Status: Patch Available (was: Open) MethodBinding.invoke() should provide cause exception - Key: MYFACES-1575 URL: https://issues.apache.org/jira/browse/MYFACES-1575 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1575.patch When javax.faces.el.MethodBinding.invoke() catches an Exception the EvaluationException it subsequently throws should include the cause property of the original exception. See: http://java.sun.com/javaee/5/docs/api/javax/faces/el/MethodBinding.html#invoke(javax.faces.context.FacesContext,%20java.lang.Object[])exception) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1576) PropertyResolver.getType() should check arguments
PropertyResolver.getType() should check arguments - Key: MYFACES-1576 URL: https://issues.apache.org/jira/browse/MYFACES-1576 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan According to the spec PropertyResolver.getType(Object, int) should throw PropertyNotFoundException when the int is out of bounds or Object is null. Also PropertyResolver.getType(Object, property) should throw PropertyNotFoundException when property is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1576) PropertyResolver.getType() should check arguments
[ https://issues.apache.org/jira/browse/MYFACES-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1576: -- Status: Patch Available (was: Open) PropertyResolver.getType() should check arguments - Key: MYFACES-1576 URL: https://issues.apache.org/jira/browse/MYFACES-1576 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1576.patch According to the spec PropertyResolver.getType(Object, int) should throw PropertyNotFoundException when the int is out of bounds or Object is null. Also PropertyResolver.getType(Object, property) should throw PropertyNotFoundException when property is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Critical UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1560) WebXmlParser should log debug instead of warn
WebXmlParser should log debug instead of warn - Key: MYFACES-1560 URL: https://issues.apache.org/jira/browse/MYFACES-1560 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Minor When WebXmlParser ignores a child of servlet or filter it logs a debug message, as expected. However, when it ignores a child of servlet-mapping or filter-mapping it logs a warning message. It should log a debug message instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1560) WebXmlParser should log debug instead of warn
[ https://issues.apache.org/jira/browse/MYFACES-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1560: -- Status: Patch Available (was: Open) WebXmlParser should log debug instead of warn - Key: MYFACES-1560 URL: https://issues.apache.org/jira/browse/MYFACES-1560 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Minor Attachments: MYFACES-1560.patch When WebXmlParser ignores a child of servlet or filter it logs a debug message, as expected. However, when it ignores a child of servlet-mapping or filter-mapping it logs a warning message. It should log a debug message instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: getAlign() and setAlign() not in JSF 1.2 spec
Thanks Dennis! On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote: I removed it from the code generator. Some of the renderers still look for the 'align' attribute but I'll get to that later. Thanks, Dennis Byrne On 3/2/07, Paul McMahan [EMAIL PROTECTED] wrote: 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 -- Dennis Byrne
Re: @PreDestroy, Servlet API,
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
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.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
[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.
