CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
+1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
On Wed, Apr 15, 2009 at 11:29 AM, Simon Kitching skitch...@apache.org wrote: +1 for moving to the common server. Our build zone has been broken for ages, and as someone who tried hard to fix it, I can say it is a difficult problem! correct. also, since this is owned (speaking in more corp. words) by infra we get way better support, uptime, etc. As the infra team is known to deliver good work/support over the past years! Note that buildbot is a specific tool (http://buildbot.net/trac). I presume we would be moving to the ci.apache.org continuum instance? yes, in case we all agree. Cheers, Simon Manfred Geiler schrieb: +1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
+1 for moving to the common server. Our build zone has been broken for ages, and as someone who tried hard to fix it, I can say it is a difficult problem! Note that buildbot is a specific tool (http://buildbot.net/trac). I presume we would be moving to the ci.apache.org continuum instance? Cheers, Simon Manfred Geiler schrieb: +1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav...
[jira] Commented: (MYFACES-2186) After using jsp:include, component ids are appended with j_id_1
[
https://issues.apache.org/jira/browse/MYFACES-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699186#action_12699186
]
CCruz commented on MYFACES-2186:
In MyFaces 1.2.5 occur the same
After using jsp:include, component ids are appended with j_id_1
-
Key: MYFACES-2186
URL: https://issues.apache.org/jira/browse/MYFACES-2186
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.6
Environment: weblogic 10.3, myfaces 1.2.6
Reporter: Arpit Sakhi
Priority: Blocker
In migration from Myfaces 1.1.5 to Myfaces 1.2.6.
On one of my jsp i am using jsp:include and after running the application i
was getting component ids appended with pc then i have modified
UIComponentClassicTagBase.java class by commenting some code as shown below
-
private String createNextId(String componentId)
{
Integer currentCounter = (Integer)
getFacesContext().getExternalContext().getRequestMap().get(componentId);
int iCurrentCounter = 1;
if (currentCounter != null)
{
iCurrentCounter = currentCounter.intValue();
iCurrentCounter++;
}
getFacesContext().getExternalContext().getRequestMap().put(componentId, new
Integer(iCurrentCounter));
// if (isIncludedOrForwarded()) // Commented these lines
// {
// componentId = componentId + pc + iCurrentCounter;
// }
// else
// {
componentId = componentId + UNIQUE_ID_PREFIX + iCurrentCounter;
// }
return componentId;
}
But now ids are getting appended with j_id_1. Is there any fix available for
this issue because its kind of show stopper in my work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2186) After using jsp:include, component ids are appended with j_id_1
[
https://issues.apache.org/jira/browse/MYFACES-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699186#action_12699186
]
CCruz edited comment on MYFACES-2186 at 4/15/09 7:14 AM:
-
In MyFaces 1.2.5 occur the same; in MyFaces 1.2.4 same thing
was (Author: blacksuit):
In MyFaces 1.2.5 occur the same
After using jsp:include, component ids are appended with j_id_1
-
Key: MYFACES-2186
URL: https://issues.apache.org/jira/browse/MYFACES-2186
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.6
Environment: weblogic 10.3, myfaces 1.2.6
Reporter: Arpit Sakhi
Priority: Blocker
In migration from Myfaces 1.1.5 to Myfaces 1.2.6.
On one of my jsp i am using jsp:include and after running the application i
was getting component ids appended with pc then i have modified
UIComponentClassicTagBase.java class by commenting some code as shown below
-
private String createNextId(String componentId)
{
Integer currentCounter = (Integer)
getFacesContext().getExternalContext().getRequestMap().get(componentId);
int iCurrentCounter = 1;
if (currentCounter != null)
{
iCurrentCounter = currentCounter.intValue();
iCurrentCounter++;
}
getFacesContext().getExternalContext().getRequestMap().put(componentId, new
Integer(iCurrentCounter));
// if (isIncludedOrForwarded()) // Commented these lines
// {
// componentId = componentId + pc + iCurrentCounter;
// }
// else
// {
componentId = componentId + UNIQUE_ID_PREFIX + iCurrentCounter;
// }
return componentId;
}
But now ids are getting appended with j_id_1. Is there any fix available for
this issue because its kind of show stopper in my work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1834) suffix added to component id when including files
[ https://issues.apache.org/jira/browse/MYFACES-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699229#action_12699229 ] Matthias Weßendorf commented on MYFACES-1834: - looks like the entire issue is still present. See: http://markmail.org/message/rodox4e7ezdv4dtw the user is using MyFaces 1.2.6 suffix added to component id when including files - Key: MYFACES-1834 URL: https://issues.apache.org/jira/browse/MYFACES-1834 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.2 Reporter: Simon Kitching Priority: Minor In core 1.2 to 1.2.2, any use of jsp:include causes the ids of components in the included file to have a random string appended to them. This results in some ugly ids. However more significantly, the id of a component is not predictable even when an id attribute is explicitly assigned. In addition, this breaks the tomahawk forceId feature, because although the namespace prefix is omitted the rest of the id changes making forceId useless. The cause is class UIComponentClassicTagBase, where checkIfItIsInAnIterator() returns true if the current component is in an included or forwarded page. Later, the createUniqueId method adds a suffix to the user-specified if member isInAnIterator is true. Unfortunately, documentation on why things are implemented as they are is lacking. Checking for iteration is needed to support c:forEach .. h:inputText id=name/ /c:forEach Checking for includedOrForwarded might be to allow: jsp:include page=subPage.jsp / jsp:include page=subPage.jsp / However this is a very rare usage; support for this should not hurt everyone. And Sun Mojarra does *not* mess with the ids like this...testing shows that the ids of components are the same regardless of whether they are inline or in an included file. Maybe the isInIterator check could look to see whether the *same file* is being included twice, eg by keeping a list of the files included so far, and returning true only if the same string is encountered twice? That would allow multiple inclusions, but not mess with ids for a single inclusion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2201) Threading issues with EL-resolvers, Variable-resolvers and Property-resolvers
Threading issues with EL-resolvers, Variable-resolvers and Property-resolvers - Key: MYFACES-2201 URL: https://issues.apache.org/jira/browse/MYFACES-2201 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.6 Environment: Spring WebFlow 2.0.6, MyFaces 1.2.6, SUN Portlet Bridge, WebSphere Application Server 6.1.0.19 Reporter: Hampus Wingren Under heavy load, (generated by HP LoadRunner), a threading issue appears involving EL-resolvers. If one jar file has defined a faces-config.xml with several variable and property resolvers and another jar has defined it´s own el-resolver in its faces-config, the ELContext somehow looses the defined variable and property resolvers defined in the first jar. I can't really say more about it because I haven't taken a look at the MyFaces source code but I could resolve the issue by adding the other jars variable and property resolvers to the second jars el-resolver (CompositeELResolver). Regards, Hampus Wingren -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces 2.0 Ajax and a big thank you
+1, there has been a lot of activity around MyFaces 2.0 AJAX, which is great. Thanks Ganesh and Alex. I'm for sure gonna play with the new AJAX features soon. ;-) /JK
Jira account for developers
Hi, Last week I've committed the fix for a Jira issue, but I can't resolve the issue, because my Jira account seems to be separated from my Apache account. Am I missing the needed roles in Jira? I authenticate on Jira using my Apache username/email address. Someone knows the answer? It would definitely make work easier. ;-) Thanks, Jan-Kees
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
Hello, can we deploy artifacts to the snapshot repository and deploy the site from ci.apache.org? Regards 'Bernd On Wed, Apr 15, 2009 at 11:43 AM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Apr 15, 2009 at 11:29 AM, Simon Kitching skitch...@apache.org wrote: +1 for moving to the common server. Our build zone has been broken for ages, and as someone who tried hard to fix it, I can say it is a difficult problem! correct. also, since this is owned (speaking in more corp. words) by infra we get way better support, uptime, etc. As the infra team is known to deliver good work/support over the past years! Note that buildbot is a specific tool (http://buildbot.net/trac). I presume we would be moving to the ci.apache.org continuum instance? yes, in case we all agree. Cheers, Simon Manfred Geiler schrieb: +1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[Orchestra] ORCHESTRA-40
Hello, can somebody take a look at https://issues.apache.org/jira/browse/ORCHESTRA-40, please. I want to know that this issue goes in the right direction. Thanks Bernd
[jira] Created: (TRINIDAD-1452) add an agent for email
add an agent for email -- Key: TRINIDAD-1452 URL: https://issues.apache.org/jira/browse/TRINIDAD-1452 Project: MyFaces Trinidad Issue Type: Improvement Components: Archetype, Build Reporter: Jeanne Waldman Assignee: Jeanne Waldman Priority: Minor Currently we add EMAIL_CAPABILITIES to the agent. So the agent can be gecko or ie. But really we want Email to be its own agent that has its own capabilities. This way we can also add 'email' to skinning's @agent list because it is very likely that email agents' css does not work the same as browser agents. We can in the future create more specific email agents, like Outlook2007 and Thunderbird, if we want to. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1453) need a public API to get the CSS style properties on the server in our renderers.
need a public API to get the CSS style properties on the server in our renderers. -- Key: TRINIDAD-1453 URL: https://issues.apache.org/jira/browse/TRINIDAD-1453 Project: MyFaces Trinidad Issue Type: New Feature Reporter: Jeanne Waldman Assignee: Jeanne Waldman This information was discussed in email thread [TRINIDAD] [API] Styles.java and getSelectorStyleMap() *Overview* We need a public API to get the CSS style properties (e.g., color: red) on the server in our renderers. We work around the lack of apis by using skinning custom style properties instead (e.g., -tr-color: red) because skinning style properties are stored on the server as an attribute of a Skin Object. This is definitely a kludgy workaround and makes it harder for a user to skin. We will also need the APIs for an emailable page mode we are implementing soon so that we can limit the css that we write in the page to only the css needed by the components on the page. Email cannot handle external css files. In summary, the APIS we need will do this: 1) For a given selector, return its style definition 2) For a given simple (no compound selectors) selector like af|inputText, return all of the style definitions that it is used in like af|foo af|inputText, af|inputText::content, etc. *API Proposal* We will assume the style map we get from the RenderingContext will contain only the styles for the StyleContext, that is, the styles have already been 'resolved'. Therefore there will be no need to pass in the StyleContext parameter when we get styles from the style map. *Public APIs* *Style* This class exists, but will need to be made public and only the public parts of it moved to the public api, and the rest stay with the private implementation. public MapString, String getProperties(); public String toInlineString(); *Styles* A new class that wraps 2 methods. This class is similar to the current StyleMap private class which isn't a Map at all. I plan to delete StyleMap and use Styles instead. MapSelector, Style getSelectorStyleMap() ListString getSelectorsForSimpleSelector(String selector) uses resolved styles from StyleProvider. String getNativeSelectorString(Selector selector) converts the selector into a string that is valid for the browser. *Selector* A new class that encapsulates the selector string into a selector object to make the getSelectorStyleMap API clearer and to have a place to add features to the Selector if it is needed. static createSelector private constructor *RenderingContext* already exists add public Styles getStyles(); *Private APIs* *CoreRenderingContext* already exists Implements the new method on RenderingContext *StyleContext* This class already exists and is private. public Styles getStyles(); *StyleContextImpl* already exists add getStyles() calls getStyleProvider().getStyles(this); *StyleProvider* already exists add public Styles getStyles(StyleContext context); // resolves the styles first *FileSystemStyleCache* extends StyleProvider already exists add public Styles getStyles(StyleContext) static inner class StylesImpl which takes a resolved styles in its constructor. this is where the work is done to create the selectorStyleMap. *StyleMap* remove. It's not a map for one thing and it is such old code and it isn't being used at all so it is cluttering the api. *API Usage:* Styles styles = renderingContext.getStyles(); // renderingContext contains a styleContext MapSelector, Style selectorStyleMap = styles.getSelectorStyleMap(); Style style = selectorStyleMap.get(Selector.createSelector(af|graph)); String color = style.getProperties(color); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699345#action_12699345 ] Simon Kitching commented on ORCHESTRA-40: - Could you describe some of the use-cases for this? For transaction-oriented websites, back-buttons or double clicking of a page can be nasty; it can cause operations to be done multiple times (eg buying multiple copies of something) when the user didn't want that. The standard way to detect back-button usage or double clicks on a web page is to have a counter component in the page, and a matching counter in the http session. Both get incremented on each request; if at the start of a request they don't match then we have one of the above problems. If I understand correctly, this patch adds a conversation-aware version of this, which stores the counter in the current conversation for the submitting page. But I'm not sure why this is useful. Why isn't a normal non-conversation-aware token implementation sufficient? Note that the Orchestra ViewController already has features to detect when a page tries to use a conversation that does not exist (eg because it has been invalidated at end of a transaction), and can redirect to the appropriate entry page for the conversation. A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1454) Facelets: setting locale attribute fails on tr:convertNumber
Facelets: setting locale attribute fails on tr:convertNumber Key: TRINIDAD-1454 URL: https://issues.apache.org/jira/browse/TRINIDAD-1454 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 1.2.11-core Reporter: Max Starets If you set locale=fr on a tr:convertNumber while running with Facelets, you will get the following exception: java.lang.IllegalArgumentException: Cannot convert fr of type class java.lang.String to class java.util.Locale Resolution: we need to provide a metarule for converting strings to java.util.Locale -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1454) Facelets: setting locale attribute fails on tr:convertNumber
[ https://issues.apache.org/jira/browse/TRINIDAD-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1454: -- Status: Patch Available (was: Open) Facelets: setting locale attribute fails on tr:convertNumber Key: TRINIDAD-1454 URL: https://issues.apache.org/jira/browse/TRINIDAD-1454 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 1.2.11-core Reporter: Max Starets Attachments: LocalePropertyTagRule.java, metarule.diff If you set locale=fr on a tr:convertNumber while running with Facelets, you will get the following exception: java.lang.IllegalArgumentException: Cannot convert fr of type class java.lang.String to class java.util.Locale Resolution: we need to provide a metarule for converting strings to java.util.Locale -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
On Wed, Apr 15, 2009 at 8:38 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, can we deploy artifacts to the snapshot repository and deploy the site from ci.apache.org? I guess yes. Let me bring it up on their new mailing list -M Regards 'Bernd On Wed, Apr 15, 2009 at 11:43 AM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Apr 15, 2009 at 11:29 AM, Simon Kitching skitch...@apache.org wrote: +1 for moving to the common server. Our build zone has been broken for ages, and as someone who tried hard to fix it, I can say it is a difficult problem! correct. also, since this is owned (speaking in more corp. words) by infra we get way better support, uptime, etc. As the infra team is known to deliver good work/support over the past years! Note that buildbot is a specific tool (http://buildbot.net/trac). I presume we would be moving to the ci.apache.org continuum instance? yes, in case we all agree. Cheers, Simon Manfred Geiler schrieb: +1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1455) NumberConverter caches only the first encountered converter for a given type. Converters for other locales are recreated every time
[
https://issues.apache.org/jira/browse/TRINIDAD-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-1455:
--
Status: Patch Available (was: Open)
NumberConverter caches only the first encountered converter for a given type.
Converters for other locales are recreated every time
---
Key: TRINIDAD-1455
URL: https://issues.apache.org/jira/browse/TRINIDAD-1455
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.11-core
Reporter: Max Starets
Attachments: converter.patch
_cacheNumberFormat() has the following code that is wrong:
// The key could have either been the type based on which formats are
// stored or it can be based on the pattern also.
String key = ((pattern != null) ? pattern : type);
MapLocale, NumberFormat nfMap = _numberFormatHolder.get(key);
// if we have not cached any NumberFormat for this type, then create a
// map for that type and add to it based on the locale
if (nfMap == null)
{
nfMap = new HashMapLocale, NumberFormat();
nfMap.put(locale, (NumberFormat)format.clone());
}
// add this based on the type ('number','currency','percent') or
// pattern1, pattern2.. patternN to the main holder
_numberFormatHolder.put(key, nfMap);
Note that the placement for the two put() calls should be swapped. New map
entry for a Locale should be added every time, while nfMap for
a given key should be added to _numberFormatHolder only when nfMap gets
created.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1455) NumberConverter caches only the first encountered converter for a given type. Converters for other locales are recreated every time
NumberConverter caches only the first encountered converter for a given type.
Converters for other locales are recreated every time
---
Key: TRINIDAD-1455
URL: https://issues.apache.org/jira/browse/TRINIDAD-1455
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.11-core
Reporter: Max Starets
Attachments: converter.patch
_cacheNumberFormat() has the following code that is wrong:
// The key could have either been the type based on which formats are
// stored or it can be based on the pattern also.
String key = ((pattern != null) ? pattern : type);
MapLocale, NumberFormat nfMap = _numberFormatHolder.get(key);
// if we have not cached any NumberFormat for this type, then create a
// map for that type and add to it based on the locale
if (nfMap == null)
{
nfMap = new HashMapLocale, NumberFormat();
nfMap.put(locale, (NumberFormat)format.clone());
}
// add this based on the type ('number','currency','percent') or
// pattern1, pattern2.. patternN to the main holder
_numberFormatHolder.put(key, nfMap);
Note that the placement for the two put() calls should be swapped. New map
entry for a Locale should be added every time, while nfMap for
a given key should be added to _numberFormatHolder only when nfMap gets created.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1453) need a public API to get the CSS style properties on the server in our renderers.
[ https://issues.apache.org/jira/browse/TRINIDAD-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699377#action_12699377 ] Matthias Weßendorf commented on TRINIDAD-1453: -- the thread is archived here: http://www.mail-archive.com/dev@myfaces.apache.org/msg37896.html need a public API to get the CSS style properties on the server in our renderers. -- Key: TRINIDAD-1453 URL: https://issues.apache.org/jira/browse/TRINIDAD-1453 Project: MyFaces Trinidad Issue Type: New Feature Reporter: Jeanne Waldman Assignee: Jeanne Waldman This information was discussed in email thread [TRINIDAD] [API] Styles.java and getSelectorStyleMap() *Overview* We need a public API to get the CSS style properties (e.g., color: red) on the server in our renderers. We work around the lack of apis by using skinning custom style properties instead (e.g., -tr-color: red) because skinning style properties are stored on the server as an attribute of a Skin Object. This is definitely a kludgy workaround and makes it harder for a user to skin. We will also need the APIs for an emailable page mode we are implementing soon so that we can limit the css that we write in the page to only the css needed by the components on the page. Email cannot handle external css files. In summary, the APIS we need will do this: 1) For a given selector, return its style definition 2) For a given simple (no compound selectors) selector like af|inputText, return all of the style definitions that it is used in like af|foo af|inputText, af|inputText::content, etc. *API Proposal* We will assume the style map we get from the RenderingContext will contain only the styles for the StyleContext, that is, the styles have already been 'resolved'. Therefore there will be no need to pass in the StyleContext parameter when we get styles from the style map. *Public APIs* *Style* This class exists, but will need to be made public and only the public parts of it moved to the public api, and the rest stay with the private implementation. public MapString, String getProperties(); public String toInlineString(); *Styles* A new class that wraps 2 methods. This class is similar to the current StyleMap private class which isn't a Map at all. I plan to delete StyleMap and use Styles instead. MapSelector, Style getSelectorStyleMap() ListString getSelectorsForSimpleSelector(String selector) uses resolved styles from StyleProvider. String getNativeSelectorString(Selector selector) converts the selector into a string that is valid for the browser. *Selector* A new class that encapsulates the selector string into a selector object to make the getSelectorStyleMap API clearer and to have a place to add features to the Selector if it is needed. static createSelector private constructor *RenderingContext* already exists add public Styles getStyles(); *Private APIs* *CoreRenderingContext* already exists Implements the new method on RenderingContext *StyleContext* This class already exists and is private. public Styles getStyles(); *StyleContextImpl* already exists add getStyles() calls getStyleProvider().getStyles(this); *StyleProvider* already exists add public Styles getStyles(StyleContext context); // resolves the styles first *FileSystemStyleCache* extends StyleProvider already exists add public Styles getStyles(StyleContext) static inner class StylesImpl which takes a resolved styles in its constructor. this is where the work is done to create the selectorStyleMap. *StyleMap* remove. It's not a map for one thing and it is such old code and it isn't being used at all so it is cluttering the api. *API Usage:* Styles styles = renderingContext.getStyles(); // renderingContext contains a styleContext MapSelector, Style selectorStyleMap = styles.getSelectorStyleMap(); Style style = selectorStyleMap.get(Selector.createSelector(af|graph)); String color = style.getProperties(color); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release of Extensions Validator 1.1.2
Hi, I was running the needed tasks to get the 1.1.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[VOTE] Release of Extensions Validator 1.2.2
Hi, I was running the needed tasks to get the 1.2.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_2_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Extensions Validator 1.1.2
+1 2009/4/16 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 1.1.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_2/http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_1_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Release of Extensions Validator 1.2.2
+1 2009/4/16 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 1.2.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_2_2/http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_2_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-2202) myfaces builder plugin does not recognize properties returning arrays
myfaces builder plugin does not recognize properties returning arrays - Key: MYFACES-2202 URL: https://issues.apache.org/jira/browse/MYFACES-2202 Project: MyFaces Core Issue Type: Bug Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe This example: @JSFProperty public abstract String[] getPartialTargets(); The expected class name to be added on myfaces-metadata.xml is java.lang.String[] and not java.lang.String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[OT] ADF/JSF Developers Wanted
MyFacers, Looking for some capable JSF developers in the New York City area. Experience with JDeveloper / ADF / Weblogic is preferred but not compulsory. Candidates WILL be evaluated thoroughly for technical competence. I usually don't post here, but this is a good gig with real-world benefits for the user-base you are developing solutions for. Compensation is competitive; two positions are open for immediate placement. Cheers, Zubin.
[jira] Created: (TRINIDAD-1456) Some keys in resource files have no translation
Some keys in resource files have no translation --- Key: TRINIDAD-1456 URL: https://issues.apache.org/jira/browse/TRINIDAD-1456 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Huayu Wu In following 2 resource files: trinidad-api\src\main\xrts\org\apache\myfaces\trinidad\resource\LoggerBundle.xrts trinidad-api\src\main\xrts\org\apache\myfaces\trinidad\resource\MessageBundle.xrts Some keys only exist in base resource files, e.g: In LoggerBundle.xrts: UNSERIALIZABLE_PROPERTY_VALUE COMPONENT_TREE_SERIALIZATION_FAILED In MessageBundle.xrts: org.apache.myfaces.trinidad.event.FileDownloadActionListener.DOWNLOAD_ERROR_detail org.apache.myfaces.trinidad.component.core.input.CoreInputFile.INPUT_FILE_ERROR These keys need to be translated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
