date:20110114

[jira] Commented: (TRINIDAD-1985) High live memory usage from SkinStyleProvider

2011-01-14 Thread Jeanne Waldman (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981976#action_12981976
 ] 

Jeanne Waldman commented on TRINIDAD-1985:
--

The soft references and LRU caching would help clean up rarely used css files 
but if the users are actually using all of these pretty consistently, the soft 
references aren't going to help much and could actually make things worse by 
thrashing as the skin information gets purged and recreated constantly if the 
application is under memory pressure. 
Look into re-using the CSSStyle objects more efficiently as a workaround.

> High live memory usage from SkinStyleProvider
> -
>
> Key: TRINIDAD-1985
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Archetype
>Affects Versions:  1.2.12-core
>Reporter: Stevan Malesevic
>
> We were checking a live memory usage in one app and noticed that some 83MB of 
> heap is pinned under SkinStyleProvider. This is under 14 instances of 
> FileSystemStyleCache$Entry each with about 6MB of memory
> Heap shows these keys for styles
> LocaleVersion
> enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
> koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
> Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) 
> Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
> koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
> (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
> (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
> koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
> Gecko/20090824 Firefox/3.5.3
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 
> Gecko/20090824 Firefox/3.5.3
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
> Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
> koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) 
> Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
> Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
> koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 
> Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
> enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET 
> CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) 
> Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) 
> Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) 
> Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
> koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
> .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
> enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; 
> .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 
> Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
> Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
> koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) 
> Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
> enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) 
> Gecko/20101203 Firefox/3.6.13
> Now beside the amount of memory pinned by single FileSystemStyleCache$Entry 
> the issue is that we apparently create too many different versions and there 
> is no restriction to the size of cache leaving open door for memory leak
> Two questions
> 1. Do we really have different styles for FF on 3.5 or 3.6 or so?  If not why 
> do we key by it?
> 2. Given different browsers and locales having cache as plain concurrent hash 
> map is actually a source of leak as over time it can accumulate more and 
> more. Do we have any restriction there? Should  the entries by LRU or have 
> exparation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (EXTCDI-122) revisit jndi names

2011-01-14 Thread Gerhard Petracek (JIRA)

revisit jndi names
--

 Key: EXTCDI-122
 URL: https://issues.apache.org/jira/browse/EXTCDI-122
 Project: MyFaces CODI
  Issue Type: Task
  Components: Core
Reporter: Gerhard Petracek




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (EXTCDI-121) CodiUtils#lookupFromEnvironment should also use the ServiceLoader

2011-01-14 Thread Gerhard Petracek (JIRA)

CodiUtils#lookupFromEnvironment should also use the ServiceLoader
-

 Key: EXTCDI-121
 URL: https://issues.apache.org/jira/browse/EXTCDI-121
 Project: MyFaces CODI
  Issue Type: New Feature
  Components: Core
Reporter: Gerhard Petracek




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (EXTCDI-120) StartupEventBroadcaster

2011-01-14 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981950#action_12981950
 ] 

Gerhard Petracek commented on EXTCDI-120:
-

it's a hook for codi btw. support-modules or add-ons e.g. for integrating 
existing frameworks like mojarra and gets triggered >before< bootstrapping 
codi. (that's the only contract.)
what you are referring to is a different story. for jsf based apps codi 
provides such an event (see StartupEvent)
however, it would be nice to get an event which gets fired after the 
bootstrapping process of cdi.

> StartupEventBroadcaster
> ---
>
> Key: EXTCDI-120
> URL: https://issues.apache.org/jira/browse/EXTCDI-120
> Project: MyFaces CODI
>  Issue Type: New Feature
>  Components: Core
>Reporter: Gerhard Petracek
> Fix For: 0.9.3
>
>
> before codi configures anything it should be possible to process 
> initialization tasks.
> public interface StartupEventBroadcaster
> {
> void broadcastStartup();
> }
> example for an use-case:
> it can be used for an improved app-server support in combination with mojarra
> the basic problem is the early config approach of mojarra.
> if mojarra gets invoked before the bootstrapping process of a cdi container, 
> it starts to configure everything immediately and codi gets invoked (outside 
> a cdi context).
> in such a case it's possible to use a custom ServletContextListener for 
> bootsrapping the container.
> in case of owb it's possible to extend WebBeansConfigurationListener
> example:
> public class MojarraAwareWebBeansConfigurationListener extends 
> WebBeansConfigurationListener implements StartupEventBroadcaster
> {
> private static Boolean initialized = false;
> private static ContainerLifecycle storedContainerLifecycle;
> public void contextInitialized(ServletContextEvent event)
> {
> if (!initialized)
> {
> //in this case CDI is bootstrapped already
> super.contextInitialized(event);
> initialized = true;
> storedContainerLifecycle = this.lifeCycle;
> }
> }
> public void broadcastStartup()
> {
> if (initialized)
> {
> return;
> }
> //in this case Mojarra was invoked too soon
> FacesContext facesContext = FacesContext.getCurrentInstance();
> if (facesContext != null && facesContext.getExternalContext() != null)
> {
> //force bootstrapping of OWB
> contextInitialized(new ServletContextEvent((ServletContext) 
> facesContext.getExternalContext().getContext()));
> initialized = true;
> }
> }
> public void requestInitialized(ServletRequestEvent event)
> {
> if (this.lifeCycle == null)
> {
> //here we have a different instance
> this.lifeCycle = storedContainerLifecycle;
> }
> super.requestInitialized(event);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-3009) Flash scope looses values on redirect

2011-01-14 Thread Jakob Korherr (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981939#action_12981939
 ] 

Jakob Korherr commented on MYFACES-3009:


No objections on my side!

It seems like a hack at first sight, but I agree that this is better than 
having to rely on FlashImpl internals!

> Flash scope looses values on redirect
> -
>
> Key: MYFACES-3009
> URL: https://issues.apache.org/jira/browse/MYFACES-3009
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-314
>Affects Versions: 2.0.3
>Reporter: Jakob Korherr
>Assignee: Jakob Korherr
> Attachments: MYFACES-3009-1.patch
>
>
> Example as follows:
> 1) A facelet called Entry.xhtml
> 
> 
>  
>First Name:
>
>  
>
>  
>  
>Last Name:
>
>  
>
>  
>/>
>  
> and the confirmation.xhtml:
> 
>  
>First Name:
>
>  
>
>  
>  
>Last Name:
>
>  
>
>   
> 
> 
>  />
> 
> But when the confirmation page is loaded, the firstName and lastName I 
> submitted
> is missing. Why? I am using flash.keep. According to what I read it should
> keep the values more than a PRG cycle.
> It works if I use Mojarra.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1960) NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant

