[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361951 ] Mathias Broekelmann commented on MYFACES-985: - I will leave this issue open since it is working on SunĀ“s RI. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361950 ] Mathias Broekelmann commented on MYFACES-985: - You could also use the rendered attribute to switch on or off rendering a component. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361953 ] Andrew Kharchenko commented on MYFACES-985: OK. Thanx for advice. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1007) AUTO_SCROLL not always working with IE
AUTO_SCROLL not always working with IE -- Key: MYFACES-1007 URL: http://issues.apache.org/jira/browse/MYFACES-1007 Project: MyFaces Type: Improvement Components: Implementation Versions: 1.1.1 Environment: Windows XP Tomcat 5.5 et IE 6 sp2 Reporter: Antoine Sabot-Durand Priority: Minor In some case the autoscroll feature doesn't work in Internet explorer 6. Especially when the rendered HTML contains a lot of div. This is due to a bug in Internet Explorer. The solution I found is to modify the renderAutoScrollFunction method in org.apache.myfaces.renderkit.html.util class. I changed the following line : script.append(window.scrollTo().append(x).append(,).append(y).append();\n); to script.append(setTimeout('window.scrollTo().append(x).append(,).append(y).append()',1);\n); The setTimeout let IE finish whatever it has to to get a right layout of the HTML elements on the page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Looks pretty good. One minor change and a few questions. @Martin: Any comments on this before we go ahead? (We will keep your resource structure for now and try to find a solution for that later.) The next try: core (org.apache.myfaces) [This has a own release cycle] myfaces/core/trunk/pom.xml myfaces/core/trunk/myfaces-api/pom.xml myfaces/core/trunk/myfaces-impl/pom.xml myfaces/core/trunk/assembly/pom.xml modules modulemyfaces-api/module modulemyfaces-impl/module moduleassembly/module modules commons (org.apache.myfaces) [This has a own release cycle] === myfaces/commons/trunk/pom.xml myfaces/commons/trunk/src/main myfaces/commons/trunk/src/test myfaces/commons/trunk/src/site [myfaces/commons/assembly/pom.xml] NOTE: own assembly not really needed if released as part of the assembly of core and tomahawk OK. Now I understand why you skipped assembly for this one. tomahawk sandbox (org.apache.myfaces.tomahawk or org.apache.myfaces) [This has a own release cycle] [Sandbox is not released only in nightly build] === myfaces/tomahawk/trunk/pom.xml myfaces/tomahawk/trunk/src/main myfaces/tomahawk/trunk/src/test myfaces/tomahawk/trunk/src/site myfaces/tomahawk/trunk/example/pom.xml myfaces/tomahawk/trunk/sandbox/pom.xml myfaces/tomahawk/trunk/sandbox/src/main myfaces/tomahawk/trunk/sandbox/src/test myfaces/tomahawk/trunk/sandbox/src/site myfaces/tomahawk/trunk/assembly/pom.xml NOTE: If tomahawk has a different groupid the pom is not inherited Maybe we can start which the same groupid, if it make sense we can change it in a future version. (The tomahawk pom is to different) One more change ... myfaces/tomahawk/trunk/sandbox/example -- add this Sandbox examples will depend on sandbox components and the sandbox.jar. So they should probably be broken out separately. tools (org.apache.myfaces) [no assembly but release on a maven repository] = myfaces/tools/trunk/pom.xml myfaces/tools/trunk/maven-myfaces-plugin/pom.xml myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm NOTE: The maven-myfaces-plugin is an archtype-plugin for maven currently in the test repository. Oh yes Bruno's archtype plugin. Yes that should go there. site (org.apache.myfaces) [never released only for publishing the main site and the content of the main site] = myfaces/site/trunk/pom.xml NOTE: The main site can be part of core It could be part of core but I think your initial idea (as its own top level) is better. The site is for everything (not just core.) Process for updateing the site and publishing the nightly build and the snapshots: This is done by spezial task from the continuum server or by some scripts invoked on the myfaces.zone.apache.org server? I was thinking chron script on the zone. The idea is: We call some maven goals on some poms. mvn site:deploy in the site trunk for the main site mvn site:deploy in the core, commons and tomahawk trunk Sounds good. The one thing is that I would like links in the top level site for the module sites (and also in the reverse direction.) Do we just add those manually to the nav contents of each of the sites? Is there a way to do this in Maven? mvn deploy:deploy on all trunks for the shapshots And this will make the snapshots available to our own projects as well as those of our users right? Sounds good. mvn assembly:assembly for the nightly build on core and tomahawk Right. And maybe also for the official release? NOTE: I don't expect one spezial pom for this. I guess you're right. There isn't anything in Maven that will pull it all together for you. TODO find a better name for assembly We can try ;-) Build is already taken. Maybe publish? TODO setup solaris zone Its been setup. Nothing has been done with it yet. Once we get the builds working that will be the next step. TODO setup continuum TODO define a snapshot repository TODO define the process for updating the site and nightly buid Yes. This looks great Bernd. I like what we are settling on. Best Regards Bernd Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: There are transitive dependencies between commons and impl, or commons and tomahawk. Tomahawk actually has a dependency on api (a compile time one.) If you were to build tomahawk using maven you would need it. If you were to use tomahawk with your own project you would not need it. I'm thinking the provided scope would help us here? Yep, provided would be a good fit here. Anything that's a compile time dependency of library Foo where a user of Foo is responsible for supplying that dependency should be declared provided. -- Adam
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
The next round core (org.apache.myfaces) [This has a own release cycle] myfaces/core/trunk/pom.xml myfaces/core/trunk/myfaces-api/pom.xml myfaces/core/trunk/myfaces-impl/pom.xml myfaces/core/trunk/assembly/pom.xml modules modulemyfaces-api/module modulemyfaces-impl/module moduleassembly/module modules commons (org.apache.myfaces) [This has a own release cycle] === myfaces/commons/trunk/pom.xml myfaces/commons/trunk/src/main myfaces/commons/trunk/src/test myfaces/commons/trunk/src/site [myfaces/commons/assembly/pom.xml] NOTE: own assembly not really needed if released as part of the assembly of core and tomahawk tomahawk sandbox (org.apache.myfaces.tomahawk or org.apache.myfaces) [This has a own release cycle] [Sandbox is not released only in nightly build] === myfaces/tomahawk/trunk/pom.xml myfaces/tomahawk/trunk/src/main myfaces/tomahawk/trunk/src/test myfaces/tomahawk/trunk/src/site myfaces/tomahawk/trunk/example/pom.xml myfaces/tomahawk/trunk/sandbox/pom.xml myfaces/tomahawk/trunk/sandbox/src/main myfaces/tomahawk/trunk/sandbox/src/test myfaces/tomahawk/trunk/sandbox/src/site myfaces/tomahawk/trunk/sandbox/example/pom.xml myfaces/tomahawk/trunk/assembly/pom.xml NOTE: If tomahawk has a different groupid the pom is not inherited Maybe we can start which the same groupid, if it makes sense we can change it in a future version. (When the tomahawk pom is to different) tools (org.apache.myfaces) [no assembly but release on a maven repository] = myfaces/tools/trunk/pom.xml myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven currently in the test repository. site (org.apache.myfaces) [never released only for publishing the main site and the content of the main site] = myfaces/site/trunk/pom.xml NOTE: The main site can be part of core but the site is for everything not just for core Process for updating the site and publishing the nightly builds and the snapshots: === This is done by special task from the continuum server or by some chron scripts invoked on the myfaces.zone.apache.org server? The idea is: We call some maven goals on some poms. mvn site:deploy in the site trunk for the main site mvn site:deploy in the core, commons and tomahawk trunk NOTE: The links between the the top level site and the subprojects are added manually in the site.xml. The svn version of the site plugin is reactor aware(Then not all links between the subprojects must defined). mvn deploy:deploy on all trunks for deploying all artifacts to the snapshot repository mvn assembly:assembly for the nightly build on core and tomahawk NOTE: A release need some more steps, but maven has a plugin for this and a best practice. TODO find a better name for assembly (dist|build|bin)? TODO use the myfaces solaris zone for publish the site, nightly build, continuum.. TODO setup continuum TODO define a snapshot repository TODO define the process for updating the site and nightly build Best Regards Bernd
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
I don't think provided would be a good idea. If someone don't use tomahawk with myfaces-api and myfaces-impl. It would be easier to exclude myfaces-api and myfaces-impl and add a dependency to the RI. On the other side it would be painful for the normal user, the normal user would expect a compile dependency to myfaces-imp and myfaces-api. Adam Winer schrieb: On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: There are transitive dependencies between commons and impl, or commons and tomahawk. Tomahawk actually has a dependency on api (a compile time one.) If you were to build tomahawk using maven you would need it. If you were to use tomahawk with your own project you would not need it. I'm thinking the provided scope would help us here? Yep, provided would be a good fit here. Anything that's a compile time dependency of library Foo where a user of Foo is responsible for supplying that dependency should be declared provided. -- Adam -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/6/06, Adam Winer [EMAIL PROTECTED] wrote: Anything that's a compile time dependency of library Foo where a user of Foo is responsible for supplying that dependency should be declared provided. The Maven team usually puts it as ... can reasonably be expected to be provided at runtime. But Maven 2.0 doesn't have anything in place to deal with the choice of implementations situation, and so 'provided' is probably the best bet. This will put the responsibility of choosing an implementation on the user-- either by declaring a dependency or installing it in the container. (Or, I suppose, by using a container that already provides it.) I think that's reasonable. -- Wendy
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
And, once we get to JSF 1.2, provided is a clear winner because web containers will need to provide a JSF implementation. -- Adam On 1/6/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/6/06, Adam Winer [EMAIL PROTECTED] wrote: Anything that's a compile time dependency of library Foo where a user of Foo is responsible for supplying that dependency should be declared provided. The Maven team usually puts it as ... can reasonably be expected to be provided at runtime. But Maven 2.0 doesn't have anything in place to deal with the choice of implementations situation, and so 'provided' is probably the best bet. This will put the responsibility of choosing an implementation on the user-- either by declaring a dependency or installing it in the container. (Or, I suppose, by using a container that already provides it.) I think that's reasonable. -- Wendy
Re: searching for component
I'd go with vertical/horizontal or page/line. normal/reverse don't carry any meaning on what to expect. You should probably keep any further discussion to the mailing list (dev makes the most sense for this topic) as others might have better suggestions. Yes, definitely open a JIRA issue and attach your patches. It's certainly useful! Thanks for improving MyFaces! -Mike On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If I add an orientation parameter to the newspaperTable component, say orientation = normal (default) or reverse (or do you have a better idea?) should I contribute my change to myfaces? Via JIRA? Or is it useful enough? -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 12:37 PM To: [EMAIL PROTECTED] Subject: Re: searching for component On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks, but this goes vertical then horizontal, right? Can I make it go horizontal, then vertical? Hmm. You're right. I don't think the orientation is configurable at present. If you're considering creating a new component, I'd recommend looking at adding an orientation parameter to the newspaperTable component instead. I'd think you'd need to update the renderer for the component. Or you could look at using t:dataTable with a simple layout, and manually constructing the layout elements. You might also be able to do this using t:dataTable and t:columns and have the columns object break your list up into smaller lists. I suppose if you're using facelets you could manually construct the elements using c:forEach and stick them in an h:panelGrid. Can't think of any other options -- I'd probably go with adding orientation to newspaperTable if it were me, reversing the rows and columns. -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 12:19 PM To: MyFaces Discussion; [EMAIL PROTECTED] Subject: Re: searching for component http://myfaces.apache.org/tomahawk/newspaperTable.html probably does what you need. On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone know of an existing component that would allow a list (or array, collection, whatever) of h:panelGroup to be added to a h:panelGrid? That is, the backing bean has an ArrayList of objects (beans) to place in the cells, continuously in a table, left to right, then starting a new row when necessary. Sort of like the h:datatable has a list of rows. The List is fixed, so I could hard code the objects in the jsp, but there are 45 of them, so I'd rather not. I looked in the jsfcentral list of components, but couldn't find anything. If not, would this component be difficult to write? Thanks, Lance
ADF Source drop is available!
Well, we've finally gotten there and done it. A public drop of the ADF Faces source code is now available: http://homepage.mac.com/awiner/FileSharing.html Ted Husted will be copying this over to a people.apache.org site, at which point I'll take it down from mac.com so my bandwidth limit doesn't get completely clobbered. This should be (nearly) a fully buildable Maven 2.0 project, including a separate project of custom Maven 2 plugins ( which are also part of the contribution.) There's an Apache 2.0 LICENSE.txt at the root of the distribution, and to save people the work of building it, we've included the JARs and our demo WAR. John and I have spent most of this week cleaning up the codebase to eliminate compile and build dependencies on anything Oracle proprietary or non-ASF compatible. I'd say we're 99.9% of the way there - the remaining points being: - the lack (AFAIK) of a JSF impl in the public maven repository - obviously, we can trivially point that to MyFaces api and impl - Our tests use a Mock JSF impl that's just a mockmaker run over jsf-api - but that's not totally ASF-legit. We've included that jar in this distribution, but this needs to be redone the right way. Looking forward to all of your comments! Best regards, John and Adam
[jira] Created: (MYFACES-1008) security bug of myfaces
security bug of myfaces Key: MYFACES-1008 URL: http://issues.apache.org/jira/browse/MYFACES-1008 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1 Environment: windows 2000 ; SUN JDK1.4.0.3 ; Tomcat 5.0.28 Reporter: lantian Priority: Critical FACES SERVLET is not secure when useing prefix mapping such as/faces/* . users can access any contents in WEB-INF directory. try following in your faces website : http://localhost/mywebsite/faces/WEB-INF/web.xml http://localhost/mywebsite/faces/WEB-INF/lib/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira