myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <darkar...@gmail.com>
Subject Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Date Wed, 22 Oct 2008 13:41:09 GMT
Wow, it's beginning to sound like a JVM or OS error to meet.  None of 
the code we have in the bridge SHOULD be OS dependent.  Plus, it's 
working fine on my machine although, admittedly, I'm running 1.6_10.  
I'll try to downgrade to 1.5 and see if I can reproduce the issue.

Scott

Leonardo Uribe wrote:
>
>
> On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <lu4242@gmail.com 
> <mailto:lu4242@gmail.com>> wrote:
>
>
>
>     On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan
>     <darkarena@gmail.com <mailto:darkarena@gmail.com>> wrote:
>
>         Leonardo,
>
>         Right.  This was the problem discovered last release.  The
>         behavior your seeing is actually expected (it was CHANGED to
>         do what it does because it USED to throw an exception).  What
>         Mike discovered was that, although there is really no need to
>         tokenize server-side and JS state saving, we were not actually
>         gaining anything by NOT tokenizing it (there are no
>         performance increases because of the current code path).  And
>         in order for the bridge to automatically determine the token
>         being used, it needs to be present.
>
>         The way I see it, we have two choices.  We can try to work off
>         of the implementation name of the distribution on MyFaces
>         (which would make the implementation name part of the
>         contract) OR we can modify MyFaces to always write the token.
>          Alternatively, I believe if you set the token in the init
>         parameters of the portlet (as specified in JSR-301) then that
>         will also get rid of the log entry.  We were trying to let the
>         R.I. autodetect between the R.I. and MyFaces.
>
>         As for the excludes, if that works then we should probably
>         commit these changes to the alpha-3 branch and I can regenrate.
>
>
>     I have made more tests about this problem. It seems the problem is
>     not related to write the state marker or not. The actual code if
>     the marker is not found it just write it directly the response.
>
>     I have one machine with firefox 3.0.3, and the problem is not
>     present. The machine with firefox 2.0.0.17 <http://2.0.0.17> has
>     the problem.
>
>     A correct request (firefox 3.0.3, opera 9 or IE 7) output on the
>     log (stdout) something like this:
>
>     2008-10-21 19:25:47.666:/portlet-bridge-demo:INFO: 
>     PortletExternalContextImpl.g
>     etViewId: found jsf target viewId = view:/helloworld/index.jsp
>     2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:  dumpScopeId:
>     ACTION_PHASE
>     2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:  Elements in
>     scope: portlet-b
>     ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb
>     2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.requestParameters
>     2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.facesViewRoot
>     2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.el.u
>     nified.resolver.managedbean.beansUnderConstruction
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       jsf_sequence
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       namebean
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.shar
>     ed_impl.renderkit.RendererUtils.RenderKitImpl
>     2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:  end dumpScopeId
>     Oct 21, 2008 7:25:47 PM org.apache.pluto.driver.PortalDriverFilter
>     doFilter
>     INFO: Forwarding to realPath: /pluto/index.jsp
>     2008-10-21 19:25:47.744:/portlet-bridge-demo:INFO:  Unable to
>     locate a SAVESTATE
>
>     _FIELD_MARKER in response.  This could be because your Faces
>     environment doesn't
>      write such a marker or because the bridge doesn't know the marker
>     in use.  If t
>     he later, configure the appropriate application init parameter
>     javax.portlet.fac
>     es.SAVESTATE_FIELD_MARKER.
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  dumpScopeId:
>     RENDER_PHASE
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  Elements in
>     scope: portlet-b
>     ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.requestParameters
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.el.u
>     nified.resolver.managedbean.beansUnderConstruction
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       jsf_sequence
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       namebean
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.shar
>     ed_impl.renderkit.RendererUtils.RenderKitImpl
>     2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  end dumpScopeId
>
>     A request using firefox 2.0.0.17 <http://2.0.0.17> looks like this:
>
>     2008-10-21 19:26:46.822:/portlet-bridge-demo:INFO: 
>     PortletExternalContextImpl.g
>     etViewId: found jsf target viewId = view:/helloworld/index.jsp
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  dumpScopeId:
>     ACTION_PHASE
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  Elements in
>     scope: portlet-b
>     ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.requestParameters
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.facesViewRoot
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.el.u
>     nified.resolver.managedbean.beansUnderConstruction
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       jsf_sequence
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       namebean
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.shar
>     ed_impl.renderkit.RendererUtils.RenderKitImpl
>     2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  end dumpScopeId
>     Oct 21, 2008 7:26:46 PM org.apache.pluto.driver.PortalDriverFilter
>     doFilter
>     INFO: Forwarding to realPath: /pluto/index.jsp
>     2008-10-21 19:26:46.869:/portlet-bridge-demo:INFO:  Unable to
>     locate a SAVESTATE
>
>     _FIELD_MARKER in response.  This could be because your Faces
>     environment doesn't
>      write such a marker or because the bridge doesn't know the marker
>     in use.  If t
>     he later, configure the appropriate application init parameter
>     javax.portlet.fac
>     es.SAVESTATE_FIELD_MARKER.
>     2008-10-21 19:26:46.869:/portlet-bridge-demo:INFO:  dumpScopeId:
>     RENDER_PHASE
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:  Elements in
>     scope: portlet-b
>     ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.requestParameters
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.el.u
>     nified.resolver.managedbean.beansUnderConstruction
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       jsf_sequence
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       namebean
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.shar
>     ed_impl.renderkit.RendererUtils.RenderKitImpl
>     2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:  end dumpScopeId
>     Oct 21, 2008 7:26:48 PM org.apache.pluto.driver.PortalDriverFilter
>     doFilter
>     INFO: Forwarding to realPath: /pluto/index.jsp
>     2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO: 
>     PortletExternalContextImpl.g
>     etViewId: found jsf target viewId = view:/helloworld/hello.jsp
>     2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO:  History for
>     mode: view : /he
>     lloworld/hello.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet
>     -bridge-demo%3Ayh4tse3ctjqw%3Aview%3A-25ecdd41%3A11d21e77bb0%3A-7fda&javax.faces
>     .ViewState=CX8k%2BpTXi4XRIwnlHJaWVyc31c23xqtKQKd4yZOqnb9H8Xs6FKjAxuC58ztDpvj1O2O
>     1%2B8C%2F2gMMzdqOlEnLOB4LrckaiKM%2Bu3h3WzFSRkY%3D
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  Unable to
>     locate a SAVESTATE
>
>     _FIELD_MARKER in response.  This could be because your Faces
>     environment doesn't
>      write such a marker or because the bridge doesn't know the marker
>     in use.  If t
>     he later, configure the appropriate application init parameter
>     javax.portlet.fac
>     es.SAVESTATE_FIELD_MARKER.
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  dumpScopeId:
>     RENDER_PHASE
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  Elements in
>     scope: portlet-b
>     ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.port
>     let.faces.includeInScope.requestParameters
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.el.u
>     nified.resolver.managedbean.beansUnderConstruction
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.appl
>     ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       jsf_sequence
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       namebean
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:      
>     org.apache.myfaces.shar
>     ed_impl.renderkit.RendererUtils.RenderKitImpl
>     2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  end dumpScopeId
>
>     The interesting thing about this is that the  RENDER_PHASE is
>     executed twice (there are not two different request, just one).
>
>     I'll try modify myfaces core 1.2.x, so it writes the marker on
>     server state saving (yes, there are no performance increase, but
>     I'll take a look at it), and see what happens. It seems to be a
>     non blocking issue for release if we modify myfaces core.
>      
>
>
> I apply the modification on JspViewHandlerImpl, so the marker is 
> always written. The result is the same, but the warning disappear. I 
> tried to test firefox 2.0.0.17 <http://2.0.0.17> (windows vista) from 
> another computer and works normal, so it seem to be a problem on my 
> other machine (windows xp). I tried install firefox 3.0.3 and the 
> problem is present too. The strange part of all this stuff is that jsf 
> ri does not have the problem (and using myfaces core with client side 
> state saving too). The configuration that fails specifically is 
> windows xp, firefox, myfaces core 1.2.x and server state saving.
>
>  
>
>
>         Scott
>
>         Leonardo Uribe wrote:
>
>
>
>             On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe
>             <lu4242@gmail.com <mailto:lu4242@gmail.com>
>             <mailto:lu4242@gmail.com <mailto:lu4242@gmail.com>>> wrote:
>
>                The problem only happens when server state saving is
>             used. On
>                client side state saving everything works well.
>
>                I'll try add the params to faces-config.xml and see
>             what happens.
>
>
>             Checking myfaces core 1.2.x code, class JspViewHandlerImpl
>             there is this code:
>
>                public void writeState(FacesContext facesContext)
>             throws IOException
>                {
>                    StateManager stateManager =
>             facesContext.getApplication().getStateManager();
>                    if (stateManager.isSavingStateInClient(facesContext))
>                    {
>                    // Only write state marker if javascript view state
>             is disabled
>                    ExternalContext extContext =
>             facesContext.getExternalContext();
>                    if
>             (!(JavascriptUtils.isJavascriptAllowed(extContext) &&
>             MyfacesConfig.getCurrentInstance(extContext).isViewStateJavascript()))
>             {
>                      
>              facesContext.getResponseWriter().write(FORM_STATE_MARKER);
>                    }
>                    }
>                    else
>                    {
>                        stateManager.writeState(facesContext, new
>             Object[2]);
>                    }
>                }
>
>             Myfaces core 1.2.x does not write any marker on server
>             side state saving (I suppose jsf ri does) and the inner
>             class JspViewHandlerImpl.StateMarkerAwareWriter (this
>             class is responsible to change the marker) is only used on
>             client side state saving, but portlet bridge always assume
>             that some marker is written.
>              
>
>                On Tue, Oct 21, 2008 at 5:57 PM, michael freedman
>                <michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>
>             <mailto:michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>>>
>                wrote:
>
>                    The main thing to note here is that this message is
>             always
>                    written to the log when running this Myfaces config
>             (for all
>                    your browsers) and hence is non-indicative of the
>             problem.
>                     FYI -- we can't determine that its correct (for
>             all cases)
>                    that we didn't find the Token which is why we write
>             a log message.
>                       -Mike-
>
>
>                    Scott O'Bryan wrote:
>
>                        Hey Leo, this could be related to the
>             state-saving issue
>                        with MyFaces that I posted to the dev list
>             about a month
>                        ago.  I havn't had time to fix it (or even
>             write a JIRA
>                        ticket) but, essentially, there are times that
>             MyFaces
>                        does not generate a state-saving token when
>             maybe it
>                        should.  On the previous attempt for alpha-3,
>             we were
>                        generating an exception.  This has changed into
>             a stern
>                        warning which is what you're seeing in the logs.
>
>                        Are you seeing a functional issue?  If so, then
>             I suppose
>                        I can try and tackle the MyFaces issue in my
>             copious
>                        amounts of free time to see if we can resolve
>             the issue
>                        from the MyFaces side.
>
>                        Scott
>
>                        Leonardo Uribe wrote:
>
>
>
>                            On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe
>                            <lu4242@gmail.com <mailto:lu4242@gmail.com>
>             <mailto:lu4242@gmail.com <mailto:lu4242@gmail.com>>
>                            <mailto:lu4242@gmail.com
>             <mailto:lu4242@gmail.com> <mailto:lu4242@gmail.com
>             <mailto:lu4242@gmail.com>>>>
>
>                            wrote:
>
>
>
>                               On Tue, Oct 21, 2008 at 4:50 PM, michael
>             freedman
>                               <michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>
>                            <mailto:michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>>
>                            <mailto:michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>
>                            <mailto:michael.freedman@oracle.com
>             <mailto:michael.freedman@oracle.com>>>>
>                               wrote:
>
>                                   What do you mean by the "demo app stops
>                            running"?  Does it run
>                                   at all?  If so how far do you get
>             before you
>                            run into the
>                                   problem?  The error message you are
>             seeing is
>                            written into the
>                                   log, right? If so, all this is
>             telling you is
>                            that Myfaces is
>                                   running in a configuration where it
>             writes the
>                            state directly
>                                   into the rendition versus using the
>                            cache/replace model of the
>                                   SAVESTATE_FIELD_MARKER.   FYI ... I
>             also am
>                            using Firefox
>                                   2.0.0.17 <http://2.0.0.17>
>             <http://2.0.0.17> <http://2.0.0.17>
>
>                            and the demo is running fine for
>                                   me.  So please send me more info on
>             reproducing.
>
>
>                               I just run the demo like this:
>
>                               mvn clean -PjettyConfig jetty:run
>             (according to the
>                            pom myfaces
>                               core 1.2.2 is used)
>
>                               and then try the demo several times.
>             Sometimes
>                            works but others do
>                               not and the message is on the log. I'm
>             just run the
>                            demo as is,
>                               without any modification. I don't know
>             if there is
>                            some special
>                               configuration to make it work correctly with
>                            myfaces core. If this
>                               is true, it could be good to use
>             profiles to define
>                            several
>                               web.xml files for configure and test it.
>                                              One last note: stops
>             running means when you click a
>                            button or link the state is not restored
>             and the
>                            request is readed as it was new.
>                            
>                                   As for running with the RI there are
>                            potentially two issues:
>                                   first the command is now:
>                                   mvn clean -PjettyConfig
>             -Djsf=ri-provided jetty:run
>
>
>                               Ok, thanks, it works and does not have
>             the problem
>                            with firefox.
>                                                     The other problem
>             is you need to make sure its
>                            not trying to
>                                   run with the prior MyFaces TLD --
>             generally the
>                            clean should
>                                   do this, though.
>                                       -Mike-
>
>
>                                   Leonardo Uribe wrote:
>
>                                       I tried to run the demo module
>             and on
>                                firefox 2.0.0.17 <http://2.0.0.17>
>             <http://2.0.0.17>
>                                       <http://2.0.0.17> sometimes I
>             have this
>                                (the demo app stops
>                                       running):
>
>                                       2008-10-21
>                                15:51:40.318:/portlet-bridge-demo:INFO:
>              History
>                                       for mode: view : /he
>                                                        
>             lloworld/index.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet
>
>                                                        
>             -bridge-demo%3Ayd3exguy3te2%3Aview%3A24d73b2a%3A11d21270f21%3A-7fd3&javax.faces.
>
>                                                        
>             ViewState=qpZU311sohuneMJrlpRjNB4K2cfv0ubhRgzMYD5Kf4V1pkzHlFXyeKdNfb5408dPXMeN1u
>
>                                      
>             tp3qg5cWArexFYziMyJAzgTwOQ8GFyqxDCz8Y%3D
>                                       2008-10-21
>                                15:51:40.318:/portlet-bridge-demo:INFO:
>              Unable to
>                                       locate a SAVESTATE
>                                       _FIELD_MARKER in response.  This
>             could be
>                                because your Faces
>                                       environment doesn't
>                                        write such a marker or because
>             the bridge
>                                doesn't know the
>                                       marker in use.  If t
>                                       he later, configure the appropriate
>                                application init
>                                       parameter javax.portlet.fac
>                                       es.SAVESTATE_FIELD_MARKER.
>
>                                       In opera 9 and IE 7 everything
>             works fine.
>
>                                       Also when I tried to run
>
>                                       mvn clean -PjettyConfig -Djsf=ri
>             jetty:run
>
>                                       throws this error:
>
>                                       2008-10-21 15:52:51.809::WARN:
>              failed
>                                portlet-bridge-demo
>                                       java.lang.NoClassDefFoundError:
>                                javax/faces/FacesException
>                                               at
>                              
>              java.lang.ClassLoader.defineClass1(Native Method)
>                                               at
>                                                        
>             java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>                                               at
>                                                        
>             java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
>                                       4)
>                                               at
>                                                        
>             java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>                                               at
>                                                        
>             java.net.URLClassLoader.access$000(URLClassLoader.java:56)
>                                               at
>                              
>              java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>                                               at
>                              
>              java.security.AccessController.doPrivileged(Native
>                                       Method)
>                                               at
>                                                        
>             java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>                                               at
>                                                        
>             org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade
>                                       r.java:366)
>                                               at
>                                                        
>             org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade
>                                       r.java:337)
>
>                                       maybe this is not blocking but
>             it could be
>                                good to have a
>                                       fast way to test it.
>
>                                       On Tue, Oct 21, 2008 at 12:28
>             PM, Scott O'Bryan
>                                       <darkarena@gmail.com
>             <mailto:darkarena@gmail.com>
>                                <mailto:darkarena@gmail.com
>             <mailto:darkarena@gmail.com>>
>                                <mailto:darkarena@gmail.com
>             <mailto:darkarena@gmail.com>
>
>                                <mailto:darkarena@gmail.com
>             <mailto:darkarena@gmail.com>>>> wrote:
>
>                                           +1
>
>
>                                           Scott O'Bryan wrote:
>
>                                               Sorry, I forgot the word
>             [VOTE] in
>                                the subject.
>
>                                               Scott O'Bryan wrote:
>
>                                                   Hi,
>
>                                                   I'm trying to
>             release the
>                                MyFaces Portlet Bridge
>                                                   Master
>             1.0.0-alpha-3.  This
>                                release was created
>                                                   in order to support
>             the latest
>                                JSR-301 Public
>                                                   Review so that it
>             may be tested
>                                by developers
>                                                   during the review
>             process.
>                                 This is still an
>                                                   alpha release
>             because there is
>                                currently no
>                                                   testing of the R.I.
>
>                                                   I was running the
>             needed tasks
>                                to get the
>                                                   1.0.0-alpha-3
>             release of the
>                                Apache MyFaces
>                                                   Portlet Bridge out. The
>                                artifacts are deployed to
>                                                   my private Apache
>             account ([1]).
>
>                                                   Please take a look
>             at the
>                                                  
>             "portlet-bridge-master-pom-1"
>                                artifacts and vote
>
>                                                                    
>             ------------------------------------------------
>                                                   [ ] +1 for community
>             members
>                                who have reviewed
>                                                   the bits
>                                                   [ ] +0
>                                                   [ ] -1 for fatal
>             flaws that
>                                should cause these
>                                                   bits not to be released,
>                                                          and
>             why..............
>                                                                    
>             ------------------------------------------------
>
>                                                   Thanks,
>                                                     Scott
>
>                                                   [1]
>                                                                    
>             http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3
>             <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>                              
>              <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>                                                                    
>             <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>                                                                    
>             <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>
>
>
>
>
>
>
>
>
>
>
>


Mime
View raw message