2011-01-14 Thread Max Starets (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981931#action_12981931
 ] 

Max Starets commented on TRINIDAD-1960:
---

The fix for TRINIDAD-2008 on the trunk would probably work here as well

> NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant
> -
>
> Key: TRINIDAD-1960
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1960
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 1.2.14-core 
> Environment: Mac OS X 10.6, Java 6, Glassfish 3.0.2
>Reporter: Manuel Blechschmidt
> Attachments: PreventNullPointerInLocaleInfoScroptlet.patch
>
>
> Hi,
> I tried to deploy trinidad in a web app to my Glassfish Server. After 
> reporting and fixing TRINIDAD-1959 I get the following problem:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:598)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1050)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:169)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.intercept(ExtValGenericRenderKit.java:84)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.addRenderer()
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase._loadRenderKitMap(RenderKitBase.java:258)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.(RenderKitBase.java:56)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.(RenderKitDecorator.java:39)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.(CoreRenderKit.java:168)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.()
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216)
>   at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:640)
>   at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538)
>   at 
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225)
>   at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
>   at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.newInstance(ExtValGenericRenderKit.java:62)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.GenericRenderKitWrapperFactory.createWrapper(GenericRenderKitWrapperFactory.java:45)
>   at 
> org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory.createWrapper(DefaultRenderKitWrapperFactory.java:54)
>   at 
> org.apache.myfaces.extensions.validator.core.renderkit.ExtValRenderKitFactory.getRenderKit(ExtValRenderKitFactory.java:84)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitFactory.getRenderKit(CoreRenderKitFactory.java:55)
>   at 
> com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:170)
>   at 
> com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
>   at 
> com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270)
>   at 
> com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
>   at 
> com.sun.faces.config.processo

[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution

2011-01-14 Thread Max Starets (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Starets updated TRINIDAD-2008:
--

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-1
   Status: Resolved  (was: Patch Available)

> tr:panelBorderLayout is throwing exception with Mojarra during tag execution
> 
>
> Key: TRINIDAD-2008
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2008
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 2.0.0-alpha-2
> Environment: Mojarra 2.0.4, WLS
>Reporter: Max Starets
>Assignee: Max Starets
> Fix For: 2.0.0-beta-1
>
> Attachments: TRINIDAD-2002.patch
>
>
> To reproduce the issue, try running the following test.xhtml page:
> http://www.w3.org/1999/xhtml";
>   xmlns:h="http://java.sun.com/jsf/html";
>   xmlns:f="http://java.sun.com/jsf/core";
>   xmlns:tr="http://myfaces.apache.org/trinidad";>
>   
>  
> 
> 
> 
> 
> 
> You will notice java.lang.ExceptionInInitializerError
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
> The root cause is the following exception:
> java.lang.NullPointerException
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:825)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at java.lang.Class.newInstance0(Class.java:355)
>   at java.lang.Class.newInstance(Class.java:308)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129)
>   at 
> com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163)
>   at 
> c

[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution

2011-01-14 Thread Max Starets (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Starets updated TRINIDAD-2008:
--

Status: Patch Available  (was: Reopened)

> tr:panelBorderLayout is throwing exception with Mojarra during tag execution
> 
>
> Key: TRINIDAD-2008
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2008
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 2.0.0-alpha-2
> Environment: Mojarra 2.0.4, WLS
>Reporter: Max Starets
>Assignee: Max Starets
> Attachments: TRINIDAD-2002.patch
>
>
> To reproduce the issue, try running the following test.xhtml page:
> http://www.w3.org/1999/xhtml";
>   xmlns:h="http://java.sun.com/jsf/html";
>   xmlns:f="http://java.sun.com/jsf/core";
>   xmlns:tr="http://myfaces.apache.org/trinidad";>
>   
>  
> 
> 
> 
> 
> 
> You will notice java.lang.ExceptionInInitializerError
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
> The root cause is the following exception:
> java.lang.NullPointerException
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:825)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at java.lang.Class.newInstance0(Class.java:355)
>   at java.lang.Class.newInstance(Class.java:308)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129)
>   at 
> com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89)
>   at 
> com.sun.

[jira] Commented: (EXTCDI-120) StartupEventBroadcaster

2011-01-14 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981922#action_12981922
 ] 

Mark Struberg commented on EXTCDI-120:
--

might it be interesting to propose the introduction of a new ContainerStarted 
system Event (JSR-299 spec section 11).
Will ask for clarification about it on the weld-dev list.

