[jira] Commented: (TOMAHAWK-1253) buffering not supported in the portal environment.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598564#action_12598564 ] Leonardo Uribe commented on TOMAHAWK-1253: -- I have disabled some changes on faces-config.xml inside tomahawk to avoid some problems we are tackling right now (better documentation, some refactoring and enhancements like Simon Kitching suggested). For make this work in portlets you must have this on faces-config of your web app: web.xml context-param param-nameorg.apache.myfaces.ADD_RESOURCE_CLASS/param-name param-valueorg.apache.myfaces.renderkit.html.util.NonBufferingAddResource/param-value /context-param This avoid the error present on the log file, usually caused because DefaultAddResource (which is buffered and the default AddResource) is used. faces-config.xml lifecycle !-- This PhaseListener is only necessary if NonBufferingAddResource is used -- phase-listenerorg.apache.myfaces.webapp.filter.ServeResourcePhaseListener/phase-listener /lifecycle factory faces-context-factoryorg.apache.myfaces.webapp.filter.TomahawkFacesContextFactory/faces-context-factory /factory buffering not supported in the portal environment. -- Key: TOMAHAWK-1253 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1253 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.7-SNAPSHOT Environment: MyFaces1.1.5,Tomahawk.1.1.7-Snapshot, Liferay4.3.3 Reporter: Rashmi Priority: Blocker Fix For: 1.1.7-SNAPSHOT Attachments: error_log.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of Trinidad 1.2.8
I found a related issue (in wicket). Looks like a JDK bug. Let me search my archive, so that we can have a fix for 1.x9... Sent from my iPod. Am 21.05.2008 um 02:40 schrieb Scott O'Bryan [EMAIL PROTECTED]: Edward, go ahead and contribute a patch to either of those bugs. Any idea on an ETA? On May 20, 2008, at 5:33 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: -1 Trinidad-73/Trinidad-978 is a showstopper issue for my application. Willing to contribute labor to get a fix for this problem into 1.0.8. Thank you, Ed On 5/20/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok Paul, TRINIDAD-1083 has been applied to both trunks, the 1.0.8 label and the 1.2.8 label. All of the artifacts have been regenerated. When you test it, give me your +1 and I think we're ready to release. Scott Scott O'Bryan wrote: Cool, thanks Matthias. I'm currently regenerating the artifacts for 1.2.8 and 1.0.8. They should be up in about an hour. Download from home is fast, but upload it REALLY SLOW.. Scott Matthias Wessendorf wrote: Hi, We need 3 +1 votes. 2.5 is not enough. Sounds like we need to wait for the 1.2.8 fix... Sent from my iPod. Am 20.05.2008 um 02:05 schrieb Scott O'Bryan [EMAIL PROTECTED] : Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/ DebugApacheChart1_2_8. js; jsessionid= 0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133 . However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +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, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
[jira] Commented: (TRINIDAD-73) trinidad-impl.jar file is left open during execution
[ https://issues.apache.org/jira/browse/TRINIDAD-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598581#action_12598581 ] Simon Kitching commented on TRINIDAD-73: Apache Commons Digester also struct this issue. Maybe the patch that fixed Digester could be useful to read. See: http://issues.apache.org/jira/browse/DIGESTER-29 trinidad-impl.jar file is left open during execution Key: TRINIDAD-73 URL: https://issues.apache.org/jira/browse/TRINIDAD-73 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.1-core Reporter: Adam Winer Fix For: 1.0.2-core When running a Trinidad application, trinidad-impl.jar is getting locked with open FileInputStream objects. When GC occurs, the FileInputStreams are getting cleared, but as new FileInputStreams are opened on each request, the file is eternally locked. Other files are likely getting locked too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] Should a non-J2EE demo war be added to the distribution?
The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: 1.0.8 Release
Hi Ed, https://issues.apache.org/jira/browse/TRINIDAD-73 there are some infos for creating a patch / fix for this. Greetings, Matthias On Tue, May 20, 2008 at 10:51 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: I don't have a vote, but could the Too many open files problem documented in JIRA issues TRINIDAD-73, TRINIDAD-806, and TRINIDAD-978 get fixed prior to this release? I have a high volume system built on MyFaces/Trinidad that really needs to go into production in late June. A fix to the above problem is one of our showstoppers. Would be happy to donate labor to help fix this. Thank you, Ed -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (TRINIDAD-875) Lightweight Dialogs broken in Opera and unreliable in Firefox
[ https://issues.apache.org/jira/browse/TRINIDAD-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598696#action_12598696 ] Joe Rossi commented on TRINIDAD-875: This appears to be down to the version of Firefox. I had a similar problem with Firefox 2.0.0.12 which subsequently disappeared with Firefox 2.0.0.14. Lightweight Dialogs broken in Opera and unreliable in Firefox - Key: TRINIDAD-875 URL: https://issues.apache.org/jira/browse/TRINIDAD-875 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.3-core Environment: JSF 1.2_04 Sun RI Tomcat 6.0.14 Reporter: Harald Stangl Priority: Critical When trying to open a lightweight dialog in Opera, the calling page reloads over and over again and the dialog doesn't show up. In Firefox, after closing a dialog, no new dialog can be opened for about 8 seconds. Clicking the link for the dialog simply does nothing. All this worked without problems in Trinidad 1.2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-875) Lightweight Dialogs broken in Opera and unreliable in Firefox
[ https://issues.apache.org/jira/browse/TRINIDAD-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598705#action_12598705 ] Scott O'Bryan commented on TRINIDAD-875: Can others watching this thread verify Joe's findings? If so, we may just need to update our Minimum Technical Requirements for which version of Firefox we support and close this issue. It has a lot of votes and watches which is why I'm not closing it right now.. Lightweight Dialogs broken in Opera and unreliable in Firefox - Key: TRINIDAD-875 URL: https://issues.apache.org/jira/browse/TRINIDAD-875 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.3-core Environment: JSF 1.2_04 Sun RI Tomcat 6.0.14 Firefox 2.0.0.12 Reporter: Harald Stangl Priority: Critical When trying to open a lightweight dialog in Opera, the calling page reloads over and over again and the dialog doesn't show up. In Firefox, after closing a dialog, no new dialog can be opened for about 8 seconds. Clicking the link for the dialog simply does nothing. All this worked without problems in Trinidad 1.2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
myfaces-commons-configurator ready for check in
Hey everyone, the long awaited myfaces-commons-configurator package is ready to be checked in. Because I'm seeing a lot of people doing things that might be aided by this framework, I was hoping I could check it into the commons project and get people to help me test it and fix it up. Do people think it would be of value checking this in before I've been able to put any real testing into it or would you rather me wait? *What is the Configurator System? *You've probably seen me talk about it in many threads before. It's a configurationless system for executing initialization, teardown, and request/response wrapping within a JSF environment without the use of filters. In addition to not requiring any configuration in the web.xml, because it does not require the use of filters, the system is compatible with both portlets and servlets. The primary example for this is for file uploads, but Trinidad uses it for many other things as well including skin handling and PPR. *What's not included? * Currently I do not have the multi-part form (file-upload) configurator complete although I intend on including that in the base package as an option that can be enabled. This will allow renderkits, like Trinidad and Tobago, to share handling of the multi-part form while still being able to use their own components. **No tests or testing No demos currently So are people willing to help with the development of this code or should I try to get it into a more final state? Scott
Re: [TRINIDAD] The email demo and panelPageSkinDemo.jspx fail in the 1.2.8 proposed release.
Looks like I messed up. I changed this as I wanted to remove the
deprecation warnings produced from using ValueBinding in JSF 1.2 based
code.
Sorry about this.
I have limited internet connectivity this week, so if someone can
cover this faster than me, please do so.
-Andrew
On Tue, May 20, 2008 at 4:51 PM, Jeanne Waldman
[EMAIL PROTECTED] wrote:
Yes, I'll log a JIRA right now. I wanted to look at it some more first, but
I'll just log a JIRA issue in case someone can get to it sooner.
- Jeanne
Scott O'Bryan wrote, On 5/20/2008 3:45 PM PT:
Me either. Are we going to get a JIRA on this?
Jeanne Waldman wrote:
I don't think this should hold up the release.
I see the code that is having an issue. It's only in the demo, and it
seems like EL code.
It's in PreferencesProxy.java. It errors trying to call
ve.getValue(context.getELContext()).
if (viewId.indexOf(/email/) = 0)
preferencesExpression = #{email.preferences};
else if (viewId.indexOf(SkinDemo) = 0)
preferencesExpression = #{sessionScope};
else if (viewId.indexOf(accessibilityProfileDemo) = 0)
preferencesExpression = #{accProfileDemo};
if (preferencesExpression != null)
{
ValueExpression ve =
context.getApplication().getExpressionFactory().createValueExpression(preferencesExpression,
Object.class);
return ve.getValue(context.getELContext());
}
In trinidad-config.xml, we have this:
skin-family#{prefs.proxy.skinFamily}/skin-family
If I change it to be
skin-family#{sessionScope.skinFamily}/skin-family
Then this bit of code doesn't get called, and it works fine (well, as
long as all the other 'prefs.proxy' EL expressions that are used in
trinidad-config.xml are fixed up the same way).
Oh, I just looked at the log of PreferencesProxy, and I see the code was
changed from JSF1.1 to JSF1.2, so that's the difference:
It was:
if (preferencesExpression != null)
{
ValueBinding vb =
context.getApplication().createValueBinding(preferencesExpression);
return vb.getValue(context);
}
and it is now:
if (preferencesExpression != null)
{
ValueExpression ve =
context.getApplication().getExpressionFactory().createValueExpression(preferencesExpression,
Object.class);
return ve.getValue(context.getELContext());
}
Anyone see anything obviously wrong? Maybe he is passing in the wrong
context.
- Jeanne
Paul Spencer wrote, On 5/20/2008 12:24 PM PT:
Is this an issue that should be addressed before releasing 1.2.8?
Paul Spencer
Jeanne Waldman wrote:
I was just about to send out an email about this as well.
I created a project from the example war file and I see the same error.
When I comment out the skin-family in faces-config.xml I get the same
error for the accessibilityMode. Both are EL bound to the same object:
accessibility-mode#{prefs.proxy.accessibilityMode}/accessibility-mode
accessibility-profile#{prefs.proxy.accessibilityProfile}/accessibility-profile
skin-family#{prefs.proxy.skinFamily}/skin-family
The errors go away when I comment these out.
This worked when I did the same thing with the 1.2.7 demo war.
Jeanne
Paul Spencer wrote, On 5/16/2008 1:56 PM PT:
Testing the 1.2.8 proposed release.
The email demo and panelPageSkinDemo.jspx fail when using jstl-1.2.jar
instead of jstl-1.1.2.jar in WEB-INF/lib in a tomcat 6.0.16 container
May 16, 2008 4:42:12 PM javax.faces.webapp._ErrorPageWriter
handleException
SEVERE: An exception occurred
javax.el.PropertyNotFoundException: Property 'skinFamily' not found
on type java.lang.String
at
javax.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:193)
at
javax.el.BeanELResolver$BeanProperties.access$400(BeanELResolver.java:170)
at javax.el.BeanELResolver.property(BeanELResolver.java:279)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:60)
at
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104)
at org.apache.el.parser.AstValue.getValue(AstValue.java:114)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.getSkinFamily(RequestContextImpl.java:230)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:510)
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
[jira] Resolved: (TRINIDAD-1074) Use shared string builder in org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey
[ https://issues.apache.org/jira/browse/TRINIDAD-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1074. -- Resolution: Fixed Fix Version/s: 1.2.9-core 1.0.9-core it will get into 1.0.9 and 1.2.9 when those are released. Use shared string builder in org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey - Key: TRINIDAD-1074 URL: https://issues.apache.org/jira/browse/TRINIDAD-1074 Project: MyFaces Trinidad Issue Type: Bug Reporter: Stevan Malesevic Fix For: 1.0.9-core, 1.2.9-core org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey should use shared StringBuilder to reduce memory (similar to org.apache.myfaces.trinidad.component.UIXComponentBase::getClientId) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of Trinidad 1.2.8
Is this a regression? If not, I do not think that the release should be held up for an existing problem and we should go ahead with the release and plan to put the fix in 1.x.9. On Tue, May 20, 2008 at 5:33 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: -1 Trinidad-73/Trinidad-978 is a showstopper issue for my application. Willing to contribute labor to get a fix for this problem into 1.0.8. Thank you, Ed On 5/20/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok Paul, TRINIDAD-1083 has been applied to both trunks, the 1.0.8 label and the 1.2.8 label. All of the artifacts have been regenerated. When you test it, give me your +1 and I think we're ready to release. Scott Scott O'Bryan wrote: Cool, thanks Matthias. I'm currently regenerating the artifacts for 1.2.8 and 1.0.8. They should be up in about an hour. Download from home is fast, but upload it REALLY SLOW.. Scott Matthias Wessendorf wrote: Hi, We need 3 +1 votes. 2.5 is not enough. Sounds like we need to wait for the 1.2.8 fix... Sent from my iPod. Am 20.05.2008 um 02:05 schrieb Scott O'Bryan [EMAIL PROTECTED]: Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +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, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [VOTE] Release of Trinidad 1.2.8
It's not a regression. Andrew Robinson wrote: Is this a regression? If not, I do not think that the release should be held up for an existing problem and we should go ahead with the release and plan to put the fix in 1.x.9. On Tue, May 20, 2008 at 5:33 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: -1 Trinidad-73/Trinidad-978 is a showstopper issue for my application. Willing to contribute labor to get a fix for this problem into 1.0.8. Thank you, Ed On 5/20/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok Paul, TRINIDAD-1083 has been applied to both trunks, the 1.0.8 label and the 1.2.8 label. All of the artifacts have been regenerated. When you test it, give me your +1 and I think we're ready to release. Scott Scott O'Bryan wrote: Cool, thanks Matthias. I'm currently regenerating the artifacts for 1.2.8 and 1.0.8. They should be up in about an hour. Download from home is fast, but upload it REALLY SLOW.. Scott Matthias Wessendorf wrote: Hi, We need 3 +1 votes. 2.5 is not enough. Sounds like we need to wait for the 1.2.8 fix... Sent from my iPod. Am 20.05.2008 um 02:05 schrieb Scott O'Bryan [EMAIL PROTECTED]: Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +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, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [VOTE] Release of Trinidad 1.2.8
It looks like the vote is going to pass. We've got our 3 +1 votes and 1 .5. I'll be sure to log the -1 vote and the reason. Ed, when you get this fixed, ping me. I'd be open to doing another early release to try to get this in before your deadline. Cool? Scott O'Bryan wrote: It's not a regression. Andrew Robinson wrote: Is this a regression? If not, I do not think that the release should be held up for an existing problem and we should go ahead with the release and plan to put the fix in 1.x.9. On Tue, May 20, 2008 at 5:33 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: -1 Trinidad-73/Trinidad-978 is a showstopper issue for my application. Willing to contribute labor to get a fix for this problem into 1.0.8. Thank you, Ed On 5/20/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok Paul, TRINIDAD-1083 has been applied to both trunks, the 1.0.8 label and the 1.2.8 label. All of the artifacts have been regenerated. When you test it, give me your +1 and I think we're ready to release. Scott Scott O'Bryan wrote: Cool, thanks Matthias. I'm currently regenerating the artifacts for 1.2.8 and 1.0.8. They should be up in about an hour. Download from home is fast, but upload it REALLY SLOW.. Scott Matthias Wessendorf wrote: Hi, We need 3 +1 votes. 2.5 is not enough. Sounds like we need to wait for the 1.2.8 fix... Sent from my iPod. Am 20.05.2008 um 02:05 schrieb Scott O'Bryan [EMAIL PROTECTED]: Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and
Re: [VOTE] Release of Trinidad 1.2.8
Cool. On Wed, May 21, 2008 at 3:55 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: It looks like the vote is going to pass. We've got our 3 +1 votes and 1 .5. I'll be sure to log the -1 vote and the reason. Ed, when you get this fixed, ping me. I'd be open to doing another early release to try to get this in before your deadline. Cool? Scott O'Bryan wrote: It's not a regression. Andrew Robinson wrote: Is this a regression? If not, I do not think that the release should be held up for an existing problem and we should go ahead with the release and plan to put the fix in 1.x.9. On Tue, May 20, 2008 at 5:33 PM, Edward Dowgiallo [EMAIL PROTECTED] wrote: -1 Trinidad-73/Trinidad-978 is a showstopper issue for my application. Willing to contribute labor to get a fix for this problem into 1.0.8. Thank you, Ed On 5/20/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok Paul, TRINIDAD-1083 has been applied to both trunks, the 1.0.8 label and the 1.2.8 label. All of the artifacts have been regenerated. When you test it, give me your +1 and I think we're ready to release. Scott Scott O'Bryan wrote: Cool, thanks Matthias. I'm currently regenerating the artifacts for 1.2.8 and 1.0.8. They should be up in about an hour. Download from home is fast, but upload it REALLY SLOW.. Scott Matthias Wessendorf wrote: Hi, We need 3 +1 votes. 2.5 is not enough. Sounds like we need to wait for the 1.2.8 fix... Sent from my iPod. Am 20.05.2008 um 02:05 schrieb Scott O'Bryan [EMAIL PROTECTED] : Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should
[RESULTS] Release of Trinidad 1.2.8
This vote passed with the following spread: +1 (x3): Paul Spencer, Scott O'Bryan, Matthias Wessendorf + .5 (x1): Andrew Robinson - 1 (x1): Edward Dowgiallo The negative one vote was for issues TRINIDAD-73 and TRINIDAD-978. We may be looking at another release soon to address these issues but the +1's didn't see the need to hold up the current release. Announcement will be sent out soon. Thanks, Scott
[jira] Updated: (TRINIDAD-1088) duplicate component id's possible with client side state saving
[ https://issues.apache.org/jira/browse/TRINIDAD-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated TRINIDAD-1088: --- Status: Patch Available (was: Open) duplicate component id's possible with client side state saving --- Key: TRINIDAD-1088 URL: https://issues.apache.org/jira/browse/TRINIDAD-1088 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.9-core, 1.2.9-core Reporter: Gerhard Petracek client side state saving: the state manager of trinidad doesn't check for duplicate component id's. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1088) duplicate component id's possible with client side state saving
duplicate component id's possible with client side state saving --- Key: TRINIDAD-1088 URL: https://issues.apache.org/jira/browse/TRINIDAD-1088 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.9-core, 1.2.9-core Reporter: Gerhard Petracek client side state saving: the state manager of trinidad doesn't check for duplicate component id's. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-875) Lightweight Dialogs broken in Opera and unreliable in Firefox
[ https://issues.apache.org/jira/browse/TRINIDAD-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598789#action_12598789 ] Mehmet Akif Olcay commented on TRINIDAD-875: Now it is ok with Mozilla/5.0 (X11; U; Linux i686; tr-TR; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-0etch1) apache-tomcat-6.0.16/ myfaces-1.2.2 It was problematic before. I think only change is that of firefox (i.e iceweal for debian) Lightweight Dialogs broken in Opera and unreliable in Firefox - Key: TRINIDAD-875 URL: https://issues.apache.org/jira/browse/TRINIDAD-875 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.3-core Environment: JSF 1.2_04 Sun RI Tomcat 6.0.14 Firefox 2.0.0.12 Reporter: Harald Stangl Priority: Critical When trying to open a lightweight dialog in Opera, the calling page reloads over and over again and the dialog doesn't show up. In Firefox, after closing a dialog, no new dialog can be opened for about 8 seconds. Clicking the link for the dialog simply does nothing. All this worked without problems in Trinidad 1.2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
shared source code within myfaces
hello, for the patches of TRINIDAD-1088 i used the source code of the myfaces state manager to detect duplicate component id's. i don't like to have duplicate source code! what's your opinion about moving all shared source code like this to a 'commons' module like the already existing myfaces-commons-utils? regards, gerhard
Re: shared source code within myfaces
-1 Myfaces commons utils is not the place for this. MyFaces core should not have to depend on the commons project to run. Plus the myfaces commons utils is a snapshot and not going to release any time soon. Making Trinidad dependent on this package would mean we can't release util the commons utils does. I don't like duping code either, but Trinidad added a bunch of duped code from MyFaces for it's configurators, so there is a prescidence. IMO, duplicating a small amount of code is preferable to adding at least 3 jar dependencies and making the core dependent on a util library. Scott On Wed, May 21, 2008 at 3:35 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, for the patches of TRINIDAD-1088 i used the source code of the myfaces state manager to detect duplicate component id's. i don't like to have duplicate source code! what's your opinion about moving all shared source code like this to a 'commons' module like the already existing myfaces-commons-utils? regards, gerhard
[jira] Commented: (TRINIDAD-875) Lightweight Dialogs broken in Opera and unreliable in Firefox
[ https://issues.apache.org/jira/browse/TRINIDAD-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598836#action_12598836 ] Scott O'Bryan commented on TRINIDAD-875: Ok, then let me see if we even have our Min. Requirements posted somewhere and I'll close this issue. Lightweight Dialogs broken in Opera and unreliable in Firefox - Key: TRINIDAD-875 URL: https://issues.apache.org/jira/browse/TRINIDAD-875 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.3-core Environment: JSF 1.2_04 Sun RI Tomcat 6.0.14 Firefox 2.0.0.12 Reporter: Harald Stangl Priority: Critical When trying to open a lightweight dialog in Opera, the calling page reloads over and over again and the dialog doesn't show up. In Firefox, after closing a dialog, no new dialog can be opened for about 8 seconds. Clicking the link for the dialog simply does nothing. All this worked without problems in Trinidad 1.2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: shared source code within myfaces
i see your point. there are some pros and cons! concerning the example you mentioned: only because we already have such a situation within the code base it isn't a legitimation to continue with this approach. (we need at least a discussion.) in the end we might have several parts which are acceptable to duplicate. - -1 for such an approach (if there are/will be too many duplicate parts). however, maybe there is a different approach! regards, gerhard 2008/5/22 Scott O'Bryan [EMAIL PROTECTED]: -1 Myfaces commons utils is not the place for this. MyFaces core should not have to depend on the commons project to run. Plus the myfaces commons utils is a snapshot and not going to release any time soon. Making Trinidad dependent on this package would mean we can't release util the commons utils does. I don't like duping code either, but Trinidad added a bunch of duped code from MyFaces for it's configurators, so there is a prescidence. IMO, duplicating a small amount of code is preferable to adding at least 3 jar dependencies and making the core dependent on a util library. Scott On Wed, May 21, 2008 at 3:35 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, for the patches of TRINIDAD-1088 i used the source code of the myfaces state manager to detect duplicate component id's. i don't like to have duplicate source code! what's your opinion about moving all shared source code like this to a 'commons' module like the already existing myfaces-commons-utils? regards, gerhard -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Andrew, Yeah, that's what I proposed. Paul wants us to distribute the non-j2ee version with our examples... Scott Andrew Robinson wrote: We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Scott and Andrew, The goal is to make it easy for a user to get the demo up and running with minimal frustration. Since I am not currently working in a J2EE environment, my desire to quickly get the demo running in order to test the 1.2.8 release did not include a J2EE server. I dropped the war in an available Tomcat server and then had to determine why the demo failed to run. After determining the I need a JSTL jar, I was able to test the release. I make the following suggested solutions, in order of preference: 1) distribute a non-J2EE Demo and Blank either in the existing Example distribution or in an non-J2EE distribution. 2) Add installation instruction that include instructions for J2EE and non-J2EE environments. The instructions, including any required jars, should be included in the .zip/.tar.gz file. 3) Add instructions on building a non-J2EE environment from the source. What ever solution is chosen, the instructions should also be on the Demo's web page[1]. Paul Spencer [1]http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html Scott O'Bryan wrote: Andrew, Yeah, that's what I proposed. Paul wants us to distribute the non-j2ee version with our examples... Scott Andrew Robinson wrote: We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Right. I'm for #3... And lets face it. The EASIEST way to run the demo is to download the tag and in the demo directory type mvn jetty:run.. Hey Paul, do you want to contribute the documentation via the website or wiki? Scott Paul Spencer wrote: Scott and Andrew, The goal is to make it easy for a user to get the demo up and running with minimal frustration. Since I am not currently working in a J2EE environment, my desire to quickly get the demo running in order to test the 1.2.8 release did not include a J2EE server. I dropped the war in an available Tomcat server and then had to determine why the demo failed to run. After determining the I need a JSTL jar, I was able to test the release. I make the following suggested solutions, in order of preference: 1) distribute a non-J2EE Demo and Blank either in the existing Example distribution or in an non-J2EE distribution. 2) Add installation instruction that include instructions for J2EE and non-J2EE environments. The instructions, including any required jars, should be included in the .zip/.tar.gz file. 3) Add instructions on building a non-J2EE environment from the source. What ever solution is chosen, the instructions should also be on the Demo's web page[1]. Paul Spencer [1]http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html Scott O'Bryan wrote: Andrew, Yeah, that's what I proposed. Paul wants us to distribute the non-j2ee version with our examples... Scott Andrew Robinson wrote: We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Hey Paul, can you do me a favor and JIRA up this improvement? It'll allow us to track the patches for this enhancement. For what it's worth, I *DO* think what you're trying to do has merit, I'm just not a big fan of making binary distributions for every possible container, especially when building the demo is so easy. In either case, we'll need some changes to the pom and if we do website documentation then it'll need some changes to be made to the site as well. Scott Scott O'Bryan wrote: Right. I'm for #3... And lets face it. The EASIEST way to run the demo is to download the tag and in the demo directory type mvn jetty:run.. Hey Paul, do you want to contribute the documentation via the website or wiki? Scott Paul Spencer wrote: Scott and Andrew, The goal is to make it easy for a user to get the demo up and running with minimal frustration. Since I am not currently working in a J2EE environment, my desire to quickly get the demo running in order to test the 1.2.8 release did not include a J2EE server. I dropped the war in an available Tomcat server and then had to determine why the demo failed to run. After determining the I need a JSTL jar, I was able to test the release. I make the following suggested solutions, in order of preference: 1) distribute a non-J2EE Demo and Blank either in the existing Example distribution or in an non-J2EE distribution. 2) Add installation instruction that include instructions for J2EE and non-J2EE environments. The instructions, including any required jars, should be included in the .zip/.tar.gz file. 3) Add instructions on building a non-J2EE environment from the source. What ever solution is chosen, the instructions should also be on the Demo's web page[1]. Paul Spencer [1]http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html Scott O'Bryan wrote: Andrew, Yeah, that's what I proposed. Paul wants us to distribute the non-j2ee version with our examples... Scott Andrew Robinson wrote: We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
[jira] Created: (TOMAHAWK-1258) not working attributes actionListener on the datatable ?? help me please
not working attributes actionListener on the datatable ?? help me please
Key: TOMAHAWK-1258
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1258
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.3
Environment: window xp , tomcat 5.0 , java 1.4 , eclipse tool
Reporter: HasunJoung
Priority: Critical
Fix For: 1.1.3
I usually use this tomahawk Extended Datatable , But I got a serious problem.
t:dataTable id=docuInfoList
value=#{fistDocuMgmtPageBean.docuInfoList}
var=docuInfo
t:column
f:facet name=header
t:outputText value=download/
/f:facet
t:commandLink id=download immediate=true
actionListener=#{docuMgmtPageBean.fileDownAction}
t:graphicImage url=images/add.gif /
/t:commandLink
/t:column
/t:dataTable
I tried commandButton.. but attribute actionListener did not function..
please help me..
public void fileDownAction (ActionEvent event) {
String filename = StatWR.xls;
String defaultPath = c:/work/;
//HttpServletRequest request =
(HttpServletRequest)getExternalContext().getRequest();
HttpServletResponse response =
(HttpServletResponse)getExternalContext().getResponse();
response.setContentType(application/vnd.ms-excel;
charset=UTF-8);
response.setHeader(Content-Disposition, attachment;
filename= + filename);
try {
response.setHeader(Content-Disposition,attachment;
filename=+URLEncoder.encode(filename, UTF-8));
} catch (UnsupportedEncodingException e1) {
e1.printStackTrace();
}
File file = new File(defaultPath + filename);
byte[] bytestream = new byte[(int)file.length()];
try{
FileInputStream filestream = new FileInputStream(file);
int i = 0, j = 0;
while((i = filestream.read()) != -1) {
bytestream[j] = (byte)i;
j++;
}
OutputStream outStream = response.getOutputStream();
outStream.write(bytestream);
outStream.close();
}catch(Exception e) {
e.printStackTrace();
}
}
I tried everything . And this Action function well not on the datatable..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-616) Datatable AutoSort and Facelets Bug
[ https://issues.apache.org/jira/browse/TOMAHAWK-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HasunJoung updated TOMAHAWK-616: Status: Patch Available (was: Open) Datatable AutoSort and Facelets Bug --- Key: TOMAHAWK-616 URL: https://issues.apache.org/jira/browse/TOMAHAWK-616 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.3 Environment: Windows XP Professional JBoss 4.03 SP1 Tomahawk 1.14 Snapshot and MyFaces 1.14 Snapshot Reporter: Tom Innes Attachments: DatatableTestFacelets.zip I am having problems with the auto sort feature after converting my application to facelets. The sorting only sorts one way ( ascending ) and the arrows are never displayed. I have tried 1.13 and 1.14 versions and there is no difference in the behaviour. I have converted the car example to highlight the problem it is attached. It is an eclipse project and the war is called DataTableTestFacelets. Just press the Find Button and then click on the links to sort the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