> StartupEventBroadcaster
> ---
>
> Key: EXTCDI-120
> URL: https://issues.apache.org/jira/browse/EXTCDI-120
> Project: MyFaces CODI
>  Issue Type: New Feature
>  Components: Core
>Reporter: Gerhard Petracek
> Fix For: 0.9.3
>
>
> before codi configures anything it should be possible to process 
> initialization tasks.
> public interface StartupEventBroadcaster
> {
> void broadcastStartup();
> }
> example for an use-case:
> it can be used for an improved app-server support in combination with mojarra
> the basic problem is the early config approach of mojarra.
> if mojarra gets invoked before the bootstrapping process of a cdi container, 
> it starts to configure everything immediately and codi gets invoked (outside 
> a cdi context).
> in such a case it's possible to use a custom ServletContextListener for 
> bootsrapping the container.
> in case of owb it's possible to extend WebBeansConfigurationListener
> example:
> public class MojarraAwareWebBeansConfigurationListener extends 
> WebBeansConfigurationListener implements StartupEventBroadcaster
> {
> private static Boolean initialized = false;
> private static ContainerLifecycle storedContainerLifecycle;
> public void contextInitialized(ServletContextEvent event)
> {
> if (!initialized)
> {
> //in this case CDI is bootstrapped already
> super.contextInitialized(event);
> initialized = true;
> storedContainerLifecycle = this.lifeCycle;
> }
> }
> public void broadcastStartup()
> {
> if (initialized)
> {
> return;
> }
> //in this case Mojarra was invoked too soon
> FacesContext facesContext = FacesContext.getCurrentInstance();
> if (facesContext != null && facesContext.getExternalContext() != null)
> {
> //force bootstrapping of OWB
> contextInitialized(new ServletContextEvent((ServletContext) 
> facesContext.getExternalContext().getContext()));
> initialized = true;
> }
> }
> public void requestInitialized(ServletRequestEvent event)
> {
> if (this.lifeCycle == null)
> {
> //here we have a different instance
> this.lifeCycle = storedContainerLifecycle;
> }
> super.requestInitialized(event);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (EXTCDI-120) StartupEventBroadcaster

2011-01-14 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-120.
-

   Resolution: Fixed
Fix Version/s: 0.9.3

> StartupEventBroadcaster
> ---
>
> Key: EXTCDI-120
> URL: https://issues.apache.org/jira/browse/EXTCDI-120
> Project: MyFaces CODI
>  Issue Type: New Feature
>  Components: Core
>Reporter: Gerhard Petracek
> Fix For: 0.9.3
>
>
> before codi configures anything it should be possible to process 
> initialization tasks.
> public interface StartupEventBroadcaster
> {
> void broadcastStartup();
> }
> example for an use-case:
> it can be used for an improved app-server support in combination with mojarra
> the basic problem is the early config approach of mojarra.
> if mojarra gets invoked before the bootstrapping process of a cdi container, 
> it starts to configure everything immediately and codi gets invoked (outside 
> a cdi context).
> in such a case it's possible to use a custom ServletContextListener for 
> bootsrapping the container.
> in case of owb it's possible to extend WebBeansConfigurationListener
> example:
> public class MojarraAwareWebBeansConfigurationListener extends 
> WebBeansConfigurationListener implements StartupEventBroadcaster
> {
> private static Boolean initialized = false;
> private static ContainerLifecycle storedContainerLifecycle;
> public void contextInitialized(ServletContextEvent event)
> {
> if (!initialized)
> {
> //in this case CDI is bootstrapped already
> super.contextInitialized(event);
> initialized = true;
> storedContainerLifecycle = this.lifeCycle;
> }
> }
> public void broadcastStartup()
> {
> if (initialized)
> {
> return;
> }
> //in this case Mojarra was invoked too soon
> FacesContext facesContext = FacesContext.getCurrentInstance();
> if (facesContext != null && facesContext.getExternalContext() != null)
> {
> //force bootstrapping of OWB
> contextInitialized(new ServletContextEvent((ServletContext) 
> facesContext.getExternalContext().getContext()));
> initialized = true;
> }
> }
> public void requestInitialized(ServletRequestEvent event)
> {
> if (this.lifeCycle == null)
> {
> //here we have a different instance
> this.lifeCycle = storedContainerLifecycle;
> }
> super.requestInitialized(event);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (EXTCDI-120) StartupEventBroadcaster

2011-01-14 Thread Gerhard Petracek (JIRA)

StartupEventBroadcaster
---

 Key: EXTCDI-120
 URL: https://issues.apache.org/jira/browse/EXTCDI-120
 Project: MyFaces CODI
  Issue Type: New Feature
  Components: Core
Reporter: Gerhard Petracek


before codi configures anything it should be possible to process initialization 
tasks.

public interface StartupEventBroadcaster
{
void broadcastStartup();
}

example for an use-case:

it can be used for an improved app-server support in combination with mojarra
the basic problem is the early config approach of mojarra.
if mojarra gets invoked before the bootstrapping process of a cdi container, it 
starts to configure everything immediately and codi gets invoked (outside a cdi 
context).

in such a case it's possible to use a custom ServletContextListener for 
bootsrapping the container.
in case of owb it's possible to extend WebBeansConfigurationListener

example:

public class MojarraAwareWebBeansConfigurationListener extends 
WebBeansConfigurationListener implements StartupEventBroadcaster
{
private static Boolean initialized = false;

private static ContainerLifecycle storedContainerLifecycle;

public void contextInitialized(ServletContextEvent event)
{
if (!initialized)
{
//in this case CDI is bootstrapped already
super.contextInitialized(event);
initialized = true;
storedContainerLifecycle = this.lifeCycle;
}
}

public void broadcastStartup()
{
if (initialized)
{
return;
}

//in this case Mojarra was invoked too soon

FacesContext facesContext = FacesContext.getCurrentInstance();

if (facesContext != null && facesContext.getExternalContext() != null)
{
//force bootstrapping of OWB
contextInitialized(new ServletContextEvent((ServletContext) 
facesContext.getExternalContext().getContext()));
initialized = true;
}
}

public void requestInitialized(ServletRequestEvent event)
{
if (this.lifeCycle == null)
{
//here we have a different instance
this.lifeCycle = storedContainerLifecycle;
}
super.requestInitialized(event);
}
}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[core] ajax @this with non trivial component

2011-01-14 Thread Martin Koci

Hi,

if component is represented on client like:



   a Label 

  


what will be in HTTP reuqest? execute = "clientId_input" - but this is
only internal part of the component, not id of component on the server
so no component is executed.

What I need is :


  
 


ajax behaviour renderer renders '@this' as pass thru value. What I
really need is:

if ("@this".equals(executeItem)) {
executeItem = clientBehaviorContext.getComponent().getCliendId()
}

Similar for render attribute. 


Spec. says: "@this = The element that triggered the request". Thats very
unclear: specification uses 'element' word in two contexts: DOM element
and XHTML element.


Mojarra 2.0.3 renders '@this' as pass through too.


WDYT ?


Kočičák

Re: [VOTE] Release of Extensions CDI (CODI) 0.9.2

2011-01-14 Thread Hazem Saleh

+1

On Thu, Jan 13, 2011 at 6:39 PM, Grant Smith  wrote:

>
> +1
>
> On Thu, Jan 13, 2011 at 12:16 AM, Rudy De Busscher 
> wrote:
>
>> +1
>>
>> Regards
>> Rudy
>>
>> On 12 January 2011 23:03, Leonardo Uribe  wrote:
>>
>>> +1
>>>
>>> Leonardo
>>>
>>>
>>
>
>
> --
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
>
>


-- 
Hazem Ahmed Saleh Ahmed

Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY

Visualize and share your social networks 2D and 3D:
http://www.mapmysocial.com

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread mamallan . uthaman


+1
-- Mamallan

On 1/14/2011 4:10 AM, Matthias Wessendorf wrote:

+1

On Fri, Jan 14, 2011 at 1:10 PM, Matthias Wessendorf  wrote:
  

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [RE-VOTE] Release MyFaces Portlet Bridge 2.0.0 TCK

2011-01-14 Thread Leonardo Uribe

+1

2011/1/14 Grant Smith 

> +1
>
>
> On Fri, Jan 14, 2011 at 2:24 AM, Werner Punz wrote:
>
>> +1
>> Am 13.01.11 19:21, schrieb Michael Freedman:
>>
>>> Appropriate NOTICE/LICENSE files have now been added to the TCK project
>>> and a distributable has been built and is hosted on:
>>> http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/
>>> >> >.
>>>
>>>
>>> The zip has been verified to ensure its download allows one to build/run
>>> the TCK via maven. I also verified that the NOTICE/LICENSE exists and
>>> are included in the various .wars that get built as part of
>>> building/running the TCK.
>>>
>>> Please revote on this new distributable:
>>> 
>>> [ ] +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.
>>>
>>> On 1/12/2011 2:00 PM, Leonardo Uribe wrote:
>>>
 Hi

 Checking the distributables, I have seen that there is no LICENSE /
 NOTICE on the parent folder or in META-INF folder. Is that correct?

 In comparison, the files for portlet bridge 2.0
 (portlet-bridge-2.0.0-src-all.zip) does have it.

 regards,

 Leonardo Uribe

 2011/1/12 Matthias Wessendorf >>> >


was there any reason why you didn't use Nexus for the release
procedure?
MyFaces (sub)projects agreed to use this..

On Tue, Jan 11, 2011 at 10:45 PM, Michael Freedman
mailto:michael.freed...@oracle.com>>

wrote:
> Please vote on the proposed release of MyFaces Portlet Bridge
2.0.0 TCK.
> This is the final version of the JSR 329 TCK and corresponds to
Portlet
> 2.0 Bridge for JavaServer Faces 1.2 specification which was
> finalized/approved by the JCP last month.
>
> Note: The TCK is designed to be built and run directly from the
maven
> project. Because of this users are pointed directly to the
subversion tag
> associated with version of the TCK:
>

 https://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr329-1.0.0
>
> Hence there are no repository artifacts built or hosted.
However, for
> convenience we do provide a downloadable version of this project
>
> These components can be inspected in
>

 http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/
<
 http://people.apache.org/%7Emfreedman/portlet-bridge-tck/jsr329-1.0.0/>

>
> I have verified that the distributables can be expanded and the
TCK can be
> built/run from this. In addition I have verified the contents in
 the
> subversion tag.
>
> Please review these materials and vote.
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
released,
> and why..
>
> Thanks,
> -Mike-
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf



>>
>>
>
>
> --
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
>
>

Re: [VOTE] Apache MyFaces Trinidad 1.2.14

2011-01-14 Thread Matt Cooper

+1

On Fri, Jan 14, 2011 at 11:01 AM, Jeanne Waldman
wrote:

> +1
>
> Matthias Wessendorf wrote, On 1/10/2011 8:28 AM PT:
>
>  Hi,
>>
>> I've created a Trinidad 1.2.14 release candidate, with the following
>> artifacts
>> up for a vote:
>>
>> SVN source tag (r1057250):
>> http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/
>>
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachemyfaces-013/
>>
>> Source release:
>>
>> https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip
>>
>> Vote will be open for 72 hours.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Thanks,
>> Matthias
>>
>>
>>
>

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Pavitra Subramaniam


Hello Matthias,

A quick question about the tags - 2.0.0-beta1 and trinidad-2.0.0-beta1 
here . Do you 
know what the former tag is for?


A diff of the poms show differences in the versions of jsf-ri, myfaces, 
trinidad plugins and some other minor differences. It appears that 
2.0.0-beta1 uses later versions.


Thanks
Pavitra

On 1/14/2011 8:48 AM, Matthias Wessendorf wrote:

if you can get it fixed quickly, sure - why not;
I can re-do this on Monday;

if the issue takes a bit longer, target it for beta-2
(I plan to run them more frequently, since I noticed there were no
releases in the last 11month, quite a shame :))

-M

On Fri, Jan 14, 2011 at 5:43 PM, MAX STARETS  wrote:
   

Actually<  I think we should take a quick look at
https://issues.apache.org/jira/browse/TRINIDAD-2008 first to decide how
important it is.

Max

On 1/14/2011 11:25 AM, MAX STARETS wrote:
 

+1

On 1/14/2011 7:10 AM, Matthias Wessendorf wrote:
   

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:

https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Jeanne Waldman





+1

Matthias Wessendorf wrote, On 1/14/2011 4:10 AM PT:

  +1

On Fri, Jan 14, 2011 at 1:10 PM, Matthias Wessendorf  wrote:
  
  
Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [VOTE] Apache MyFaces Trinidad 1.2.14

2011-01-14 Thread Jeanne Waldman


+1

Matthias Wessendorf wrote, On 1/10/2011 8:28 AM PT:

Hi,

I've created a Trinidad 1.2.14 release candidate, with the following artifacts
up for a vote:

SVN source tag (r1057250):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-013/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matthias Wessendorf

if you can get it fixed quickly, sure - why not;
I can re-do this on Monday;

if the issue takes a bit longer, target it for beta-2
(I plan to run them more frequently, since I noticed there were no
releases in the last 11month, quite a shame :))

-M

On Fri, Jan 14, 2011 at 5:43 PM, MAX STARETS  wrote:
> Actually< I think we should take a quick look at
> https://issues.apache.org/jira/browse/TRINIDAD-2008 first to decide how
> important it is.
>
> Max
>
> On 1/14/2011 11:25 AM, MAX STARETS wrote:
>>
>> +1
>>
>> On 1/14/2011 7:10 AM, Matthias Wessendorf wrote:
>>>
>>> Hi,
>>>
>>> I've created a Trinidad 2.0.0-beta-1 release candidate, with the
>>> following artifacts
>>> up for a vote:
>>>
>>> SVN source tag (r1058869):
>>> http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/
>>>
>>> Maven staging repo:
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-025/
>>>
>>> Source release:
>>>
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip
>>>
>>> Vote will be open for 72 hours.
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> Thanks,
>>> Matthias
>>>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread MAX STARETS

Actually< I think we should take a quick look at 
https://issues.apache.org/jira/browse/TRINIDAD-2008 first to decide how 
important it is.


Max

On 1/14/2011 11:25 AM, MAX STARETS wrote:

+1

On 1/14/2011 7:10 AM, Matthias Wessendorf wrote:

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip 



Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

[jira] Reopened: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution

2011-01-14 Thread Max Starets (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Starets reopened TRINIDAD-2008:
---


I am seeing it with the latest build

> tr:panelBorderLayout is throwing exception with Mojarra during tag execution
> 
>
> Key: TRINIDAD-2008
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2008
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 2.0.0-alpha-2
> Environment: Mojarra 2.0.4, WLS
>Reporter: Max Starets
>
> To reproduce the issue, try running the following test.xhtml page:
> http://www.w3.org/1999/xhtml";
>   xmlns:h="http://java.sun.com/jsf/html";
>   xmlns:f="http://java.sun.com/jsf/core";
>   xmlns:tr="http://myfaces.apache.org/trinidad";>
>   
>  
> 
> 
> 
> 
> 
> You will notice java.lang.ExceptionInInitializerError
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
> The root cause is the following exception:
> java.lang.NullPointerException
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:825)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at java.lang.Class.newInstance0(Class.java:355)
>   at java.lang.Class.newInstance(Class.java:308)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129)
>   at 
> com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864)
>   at 
> com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
>   at 
> com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89)
>   at 
> com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79)
>   at 
>

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Blake Sullivan


+1

-- Blake Sullivan

On 1/14/11 4:10 AM, Matthias Wessendorf wrote:

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread MAX STARETS


+1

On 1/14/2011 7:10 AM, Matthias Wessendorf wrote:

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

Re: [RE-VOTE] Release MyFaces Portlet Bridge 2.0.0 TCK

2011-01-14 Thread Grant Smith

+1

On Fri, Jan 14, 2011 at 2:24 AM, Werner Punz  wrote:

> +1
> Am 13.01.11 19:21, schrieb Michael Freedman:
>
>> Appropriate NOTICE/LICENSE files have now been added to the TCK project
>> and a distributable has been built and is hosted on:
>> http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/
>> .
>>
>>
>> The zip has been verified to ensure its download allows one to build/run
>> the TCK via maven. I also verified that the NOTICE/LICENSE exists and
>> are included in the various .wars that get built as part of
>> building/running the TCK.
>>
>> Please revote on this new distributable:
>> 
>> [ ] +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.
>>
>> On 1/12/2011 2:00 PM, Leonardo Uribe wrote:
>>
>>> Hi
>>>
>>> Checking the distributables, I have seen that there is no LICENSE /
>>> NOTICE on the parent folder or in META-INF folder. Is that correct?
>>>
>>> In comparison, the files for portlet bridge 2.0
>>> (portlet-bridge-2.0.0-src-all.zip) does have it.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/1/12 Matthias Wessendorf >> >
>>>
>>>
>>>was there any reason why you didn't use Nexus for the release
>>>procedure?
>>>MyFaces (sub)projects agreed to use this..
>>>
>>>On Tue, Jan 11, 2011 at 10:45 PM, Michael Freedman
>>>mailto:michael.freed...@oracle.com>>
>>>
>>>wrote:
>>>> Please vote on the proposed release of MyFaces Portlet Bridge
>>>2.0.0 TCK.
>>>> This is the final version of the JSR 329 TCK and corresponds to
>>>Portlet
>>>> 2.0 Bridge for JavaServer Faces 1.2 specification which was
>>>> finalized/approved by the JCP last month.
>>>>
>>>> Note: The TCK is designed to be built and run directly from the
>>>maven
>>>> project. Because of this users are pointed directly to the
>>>subversion tag
>>>> associated with version of the TCK:
>>>>
>>>
>>> https://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr329-1.0.0
>>>>
>>>> Hence there are no repository artifacts built or hosted.
>>>However, for
>>>> convenience we do provide a downloadable version of this project
>>>>
>>>> These components can be inspected in
>>>>
>>>
>>> http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/
>>><
>>> http://people.apache.org/%7Emfreedman/portlet-bridge-tck/jsr329-1.0.0/>
>>>
>>>>
>>>> I have verified that the distributables can be expanded and the
>>>TCK can be
>>>> built/run from this. In addition I have verified the contents in the
>>>> subversion tag.
>>>>
>>>> Please review these materials and vote.
>>>>
>>>> 
>>>> [ ] +1 for community members who have reviewed the bits
>>>> [ ] +0
>>>> [ ] -1 for fatal flaws that should cause these bits not to be
>>>released,
>>>> and why..
>>>>
>>>> Thanks,
>>>> -Mike-
>>>>
>>>
>>>
>>>
>>>--
>>>Matthias Wessendorf
>>>
>>>blog: http://matthiaswessendorf.wordpress.com/
>>>sessions: http://www.slideshare.net/mwessendorf
>>>twitter: http://twitter.com/mwessendorf
>>>
>>>
>>>
>
>


-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

[jira] Commented: (TRINIDAD-1960) NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant

2011-01-14 Thread JIRA


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981810#action_12981810
 ] 

Matthias Weßendorf commented on TRINIDAD-1960:
--

was reported as TRINIDAD-2008 as well

> NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant
> -
>
> Key: TRINIDAD-1960
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1960
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 1.2.14-core 
> Environment: Mac OS X 10.6, Java 6, Glassfish 3.0.2
>Reporter: Manuel Blechschmidt
> Attachments: PreventNullPointerInLocaleInfoScroptlet.patch
>
>
> Hi,
> I tried to deploy trinidad in a web app to my Glassfish Server. After 
> reporting and fixing TRINIDAD-1959 I get the following problem:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:598)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1050)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:169)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.intercept(ExtValGenericRenderKit.java:84)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.addRenderer()
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase._loadRenderKitMap(RenderKitBase.java:258)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.(RenderKitBase.java:56)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.(RenderKitDecorator.java:39)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.(CoreRenderKit.java:168)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.()
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220)
>   at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216)
>   at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:640)
>   at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538)
>   at 
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225)
>   at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
>   at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.newInstance(ExtValGenericRenderKit.java:62)
>   at 
> org.apache.myfaces.extensions.validator.generic.renderkit.GenericRenderKitWrapperFactory.createWrapper(GenericRenderKitWrapperFactory.java:45)
>   at 
> org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory.createWrapper(DefaultRenderKitWrapperFactory.java:54)
>   at 
> org.apache.myfaces.extensions.validator.core.renderkit.ExtValRenderKitFactory.getRenderKit(ExtValRenderKitFactory.java:84)
>   at 
> org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitFactory.getRenderKit(CoreRenderKitFactory.java:55)
>   at 
> com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:170)
>   at 
> com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
>   at 
> com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270)
>   at 
> com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
>   at 
> com.sun.faces.config.processor.ValidatorConfi

[jira] Created: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution

2011-01-14 Thread Max Starets (JIRA)

tr:panelBorderLayout is throwing exception with Mojarra during tag execution


 Key: TRINIDAD-2008
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
 Environment: Mojarra 2.0.4, WLS
Reporter: Max Starets


To reproduce the issue, try running the following test.xhtml page:

http://www.w3.org/1999/xhtml";
  xmlns:h="http://java.sun.com/jsf/html";
  xmlns:f="http://java.sun.com/jsf/core";
  xmlns:tr="http://myfaces.apache.org/trinidad";>
  
 






You will notice java.lang.ExceptionInInitializerError
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)

The root cause is the following exception:

java.lang.NullPointerException
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.(XhtmlUtils.java:825)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.(PanelBorderLayoutRenderer.java:1102)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at 
org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129)
at 
com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915)
at 
com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864)
at 
com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125)
at 
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513)
at 
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153)
at 
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
at 
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
at 
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
at 
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
at 
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
at 
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133)
at 
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
at 
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116)
at 
com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163)
at 
com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89)
at 
com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79)
at 
com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:148)
at 
com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:740)
at 
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:96)
  
It appears that LocaleInfoScriptlet.getSupportedLocale

Re: [POM] MyFaces-Parent

2011-01-14 Thread Matthias Wessendorf

ok,

let's do that overhaul with 11-SNAPSHOT, k?

-M

On Fri, Jan 14, 2011 at 4:18 PM, Mark Struberg  wrote:
> we could also go the other way around in the future. setting the source and 
> target levels to 1.5 and override it with 1.3 for our JSF-1 projects.
>
> I think this might go well beginning with myfaces-parent-11.
>
> LieGrue,
> strub
>
> --- On Fri, 1/14/11, Matthias Wessendorf  wrote:
>
>> From: Matthias Wessendorf 
>> Subject: Re: [POM] MyFaces-Parent
>> To: "MyFaces Development" 
>> Date: Friday, January 14, 2011, 3:03 PM
>> k
>>
>> On Fri, Jan 14, 2011 at 4:02 PM, Leonardo Uribe 
>> wrote:
>> > Hi
>> >
>> > Please don't change the source level. We have still
>> projects that requires
>> > jdk 1.4 (myfaces core 1.1.x )
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>> >
>> > 2011/1/14 Matthias Wessendorf 
>> >>
>> >> On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr
>> 
>> >> wrote:
>> >> > +1
>> >> >
>> >> > Maybe we should also change the ciManagement
>> section to hudson. It is
>> >> > still continuum, isn't it?
>> >>
>> >> k
>> >>
>> >> >
>> >> > Also: the source level is still 1.3. Maybe we
>> should change it to 1.5
>> >> > (or 1.6)?
>> >>
>> >> 1.5
>> >>
>> >> >
>> >> > Regards,
>> >> > Jakob
>> >> >
>> >> > Am Freitag, 14. Januar 2011 schrieb Matthias
>> Wessendorf
>> >> > :
>> >> >> Hi,
>> >> >>
>> >> >> I changed a few versions (assembly and
>> release plugin) on our master
>> >> >> pom;
>> >> >> before Jakob did change the dependency to
>> Apache-8
>> >> >>
>> >> >> Are we OK with releasing the
>> myfaces-pom-10 ?
>> >> >>
>> >> >> (yes, I can run it)
>> >> >>
>> >> >> -Matthias
>> >> >>
>> >> >> --
>> >> >> Matthias Wessendorf
>> >> >>
>> >> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> >> sessions: http://www.slideshare.net/mwessendorf
>> >> >> twitter: http://twitter.com/mwessendorf
>> >> >>
>> >> >
>> >> > --
>> >> > Jakob Korherr
>> >> >
>> >> > blog: http://www.jakobk.com
>> >> > twitter: http://twitter.com/jakobkorherr
>> >> > work: http://www.irian.at
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>>
>
>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matthias Wessendorf

http://svn.apache.org/viewvc?rev=1059053&view=rev

On Fri, Jan 14, 2011 at 5:06 PM, Matthias Wessendorf  wrote:
> let me delete that branch
>
> -M
>
> On Fri, Jan 14, 2011 at 5:01 PM, Andy Schwartz
>  wrote:
>> Not sure how much weight my non-committer vote holds, but +1 from me. :-)
>>
>> BTW, I noticed that there is an older, unrelated 2.0.0-beta-1 branch
>> from last year:
>>
>> http://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0-beta-1
>>
>> Does this branch contain any meaningful history?  If not, wondering
>> whether we should prune it, if only to avoid confusion with our newer
>> 2.0.0-beta-1 tag.
>>
>> Andy
>>
>
>
>
> --
> 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

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matthias Wessendorf

let me delete that branch

-M

On Fri, Jan 14, 2011 at 5:01 PM, Andy Schwartz
 wrote:
> Not sure how much weight my non-committer vote holds, but +1 from me. :-)
>
> BTW, I noticed that there is an older, unrelated 2.0.0-beta-1 branch
> from last year:
>
> http://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0-beta-1
>
> Does this branch contain any meaningful history?  If not, wondering
> whether we should prune it, if only to avoid confusion with our newer
> 2.0.0-beta-1 tag.
>
> Andy
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Andy Schwartz

Not sure how much weight my non-committer vote holds, but +1 from me. :-)

BTW, I noticed that there is an older, unrelated 2.0.0-beta-1 branch
from last year:

http://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0-beta-1

Does this branch contain any meaningful history?  If not, wondering
whether we should prune it, if only to avoid confusion with our newer
2.0.0-beta-1 tag.

Andy

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matt Cooper

+1

On Fri, Jan 14, 2011 at 5:10 AM, Matthias Wessendorf wrote:

> +1
>
> On Fri, Jan 14, 2011 at 1:10 PM, Matthias Wessendorf 
> wrote:
> > Hi,
> >
> > I've created a Trinidad 2.0.0-beta-1 release candidate, with the
> > following artifacts
> > up for a vote:
> >
> > SVN source tag (r1058869):
> > http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachemyfaces-025/
> >
> > Source release:
> >
> https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip
> >
> > Vote will be open for 72 hours.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Thanks,
> > Matthias
> >
> > --
> > 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
>

Re: [POM] MyFaces-Parent

2011-01-14 Thread Scott O'Bryan

I agree.  Legacy projects can:

1 keep referencing the old master pom
Or
2 set an older JDK level when they upgrade.  There are far more
projects right now which require JDK 5+

On Jan 14, 2011, at 8:19 AM, Mark Struberg  wrote:

> we could also go the other way around in the future. setting the source and 
> target levels to 1.5 and override it with 1.3 for our JSF-1 projects.
>
> I think this might go well beginning with myfaces-parent-11.
>
> LieGrue,
> strub
>
> --- On Fri, 1/14/11, Matthias Wessendorf  wrote:
>
>> From: Matthias Wessendorf 
>> Subject: Re: [POM] MyFaces-Parent
>> To: "MyFaces Development" 
>> Date: Friday, January 14, 2011, 3:03 PM
>> k
>>
>> On Fri, Jan 14, 2011 at 4:02 PM, Leonardo Uribe 
>> wrote:
>>> Hi
>>>
>>> Please don't change the source level. We have still
>> projects that requires
>>> jdk 1.4 (myfaces core 1.1.x )
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/1/14 Matthias Wessendorf 

 On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr
>> 
 wrote:
> +1
>
> Maybe we should also change the ciManagement
>> section to hudson. It is
> still continuum, isn't it?

 k

>
> Also: the source level is still 1.3. Maybe we
>> should change it to 1.5
> (or 1.6)?

 1.5

>
> Regards,
> Jakob
>
> Am Freitag, 14. Januar 2011 schrieb Matthias
>> Wessendorf
> :
>> Hi,
>>
>> I changed a few versions (assembly and
>> release plugin) on our master
>> pom;
>> before Jakob did change the dependency to
>> Apache-8
>>
>> Are we OK with releasing the
>> myfaces-pom-10 ?
>>
>> (yes, I can run it)
>>
>> -Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>



 --
 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
>>
>
>
>

Re: [POM] MyFaces-Parent

2011-01-14 Thread Mark Struberg

we could also go the other way around in the future. setting the source and 
target levels to 1.5 and override it with 1.3 for our JSF-1 projects.

I think this might go well beginning with myfaces-parent-11.

LieGrue,
strub

--- On Fri, 1/14/11, Matthias Wessendorf  wrote:

> From: Matthias Wessendorf 
> Subject: Re: [POM] MyFaces-Parent
> To: "MyFaces Development" 
> Date: Friday, January 14, 2011, 3:03 PM
> k
> 
> On Fri, Jan 14, 2011 at 4:02 PM, Leonardo Uribe 
> wrote:
> > Hi
> >
> > Please don't change the source level. We have still
> projects that requires
> > jdk 1.4 (myfaces core 1.1.x )
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2011/1/14 Matthias Wessendorf 
> >>
> >> On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr
> 
> >> wrote:
> >> > +1
> >> >
> >> > Maybe we should also change the ciManagement
> section to hudson. It is
> >> > still continuum, isn't it?
> >>
> >> k
> >>
> >> >
> >> > Also: the source level is still 1.3. Maybe we
> should change it to 1.5
> >> > (or 1.6)?
> >>
> >> 1.5
> >>
> >> >
> >> > Regards,
> >> > Jakob
> >> >
> >> > Am Freitag, 14. Januar 2011 schrieb Matthias
> Wessendorf
> >> > :
> >> >> Hi,
> >> >>
> >> >> I changed a few versions (assembly and
> release plugin) on our master
> >> >> pom;
> >> >> before Jakob did change the dependency to
> Apache-8
> >> >>
> >> >> Are we OK with releasing the
> myfaces-pom-10 ?
> >> >>
> >> >> (yes, I can run it)
> >> >>
> >> >> -Matthias
> >> >>
> >> >> --
> >> >> Matthias Wessendorf
> >> >>
> >> >> blog: http://matthiaswessendorf.wordpress.com/
> >> >> sessions: http://www.slideshare.net/mwessendorf
> >> >> twitter: http://twitter.com/mwessendorf
> >> >>
> >> >
> >> > --
> >> > Jakob Korherr
> >> >
> >> > blog: http://www.jakobk.com
> >> > twitter: http://twitter.com/jakobkorherr
> >> > work: http://www.irian.at
> >> >
> >>
> >>
> >>
> >> --
> >> 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
>

Re: [POM] MyFaces-Parent

2011-01-14 Thread Jakob Korherr

IMO those (legacy) projects should override the default settings to
1.4 when upgrading to parent-10. Currently every new project has to do
this for 1.5 and that's annoying...

Regards,
Jakob

Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf :
> k
>
> On Fri, Jan 14, 2011 at 4:02 PM, Leonardo Uribe  wrote:
>> Hi
>>
>> Please don't change the source level. We have still projects that requires
>> jdk 1.4 (myfaces core 1.1.x )
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/1/14 Matthias Wessendorf 
>>>
>>> On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr 
>>> wrote:
>>> > +1
>>> >
>>> > Maybe we should also change the ciManagement section to hudson. It is
>>> > still continuum, isn't it?
>>>
>>> k
>>>
>>> >
>>> > Also: the source level is still 1.3. Maybe we should change it to 1.5
>>> > (or 1.6)?
>>>
>>> 1.5
>>>
>>> >
>>> > Regards,
>>> > Jakob
>>> >
>>> > Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf
>>> > :
>>> >> Hi,
>>> >>
>>> >> I changed a few versions (assembly and release plugin) on our master
>>> >> pom;
>>> >> before Jakob did change the dependency to Apache-8
>>> >>
>>> >> Are we OK with releasing the myfaces-pom-10 ?
>>> >>
>>> >> (yes, I can run it)
>>> >>
>>> >> -Matthias
>>> >>
>>> >> --
>>> >> Matthias Wessendorf
>>> >>
>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>> >> sessions: http://www.slideshare.net/mwessendorf
>>> >> twitter: http://twitter.com/mwessendorf
>>> >>
>>> >
>>> > --
>>> > Jakob Korherr
>>> >
>>> > blog: http://www.jakobk.com
>>> > twitter: http://twitter.com/jakobkorherr
>>> > work: http://www.irian.at
>>> >
>>>
>>>
>>>
>>> --
>>> 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
>

-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Re: [POM] MyFaces-Parent

2011-01-14 Thread Matthias Wessendorf

k

On Fri, Jan 14, 2011 at 4:02 PM, Leonardo Uribe  wrote:
> Hi
>
> Please don't change the source level. We have still projects that requires
> jdk 1.4 (myfaces core 1.1.x )
>
> regards,
>
> Leonardo Uribe
>
> 2011/1/14 Matthias Wessendorf 
>>
>> On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr 
>> wrote:
>> > +1
>> >
>> > Maybe we should also change the ciManagement section to hudson. It is
>> > still continuum, isn't it?
>>
>> k
>>
>> >
>> > Also: the source level is still 1.3. Maybe we should change it to 1.5
>> > (or 1.6)?
>>
>> 1.5
>>
>> >
>> > Regards,
>> > Jakob
>> >
>> > Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf
>> > :
>> >> Hi,
>> >>
>> >> I changed a few versions (assembly and release plugin) on our master
>> >> pom;
>> >> before Jakob did change the dependency to Apache-8
>> >>
>> >> Are we OK with releasing the myfaces-pom-10 ?
>> >>
>> >> (yes, I can run it)
>> >>
>> >> -Matthias
>> >>
>> >> --
>> >> Matthias Wessendorf
>> >>
>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> sessions: http://www.slideshare.net/mwessendorf
>> >> twitter: http://twitter.com/mwessendorf
>> >>
>> >
>> > --
>> > Jakob Korherr
>> >
>> > blog: http://www.jakobk.com
>> > twitter: http://twitter.com/jakobkorherr
>> > work: http://www.irian.at
>> >
>>
>>
>>
>> --
>> 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

Re: [POM] MyFaces-Parent

2011-01-14 Thread Leonardo Uribe

Hi

Please don't change the source level. We have still projects that requires
jdk 1.4 (myfaces core 1.1.x )

regards,

Leonardo Uribe

2011/1/14 Matthias Wessendorf 

> On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr 
> wrote:
> > +1
> >
> > Maybe we should also change the ciManagement section to hudson. It is
> > still continuum, isn't it?
>
> k
>
> >
> > Also: the source level is still 1.3. Maybe we should change it to 1.5 (or
> 1.6)?
>
> 1.5
>
> >
> > Regards,
> > Jakob
> >
> > Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf <
> mat...@apache.org>:
> >> Hi,
> >>
> >> I changed a few versions (assembly and release plugin) on our master
> pom;
> >> before Jakob did change the dependency to Apache-8
> >>
> >> Are we OK with releasing the myfaces-pom-10 ?
> >>
> >> (yes, I can run it)
> >>
> >> -Matthias
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >>
> >
> > --
> > Jakob Korherr
> >
> > blog: http://www.jakobk.com
> > twitter: http://twitter.com/jakobkorherr
> > work: http://www.irian.at
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [POM] MyFaces-Parent

2011-01-14 Thread Matthias Wessendorf

On Fri, Jan 14, 2011 at 3:49 PM, Jakob Korherr  wrote:
> +1
>
> Maybe we should also change the ciManagement section to hudson. It is
> still continuum, isn't it?

k

>
> Also: the source level is still 1.3. Maybe we should change it to 1.5 (or 
> 1.6)?

1.5

>
> Regards,
> Jakob
>
> Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf :
>> Hi,
>>
>> I changed a few versions (assembly and release plugin) on our master pom;
>> before Jakob did change the dependency to Apache-8
>>
>> Are we OK with releasing the myfaces-pom-10 ?
>>
>> (yes, I can run it)
>>
>> -Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [POM] MyFaces-Parent

2011-01-14 Thread Jakob Korherr

+1

Maybe we should also change the ciManagement section to hudson. It is
still continuum, isn't it?

Also: the source level is still 1.3. Maybe we should change it to 1.5 (or 1.6)?

Regards,
Jakob

Am Freitag, 14. Januar 2011 schrieb Matthias Wessendorf :
> Hi,
>
> I changed a few versions (assembly and release plugin) on our master pom;
> before Jakob did change the dependency to Apache-8
>
> Are we OK with releasing the myfaces-pom-10 ?
>
> (yes, I can run it)
>
> -Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

[POM] MyFaces-Parent

2011-01-14 Thread Matthias Wessendorf

Hi,

I changed a few versions (assembly and release plugin) on our master pom;
before Jakob did change the dependency to Apache-8

Are we OK with releasing the myfaces-pom-10 ?

(yes, I can run it)

-Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

[jira] Created: (TRINIDAD-2007) change TLD namespace schemas

2011-01-14 Thread JIRA

change TLD namespace schemas


 Key: TRINIDAD-2007
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2007
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf


For Trinidad 1.2.15 and the second beta release, we need to address the issue 
on the TLDs.

Similar to TOMAHAWK-1560



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matthias Wessendorf

+1

On Fri, Jan 14, 2011 at 1:10 PM, Matthias Wessendorf  wrote:
> Hi,
>
> I've created a Trinidad 2.0.0-beta-1 release candidate, with the
> following artifacts
> up for a vote:
>
> SVN source tag (r1058869):
> http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachemyfaces-025/
>
> Source release:
> https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Thanks,
> Matthias
>
> --
> 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

[VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matthias Wessendorf

Hi,

I've created a Trinidad 2.0.0-beta-1 release candidate, with the
following artifacts
up for a vote:

SVN source tag (r1058869):
http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/

Source release:
https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Thanks,
Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

[jira] Reopened: (MYFACES-2958) Improve handling of AJAX response if source element is deleted

2011-01-14 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Kočí reopened MYFACES-2958:
--


The second part of patch is not applied or was deleted by mistake:












and

myfaces.config.no_portlet_env = true

does not work: after button click the ViewState hidden input disappears from 
entire DOM.


Werner, can you please take a look at it? Attached patch contains modification 
of _AjaxResponse.js, but in current trunk is this modification not present.


> Improve handling of AJAX response if source element is deleted
> --
>
> Key: MYFACES-2958
> URL: https://issues.apache.org/jira/browse/MYFACES-2958
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-314
>Affects Versions: 2.0.3-SNAPSHOT
> Environment: myfaces trunk
>Reporter: Martin Kočí
> Fix For: 2.0.3
>
> Attachments: MYFACES-2958.patch
>
>
> If ajax response removes HTML form with source element, .js stops processing 
> of others  HTML forms (specially it does not update ViewState elements).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [RE-VOTE] Release MyFaces Portlet Bridge 2.0.0 TCK

2011-01-14 Thread Werner Punz

+1
Am 13.01.11 19:21, schrieb Michael Freedman:

Appropriate NOTICE/LICENSE files have now been added to the TCK project
and a distributable has been built and is hosted on:
http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/
.

The zip has been verified to ensure its download allows one to build/run
the TCK via maven. I also verified that the NOTICE/LICENSE exists and
are included in the various .wars that get built as part of
building/running the TCK.

Please revote on this new distributable:

[ ] +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.

On 1/12/2011 2:00 PM, Leonardo Uribe wrote:

Hi

Checking the distributables, I have seen that there is no LICENSE /
NOTICE on the parent folder or in META-INF folder. Is that correct?

In comparison, the files for portlet bridge 2.0
(portlet-bridge-2.0.0-src-all.zip) does have it.

regards,

Leonardo Uribe

2011/1/12 Matthias Wessendorf mailto:mat...@apache.org>>

was there any reason why you didn't use Nexus for the release
procedure?
MyFaces (sub)projects agreed to use this..

On Tue, Jan 11, 2011 at 10:45 PM, Michael Freedman
mailto:michael.freed...@oracle.com>>
wrote:
> Please vote on the proposed release of MyFaces Portlet Bridge
2.0.0 TCK.
> This is the final version of the JSR 329 TCK and corresponds to
Portlet
> 2.0 Bridge for JavaServer Faces 1.2 specification which was
> finalized/approved by the JCP last month.
>
> Note: The TCK is designed to be built and run directly from the
maven
> project. Because of this users are pointed directly to the
subversion tag
> associated with version of the TCK:
>

https://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr329-1.0.0
>
> Hence there are no repository artifacts built or hosted.
However, for
> convenience we do provide a downloadable version of this project
>
> These components can be inspected in
>
http://people.apache.org/~mfreedman/portlet-bridge-tck/jsr329-1.0.0/

>
> I have verified that the distributables can be expanded and the
TCK can be
> built/run from this. In addition I have verified the contents in the
> subversion tag.
>
> Please review these materials and vote.
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
released,
> and why..
>
> Thanks,
> -Mike-
>

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

45 matches

Mail list logo