You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by so...@apache.org on 2008/02/19 22:35:45 UTC
svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml
trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Author: sobryan
Date: Tue Feb 19 13:35:43 2008
New Revision: 629242
URL: http://svn.apache.org/viewvc?rev=629242&view=rev
Log:
TRINIDAD-134 - StateManagerImpl is not fully compatible with JSR-301
Modified:
myfaces/trinidad/trunk/pom.xml
myfaces/trinidad/trunk/trinidad-impl/pom.xml
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Modified: myfaces/trinidad/trunk/pom.xml
URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
==============================================================================
--- myfaces/trinidad/trunk/pom.xml (original)
+++ myfaces/trinidad/trunk/pom.xml Tue Feb 19 13:35:43 2008
@@ -351,6 +351,13 @@
</dependency>
<dependency>
+ <groupId>org.apache.myfaces.portlet-bridge</groupId>
+ <artifactId>portlet-bridge-api</artifactId>
+ <version>1.0.0-alpha</version>
+ <scope>provided</scope>
+ </dependency>
+
+ <dependency>
<groupId>org.apache.myfaces.core</groupId>
<artifactId>myfaces-api</artifactId>
<version>${myfaces.version}</version>
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
==============================================================================
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
@@ -206,6 +206,11 @@
</dependency>
<dependency>
+ <groupId>org.apache.myfaces.portlet-bridge</groupId>
+ <artifactId>portlet-bridge-api</artifactId>
+ </dependency>
+
+ <dependency>
<groupId>org.apache.myfaces.trinidad</groupId>
<artifactId>trinidad-build</artifactId>
</dependency>
Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
==============================================================================
--- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
+++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@
import java.io.IOException;
+import javax.portlet.faces.annotation.PortletNamingContainer;
+import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
/**
* StateManager that handles a hybrid client/server strategy: a
* SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
+ //This code handles automatic namespacing in a JSR-301 environment
+ if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+ {
+ //To avoid introducing a runtime dependency on the bridge,
+ //this method should only be executed when we have a portlet
+ //request. If we do have a portlet request then the bridge
+ //should be available anyway.
+ newRoot = _getPortletRoot(newRoot);
+ }
+
+
// must call restoreState so that we setup attributes, listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@
return null;
}
+
+ /**
+ * This should only be executed if we are currently in a Portlet Request.
+ * If executed, this method introduces a dependency on the JSR-301 bridge
+ * which is required for Trinidad to run in a portal environment. If this
+ * method is not run, then the bridge api's remain optional at runtime.
+ *
+ * This method checks the current UIViewRoot to see if it is a
+ * PortletNamingContainer. If it is, then this class simply returns the
+ * UIViewRoot. If it does not then the current UIViewRoot is used to create
+ * a new PortletNamingContainerUIViewRoot.
+ */
+ private UIViewRoot _getPortletRoot(UIViewRoot root)
+ {
+ Class<? extends UIViewRoot> rootClass = root.getClass();
+ //If the current root is not the real UIViewRoot object in faces then
+ //is no need to escape it. It is assumed it handles namespacing on its
+ //own. This is the same as the logic in the JSR-301 Bridge spec.
+ if(rootClass == UIViewRoot.class)
+ {
+ _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
+ root = new PortletNamingContainerUIViewRoot(root);
+ }
+
+ //TODO: Do we need a warning here if the view root is not annotated
+ //properly? This could happen if another renderkit is involved and does
+ //not correctly implement JSR-301. This will NOT be an issue in Trin only
+ //environments.
+ return root;
+ }
+
}
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
Correction, this dependency is a "compile only" library, not a runtime
only library.
Scott O'Bryan wrote:
> The Apache MVN website says this about providing a "compile only"
> library:
>
> "The scope you should use for this is |provided|. This indicates to
> Maven that the dependency will be provided at run time by its
> container or the JDK, for example.
>
> "Dependencies with this scope will not be passed on transitively,
> nor will they be bundled in an package such as a WAR, or included in
> the runtime classpath.
>
> This library is a runtime only library and is only needed when running
> in the portlet environment. Currently Trinidad's demo's aren't
> portlet compatible. Until I'm able to do some of this work, I would
> much rather this API (and the subsequent impl) not be added to the demo.
>
> Scott
>
> Matthias Wessendorf wrote:
>> also...
>> doesn't this belong to the 12x trunk ?
>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>
>> -M
>>
>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>> <dependency>
>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>> + <version>1.0.0-alpha</version>
>>>> + <scope>provided</scope>
>>>> + </dependency>
>>>>
>>> I wonder fi is the right scope.
>>> Pretty much all containers don't really ship that JAR.
>>>
>>> -M
>>>
>>>
>>>
>>>
>>>> +
>>>> + <dependency>
>>>> <groupId>org.apache.myfaces.core</groupId>
>>>> <artifactId>myfaces-api</artifactId>
>>>> <version>${myfaces.version}</version>
>>>>
>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>> URL:
>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>
>>>> ==============================================================================
>>>>
>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>> 13:35:43 2008
>>>> @@ -206,6 +206,11 @@
>>>> </dependency>
>>>>
>>>> <dependency>
>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>> <artifactId>trinidad-build</artifactId>
>>>> </dependency>
>>>>
>>>> Modified:
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>
>>>> URL:
>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>
>>>> ==============================================================================
>>>>
>>>> ---
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>> (original)
>>>> +++
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>> Tue Feb 19 13:35:43 2008
>>>> @@ -51,6 +51,11 @@
>>>>
>>>> import java.io.IOException;
>>>>
>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>> +import
>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>> +
>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>> +
>>>> /**
>>>> * StateManager that handles a hybrid client/server strategy: a
>>>> * SerializedView is stored on the server, and only a small token
>>>> @@ -966,6 +971,17 @@
>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>
>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>
>>>> + //This code handles automatic namespacing in a JSR-301
>>>> environment
>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>> + {
>>>> + //To avoid introducing a runtime dependency on the bridge,
>>>> + //this method should only be executed when we have a
>>>> portlet
>>>> + //request. If we do have a portlet request then the bridge
>>>> + //should be available anyway.
>>>> + newRoot = _getPortletRoot(newRoot);
>>>> + }
>>>> +
>>>> +
>>>> // must call restoreState so that we setup attributes,
>>>> listeners,
>>>> // uniqueIds, etc ...
>>>> newRoot.restoreState(fc, viewRootState);
>>>> @@ -984,6 +1000,37 @@
>>>>
>>>> return null;
>>>> }
>>>> +
>>>> + /**
>>>> + * This should only be executed if we are currently in a
>>>> Portlet Request.
>>>> + * If executed, this method introduces a dependency on the
>>>> JSR-301 bridge
>>>> + * which is required for Trinidad to run in a portal
>>>> environment. If this
>>>> + * method is not run, then the bridge api's remain optional at
>>>> runtime.
>>>> + *
>>>> + * This method checks the current UIViewRoot to see if it is a
>>>> + * PortletNamingContainer. If it is, then this class simply
>>>> returns the
>>>> + * UIViewRoot. If it does not then the current UIViewRoot is
>>>> used to create
>>>> + * a new PortletNamingContainerUIViewRoot.
>>>> + */
>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>> + {
>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>> + //If the current root is not the real UIViewRoot object in
>>>> faces then
>>>> + //is no need to escape it. It is assumed it handles
>>>> namespacing on its
>>>> + //own. This is the same as the logic in the JSR-301 Bridge
>>>> spec.
>>>> + if(rootClass == UIViewRoot.class)
>>>> + {
>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>> portal.");
>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>> + }
>>>> +
>>>> + //TODO: Do we need a warning here if the view root is not
>>>> annotated
>>>> + //properly? This could happen if another renderkit is
>>>> involved and does
>>>> + //not correctly implement JSR-301. This will NOT be an
>>>> issue in Trin only
>>>> + //environments.
>>>> + return root;
>>>> + }
>>>> +
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> further stuff:
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> mail: matzew-at-apache-dot-org
>>>
>>>
>>
>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Feb 20, 2008 5:54 PM, Bernhard Huemer <be...@gmail.com> wrote:
> Hello,
>
> that's because there's a dependency to PortletNamingContainerUIViewRoot
> even if you're using this StateManager in a Servlet environment (due to
> the import). In order to overcome this issue Scott could introduce an
> additional indirection so that the class Portlet..UIViewRoot will only
> be loaded if Trinidad is running in the appropriate environment (for
> example by introducing a Jsr301StateManagerImpl ;-)).
yes... the dependency was introduced due to that,
that's why I sent the original "complain" :)
Scott is fixing that, as he said ;-)
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
>
> "Matthias Wessendorf" <ma...@apache.org> wrote:
> > Hi Scott,
> >
> > On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
> >> The Apache MVN website says this about providing a "compile only" library:
> >>
> >> "The scope you should use for this is |provided|. This indicates to
> >> Maven that the dependency will be provided at run time by its
> >> container or the JDK, for example.
> >>
> >> "Dependencies with this scope will not be passed on transitively,
> >> nor will they be bundled in an package such as a WAR, or included in
> >> the runtime classpath.
> >>
> >> This library is a runtime only library and is only needed when running
> >> in the portlet environment. Currently Trinidad's demo's aren't portlet
> >> compatible. Until I'm able to do some of this work, I would much rather
> >> this API (and the subsequent impl) not be added to the demo.
> >
> > I get a "java.lang.NoClassDefFoundError:
> > javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
> > running the demos...
> > (on 1.2.6.1 branch)
> > (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
> >
> > when I change the dependency (as suggested) to compile, after building
> > Trinidad again, all works fine.
> >
> > Also, the 301-fix is now here:
> > -1.0.x trunk
> > -1.2.6.1 branch
> >
> > not in 1.2_x trunk
> >
> > -Matthias
> >
> > -Matthias
> >
> >> Scott
> >>
> >>
> >> Matthias Wessendorf wrote:
> >>> also...
> >>> doesn't this belong to the 12x trunk ?
> >>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
> >>>
> >>> -M
> >>>
> >>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>> <dependency>
> >>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>>>> + <artifactId>portlet-bridge-api</artifactId>
> >>>>> + <version>1.0.0-alpha</version>
> >>>>> + <scope>provided</scope>
> >>>>> + </dependency>
> >>>>>
> >>>> I wonder fi is the right scope.
> >>>> Pretty much all containers don't really ship that JAR.
> >>>>
> >>>> -M
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> +
> >>>>> + <dependency>
> >>>>> <groupId>org.apache.myfaces.core</groupId>
> >>>>> <artifactId>myfaces-api</artifactId>
> >>>>> <version>${myfaces.version}</version>
> >>>>>
> >>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
> >>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
> >>>>> ==============================================================================
> >>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
> >>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
> >>>>> @@ -206,6 +206,11 @@
> >>>>> </dependency>
> >>>>>
> >>>>> <dependency>
> >>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>>>> + <artifactId>portlet-bridge-api</artifactId>
> >>>>> + </dependency>
> >>>>> +
> >>>>> + <dependency>
> >>>>> <groupId>org.apache.myfaces.trinidad</groupId>
> >>>>> <artifactId>trinidad-build</artifactId>
> >>>>> </dependency>
> >>>>>
> >>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> >>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
> >>>>> ==============================================================================
> >>>>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
> >>>>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
> >>>>> @@ -51,6 +51,11 @@
> >>>>>
> >>>>> import java.io.IOException;
> >>>>>
> >>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
> >>>>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
> >>>>> +
> >>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
> >>>>> +
> >>>>> /**
> >>>>> * StateManager that handles a hybrid client/server strategy: a
> >>>>> * SerializedView is stored on the server, and only a small token
> >>>>> @@ -966,6 +971,17 @@
> >>>>> UIViewRoot newRoot = (UIViewRoot)
> >>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
> >>>>>
> >>>>> + //This code handles automatic namespacing in a JSR-301 environment
> >>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
> >>>>> + {
> >>>>> + //To avoid introducing a runtime dependency on the bridge,
> >>>>> + //this method should only be executed when we have a portlet
> >>>>> + //request. If we do have a portlet request then the bridge
> >>>>> + //should be available anyway.
> >>>>> + newRoot = _getPortletRoot(newRoot);
> >>>>> + }
> >>>>> +
> >>>>> +
> >>>>> // must call restoreState so that we setup attributes, listeners,
> >>>>> // uniqueIds, etc ...
> >>>>> newRoot.restoreState(fc, viewRootState);
> >>>>> @@ -984,6 +1000,37 @@
> >>>>>
> >>>>> return null;
> >>>>> }
> >>>>> +
> >>>>> + /**
> >>>>> + * This should only be executed if we are currently in a Portlet Request.
> >>>>> + * If executed, this method introduces a dependency on the JSR-301 bridge
> >>>>> + * which is required for Trinidad to run in a portal environment. If this
> >>>>> + * method is not run, then the bridge api's remain optional at runtime.
> >>>>> + *
> >>>>> + * This method checks the current UIViewRoot to see if it is a
> >>>>> + * PortletNamingContainer. If it is, then this class simply returns the
> >>>>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
> >>>>> + * a new PortletNamingContainerUIViewRoot.
> >>>>> + */
> >>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
> >>>>> + {
> >>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
> >>>>> + //If the current root is not the real UIViewRoot object in faces then
> >>>>> + //is no need to escape it. It is assumed it handles namespacing on its
> >>>>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
> >>>>> + if(rootClass == UIViewRoot.class)
> >>>>> + {
> >>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
> >>>>> + root = new PortletNamingContainerUIViewRoot(root);
> >>>>> + }
> >>>>> +
> >>>>> + //TODO: Do we need a warning here if the view root is not annotated
> >>>>> + //properly? This could happen if another renderkit is involved and does
> >>>>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
> >>>>> + //environments.
> >>>>> + return root;
> >>>>> + }
> >>>>> +
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Matthias Wessendorf
> >>>>
> >>>> further stuff:
> >>>> blog: http://matthiaswessendorf.wordpress.com/
> >>>> sessions: http://www.slideshare.net/mwessendorf
> >>>> mail: matzew-at-apache-dot-org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
I'm fine with this "restriction" as I'm using the Apache Portal JSF
Bridge only in cases where I can't use the JSR 301 Bridge (due to the
JSF 1.2 dependency).
regards,
Bernhard
On 02/21/2008 +0100,
"Scott O'Bryan" <da...@gmail.com> wrote:
> Ok, I think I fixed it. Bernhard, you were right, it needed to be
> moved. ExternalContextUtils works because I use reflection to get the
> classes.. duh!
>
> Anyway I removed the checkin from trunk.
> Added the checking to trunk_1.2.x
> And modified the previous checkin to 1.2.6.1-branch
>
> I tested it with Jetty and everything works right. Insidently I had
> previously tested this in JDEV and it worked, Jetty failed. I can only
> assume it's because of differences with the class loader, so I'll make
> sure to add Jetty tests in the future.
>
> Bernhard, I'm assuming that this modification NOT being in trunk solves
> your needs as well, correct? Trinidad 1.1 portlets are not "officially
> supported" even though they should work with some hacks and
> workarounds. I'm thinking for 1.2, though, we really should enforce the
> standard bridge. Do you agree?
>
> Scott
>
> Bernhard Huemer wrote:
>> Hello,
>>
>>> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
>>> 99.99999% of the code is shared and only a private inner class
>>> contains the change. I'll figure something out.
>>
>> actually, I was just kidding but nevertheless noone said that the
>> Jsr301StateManagerImpl isn't allowed to inherit from the "plain"
>> StateManagerImpl.
>>
>>> That said, I'm not sure it's the import necessarily. But I'll trace
>>> though it to see what I've got. I know that the ExternalContextUtils
>>> has the imports on the portlet classes and it loads fine in a servlet
>>> only environment. I may have to get at the class using reflection or
>>> something to prevent it from preloading.
>>
>> Although I'm quite sure that the import statement causes this
>> behaviour, you're right, that it's not necessarily true. However, the
>> class definition somehow depends on PortletNamingUIViewRoot
>> _directly_. As I've already mentioned, you just have to introduce an
>> additional indirection to prevent preloading (for example by
>> introducing a Jsr301StateManagerUtils class - just don't use a nested
>> class).
>>
>> regards,
>> Bernhard
>>
>> On 02/20/2008 +0100,
>> "Scott O'Bryan" <da...@gmail.com> wrote:
>>> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
>>> 99.99999% of the code is shared and only a private inner class
>>> contains the change. I'll figure something out.
>>>
>>> That said, I'm not sure it's the import necessarily. But I'll trace
>>> though it to see what I've got. I know that the ExternalContextUtils
>>> has the imports on the portlet classes and it loads fine in a servlet
>>> only environment. I may have to get at the class using reflection or
>>> something to prevent it from preloading.
>>>
>>> Scott
>>>
>>> Bernhard Huemer wrote:
>>>> Hello,
>>>>
>>>> that's because there's a dependency to
>>>> PortletNamingContainerUIViewRoot even if you're using this
>>>> StateManager in a Servlet environment (due to the import). In order
>>>> to overcome this issue Scott could introduce an additional
>>>> indirection so that the class Portlet..UIViewRoot will only be
>>>> loaded if Trinidad is running in the appropriate environment (for
>>>> example by introducing a Jsr301StateManagerImpl ;-)).
>>>>
>>>> regards,
>>>> Bernhard
>>>>
>>>> On 02/20/2008 +0100,
>>>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>>>> Hi Scott,
>>>>>
>>>>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>>>>>> The Apache MVN website says this about providing a "compile only"
>>>>>> library:
>>>>>>
>>>>>> "The scope you should use for this is |provided|. This
>>>>>> indicates to
>>>>>> Maven that the dependency will be provided at run time by its
>>>>>> container or the JDK, for example.
>>>>>>
>>>>>> "Dependencies with this scope will not be passed on transitively,
>>>>>> nor will they be bundled in an package such as a WAR, or
>>>>>> included in
>>>>>> the runtime classpath.
>>>>>>
>>>>>> This library is a runtime only library and is only needed when
>>>>>> running
>>>>>> in the portlet environment. Currently Trinidad's demo's aren't
>>>>>> portlet
>>>>>> compatible. Until I'm able to do some of this work, I would much
>>>>>> rather
>>>>>> this API (and the subsequent impl) not be added to the demo.
>>>>>
>>>>> I get a "java.lang.NoClassDefFoundError:
>>>>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
>>>>> running the demos...
>>>>> (on 1.2.6.1 branch)
>>>>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>>>>>
>>>>> when I change the dependency (as suggested) to compile, after building
>>>>> Trinidad again, all works fine.
>>>>>
>>>>> Also, the 301-fix is now here:
>>>>> -1.0.x trunk
>>>>> -1.2.6.1 branch
>>>>>
>>>>> not in 1.2_x trunk
>>>>>
>>>>> -Matthias
>>>>>
>>>>> -Matthias
>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> Matthias Wessendorf wrote:
>>>>>>> also...
>>>>>>> doesn't this belong to the 12x trunk ?
>>>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>>>>
>>>>>>> -M
>>>>>>>
>>>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>> <dependency>
>>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>>> + <version>1.0.0-alpha</version>
>>>>>>>>> + <scope>provided</scope>
>>>>>>>>> + </dependency>
>>>>>>>>>
>>>>>>>> I wonder fi is the right scope.
>>>>>>>> Pretty much all containers don't really ship that JAR.
>>>>>>>>
>>>>>>>> -M
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> + <dependency>
>>>>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>>>>> <version>${myfaces.version}</version>
>>>>>>>>>
>>>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>>>>> URL:
>>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>>
>>>>>>>>> ==============================================================================
>>>>>>>>>
>>>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>>>>> 13:35:43 2008
>>>>>>>>> @@ -206,6 +206,11 @@
>>>>>>>>> </dependency>
>>>>>>>>>
>>>>>>>>> <dependency>
>>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>>> + </dependency>
>>>>>>>>> +
>>>>>>>>> + <dependency>
>>>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>>>>> </dependency>
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>>>
>>>>>>>>> URL:
>>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>>
>>>>>>>>> ==============================================================================
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>>> (original)
>>>>>>>>> +++
>>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>>> Tue Feb 19 13:35:43 2008
>>>>>>>>> @@ -51,6 +51,11 @@
>>>>>>>>>
>>>>>>>>> import java.io.IOException;
>>>>>>>>>
>>>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>>>>> +import
>>>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>>>>> +
>>>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>>>>> +
>>>>>>>>> /**
>>>>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>>>>> @@ -966,6 +971,17 @@
>>>>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>>>>
>>>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>>>>
>>>>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>>>>> environment
>>>>>>>>> +
>>>>>>>>> if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>>>>> + {
>>>>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>>>>> bridge,
>>>>>>>>> + //this method should only be executed when we have a
>>>>>>>>> portlet
>>>>>>>>> + //request. If we do have a portlet request then the
>>>>>>>>> bridge
>>>>>>>>> + //should be available anyway.
>>>>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> +
>>>>>>>>> // must call restoreState so that we setup attributes,
>>>>>>>>> listeners,
>>>>>>>>> // uniqueIds, etc ...
>>>>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>>>>> @@ -984,6 +1000,37 @@
>>>>>>>>>
>>>>>>>>> return null;
>>>>>>>>> }
>>>>>>>>> +
>>>>>>>>> + /**
>>>>>>>>> + * This should only be executed if we are currently in a
>>>>>>>>> Portlet Request.
>>>>>>>>> + * If executed, this method introduces a dependency on the
>>>>>>>>> JSR-301 bridge
>>>>>>>>> + * which is required for Trinidad to run in a portal
>>>>>>>>> environment. If this
>>>>>>>>> + * method is not run, then the bridge api's remain
>>>>>>>>> optional at runtime.
>>>>>>>>> + *
>>>>>>>>> + * This method checks the current UIViewRoot to see if it
>>>>>>>>> is a
>>>>>>>>> + * PortletNamingContainer. If it is, then this class
>>>>>>>>> simply returns the
>>>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>>>>> is used to create
>>>>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>>>>> + */
>>>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>>>>> + {
>>>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>>>>> + //If the current root is not the real UIViewRoot object
>>>>>>>>> in faces then
>>>>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>>>>> namespacing on its
>>>>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>>>>> Bridge spec.
>>>>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>>>>> + {
>>>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>>>>> portal.");
>>>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> + //TODO: Do we need a warning here if the view root is
>>>>>>>>> not annotated
>>>>>>>>> + //properly? This could happen if another renderkit is
>>>>>>>>> involved and does
>>>>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>>>>> issue in Trin only
>>>>>>>>> + //environments.
>>>>>>>>> + return root;
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Matthias Wessendorf
>>>>>>>>
>>>>>>>> further stuff:
>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>> mail: matzew-at-apache-dot-org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Matthias Wessendorf <ma...@apache.org>.
thank!
and yes, jetty is a damn cool container ;-)
-Matthias
On Thu, Feb 21, 2008 at 3:13 AM, Scott O'Bryan <da...@gmail.com> wrote:
> Ok, I think I fixed it. Bernhard, you were right, it needed to be
> moved. ExternalContextUtils works because I use reflection to get the
> classes.. duh!
>
> Anyway I removed the checkin from trunk.
> Added the checking to trunk_1.2.x
> And modified the previous checkin to 1.2.6.1-branch
>
> I tested it with Jetty and everything works right. Insidently I had
> previously tested this in JDEV and it worked, Jetty failed. I can only
> assume it's because of differences with the class loader, so I'll make
> sure to add Jetty tests in the future.
>
> Bernhard, I'm assuming that this modification NOT being in trunk solves
> your needs as well, correct? Trinidad 1.1 portlets are not "officially
> supported" even though they should work with some hacks and
> workarounds. I'm thinking for 1.2, though, we really should enforce the
> standard bridge. Do you agree?
>
>
>
> Scott
>
> Bernhard Huemer wrote:
> > Hello,
> >
> >> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
> >> 99.99999% of the code is shared and only a private inner class
> >> contains the change. I'll figure something out.
> >
> > actually, I was just kidding but nevertheless noone said that the
> > Jsr301StateManagerImpl isn't allowed to inherit from the "plain"
> > StateManagerImpl.
> >
> >> That said, I'm not sure it's the import necessarily. But I'll trace
> >> though it to see what I've got. I know that the ExternalContextUtils
> >> has the imports on the portlet classes and it loads fine in a servlet
> >> only environment. I may have to get at the class using reflection or
> >> something to prevent it from preloading.
> >
> > Although I'm quite sure that the import statement causes this
> > behaviour, you're right, that it's not necessarily true. However, the
> > class definition somehow depends on PortletNamingUIViewRoot
> > _directly_. As I've already mentioned, you just have to introduce an
> > additional indirection to prevent preloading (for example by
> > introducing a Jsr301StateManagerUtils class - just don't use a nested
> > class).
> >
> > regards,
> > Bernhard
> >
> > On 02/20/2008 +0100,
> > "Scott O'Bryan" <da...@gmail.com> wrote:
> >> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
> >> 99.99999% of the code is shared and only a private inner class
> >> contains the change. I'll figure something out.
> >>
> >> That said, I'm not sure it's the import necessarily. But I'll trace
> >> though it to see what I've got. I know that the ExternalContextUtils
> >> has the imports on the portlet classes and it loads fine in a servlet
> >> only environment. I may have to get at the class using reflection or
> >> something to prevent it from preloading.
> >>
> >> Scott
> >>
> >> Bernhard Huemer wrote:
> >>> Hello,
> >>>
> >>> that's because there's a dependency to
> >>> PortletNamingContainerUIViewRoot even if you're using this
> >>> StateManager in a Servlet environment (due to the import). In order
> >>> to overcome this issue Scott could introduce an additional
> >>> indirection so that the class Portlet..UIViewRoot will only be
> >>> loaded if Trinidad is running in the appropriate environment (for
> >>> example by introducing a Jsr301StateManagerImpl ;-)).
> >>>
> >>> regards,
> >>> Bernhard
> >>>
> >>> On 02/20/2008 +0100,
> >>> "Matthias Wessendorf" <ma...@apache.org> wrote:
> >>>> Hi Scott,
> >>>>
> >>>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
> >>>>> The Apache MVN website says this about providing a "compile only"
> >>>>> library:
> >>>>>
> >>>>> "The scope you should use for this is |provided|. This
> >>>>> indicates to
> >>>>> Maven that the dependency will be provided at run time by its
> >>>>> container or the JDK, for example.
> >>>>>
> >>>>> "Dependencies with this scope will not be passed on transitively,
> >>>>> nor will they be bundled in an package such as a WAR, or
> >>>>> included in
> >>>>> the runtime classpath.
> >>>>>
> >>>>> This library is a runtime only library and is only needed when
> >>>>> running
> >>>>> in the portlet environment. Currently Trinidad's demo's aren't
> >>>>> portlet
> >>>>> compatible. Until I'm able to do some of this work, I would much
> >>>>> rather
> >>>>> this API (and the subsequent impl) not be added to the demo.
> >>>>
> >>>> I get a "java.lang.NoClassDefFoundError:
> >>>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
> >>>> running the demos...
> >>>> (on 1.2.6.1 branch)
> >>>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
> >>>>
> >>>> when I change the dependency (as suggested) to compile, after building
> >>>> Trinidad again, all works fine.
> >>>>
> >>>> Also, the 301-fix is now here:
> >>>> -1.0.x trunk
> >>>> -1.2.6.1 branch
> >>>>
> >>>> not in 1.2_x trunk
> >>>>
> >>>> -Matthias
> >>>>
> >>>> -Matthias
> >>>>
> >>>>> Scott
> >>>>>
> >>>>>
> >>>>> Matthias Wessendorf wrote:
> >>>>>> also...
> >>>>>> doesn't this belong to the 12x trunk ?
> >>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
> >>>>>>
> >>>>>> -M
> >>>>>>
> >>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>
> >>>>>>>> <dependency>
> >>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
> >>>>>>>> + <version>1.0.0-alpha</version>
> >>>>>>>> + <scope>provided</scope>
> >>>>>>>> + </dependency>
> >>>>>>>>
> >>>>>>> I wonder fi is the right scope.
> >>>>>>> Pretty much all containers don't really ship that JAR.
> >>>>>>>
> >>>>>>> -M
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> +
> >>>>>>>> + <dependency>
> >>>>>>>> <groupId>org.apache.myfaces.core</groupId>
> >>>>>>>> <artifactId>myfaces-api</artifactId>
> >>>>>>>> <version>${myfaces.version}</version>
> >>>>>>>>
> >>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
> >>>>>>>> URL:
> >>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
> >>>>>>>>
> >>>>>>>> ==============================================================================
> >>>>>>>>
> >>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
> >>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
> >>>>>>>> 13:35:43 2008
> >>>>>>>> @@ -206,6 +206,11 @@
> >>>>>>>> </dependency>
> >>>>>>>>
> >>>>>>>> <dependency>
> >>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
> >>>>>>>> + </dependency>
> >>>>>>>> +
> >>>>>>>> + <dependency>
> >>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
> >>>>>>>> <artifactId>trinidad-build</artifactId>
> >>>>>>>> </dependency>
> >>>>>>>>
> >>>>>>>> Modified:
> >>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> >>>>>>>>
> >>>>>>>> URL:
> >>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
> >>>>>>>>
> >>>>>>>> ==============================================================================
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> >>>>>>>> (original)
> >>>>>>>> +++
> >>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> >>>>>>>> Tue Feb 19 13:35:43 2008
> >>>>>>>> @@ -51,6 +51,11 @@
> >>>>>>>>
> >>>>>>>> import java.io.IOException;
> >>>>>>>>
> >>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
> >>>>>>>> +import
> >>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
> >>>>>>>> +
> >>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
> >>>>>>>> +
> >>>>>>>> /**
> >>>>>>>> * StateManager that handles a hybrid client/server strategy: a
> >>>>>>>> * SerializedView is stored on the server, and only a small token
> >>>>>>>> @@ -966,6 +971,17 @@
> >>>>>>>> UIViewRoot newRoot = (UIViewRoot)
> >>>>>>>>
> >>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
> >>>>>>>>
> >>>>>>>> + //This code handles automatic namespacing in a JSR-301
> >>>>>>>> environment
> >>>>>>>> +
> >>>>>>>> if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
> >>>>>>>> + {
> >>>>>>>> + //To avoid introducing a runtime dependency on the
> >>>>>>>> bridge,
> >>>>>>>> + //this method should only be executed when we have a
> >>>>>>>> portlet
> >>>>>>>> + //request. If we do have a portlet request then the
> >>>>>>>> bridge
> >>>>>>>> + //should be available anyway.
> >>>>>>>> + newRoot = _getPortletRoot(newRoot);
> >>>>>>>> + }
> >>>>>>>> +
> >>>>>>>> +
> >>>>>>>> // must call restoreState so that we setup attributes,
> >>>>>>>> listeners,
> >>>>>>>> // uniqueIds, etc ...
> >>>>>>>> newRoot.restoreState(fc, viewRootState);
> >>>>>>>> @@ -984,6 +1000,37 @@
> >>>>>>>>
> >>>>>>>> return null;
> >>>>>>>> }
> >>>>>>>> +
> >>>>>>>> + /**
> >>>>>>>> + * This should only be executed if we are currently in a
> >>>>>>>> Portlet Request.
> >>>>>>>> + * If executed, this method introduces a dependency on the
> >>>>>>>> JSR-301 bridge
> >>>>>>>> + * which is required for Trinidad to run in a portal
> >>>>>>>> environment. If this
> >>>>>>>> + * method is not run, then the bridge api's remain
> >>>>>>>> optional at runtime.
> >>>>>>>> + *
> >>>>>>>> + * This method checks the current UIViewRoot to see if it
> >>>>>>>> is a
> >>>>>>>> + * PortletNamingContainer. If it is, then this class
> >>>>>>>> simply returns the
> >>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
> >>>>>>>> is used to create
> >>>>>>>> + * a new PortletNamingContainerUIViewRoot.
> >>>>>>>> + */
> >>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
> >>>>>>>> + {
> >>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
> >>>>>>>> + //If the current root is not the real UIViewRoot object
> >>>>>>>> in faces then
> >>>>>>>> + //is no need to escape it. It is assumed it handles
> >>>>>>>> namespacing on its
> >>>>>>>> + //own. This is the same as the logic in the JSR-301
> >>>>>>>> Bridge spec.
> >>>>>>>> + if(rootClass == UIViewRoot.class)
> >>>>>>>> + {
> >>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
> >>>>>>>> portal.");
> >>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
> >>>>>>>> + }
> >>>>>>>> +
> >>>>>>>> + //TODO: Do we need a warning here if the view root is
> >>>>>>>> not annotated
> >>>>>>>> + //properly? This could happen if another renderkit is
> >>>>>>>> involved and does
> >>>>>>>> + //not correctly implement JSR-301. This will NOT be an
> >>>>>>>> issue in Trin only
> >>>>>>>> + //environments.
> >>>>>>>> + return root;
> >>>>>>>> + }
> >>>>>>>> +
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> --
> >>>>>>> Matthias Wessendorf
> >>>>>>>
> >>>>>>> further stuff:
> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/
> >>>>>>> sessions: http://www.slideshare.net/mwessendorf
> >>>>>>> mail: matzew-at-apache-dot-org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
Ok, I think I fixed it. Bernhard, you were right, it needed to be
moved. ExternalContextUtils works because I use reflection to get the
classes.. duh!
Anyway I removed the checkin from trunk.
Added the checking to trunk_1.2.x
And modified the previous checkin to 1.2.6.1-branch
I tested it with Jetty and everything works right. Insidently I had
previously tested this in JDEV and it worked, Jetty failed. I can only
assume it's because of differences with the class loader, so I'll make
sure to add Jetty tests in the future.
Bernhard, I'm assuming that this modification NOT being in trunk solves
your needs as well, correct? Trinidad 1.1 portlets are not "officially
supported" even though they should work with some hacks and
workarounds. I'm thinking for 1.2, though, we really should enforce the
standard bridge. Do you agree?
Scott
Bernhard Huemer wrote:
> Hello,
>
>> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
>> 99.99999% of the code is shared and only a private inner class
>> contains the change. I'll figure something out.
>
> actually, I was just kidding but nevertheless noone said that the
> Jsr301StateManagerImpl isn't allowed to inherit from the "plain"
> StateManagerImpl.
>
>> That said, I'm not sure it's the import necessarily. But I'll trace
>> though it to see what I've got. I know that the ExternalContextUtils
>> has the imports on the portlet classes and it loads fine in a servlet
>> only environment. I may have to get at the class using reflection or
>> something to prevent it from preloading.
>
> Although I'm quite sure that the import statement causes this
> behaviour, you're right, that it's not necessarily true. However, the
> class definition somehow depends on PortletNamingUIViewRoot
> _directly_. As I've already mentioned, you just have to introduce an
> additional indirection to prevent preloading (for example by
> introducing a Jsr301StateManagerUtils class - just don't use a nested
> class).
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
> "Scott O'Bryan" <da...@gmail.com> wrote:
>> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
>> 99.99999% of the code is shared and only a private inner class
>> contains the change. I'll figure something out.
>>
>> That said, I'm not sure it's the import necessarily. But I'll trace
>> though it to see what I've got. I know that the ExternalContextUtils
>> has the imports on the portlet classes and it loads fine in a servlet
>> only environment. I may have to get at the class using reflection or
>> something to prevent it from preloading.
>>
>> Scott
>>
>> Bernhard Huemer wrote:
>>> Hello,
>>>
>>> that's because there's a dependency to
>>> PortletNamingContainerUIViewRoot even if you're using this
>>> StateManager in a Servlet environment (due to the import). In order
>>> to overcome this issue Scott could introduce an additional
>>> indirection so that the class Portlet..UIViewRoot will only be
>>> loaded if Trinidad is running in the appropriate environment (for
>>> example by introducing a Jsr301StateManagerImpl ;-)).
>>>
>>> regards,
>>> Bernhard
>>>
>>> On 02/20/2008 +0100,
>>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>>> Hi Scott,
>>>>
>>>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>>>>> The Apache MVN website says this about providing a "compile only"
>>>>> library:
>>>>>
>>>>> "The scope you should use for this is |provided|. This
>>>>> indicates to
>>>>> Maven that the dependency will be provided at run time by its
>>>>> container or the JDK, for example.
>>>>>
>>>>> "Dependencies with this scope will not be passed on transitively,
>>>>> nor will they be bundled in an package such as a WAR, or
>>>>> included in
>>>>> the runtime classpath.
>>>>>
>>>>> This library is a runtime only library and is only needed when
>>>>> running
>>>>> in the portlet environment. Currently Trinidad's demo's aren't
>>>>> portlet
>>>>> compatible. Until I'm able to do some of this work, I would much
>>>>> rather
>>>>> this API (and the subsequent impl) not be added to the demo.
>>>>
>>>> I get a "java.lang.NoClassDefFoundError:
>>>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
>>>> running the demos...
>>>> (on 1.2.6.1 branch)
>>>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>>>>
>>>> when I change the dependency (as suggested) to compile, after building
>>>> Trinidad again, all works fine.
>>>>
>>>> Also, the 301-fix is now here:
>>>> -1.0.x trunk
>>>> -1.2.6.1 branch
>>>>
>>>> not in 1.2_x trunk
>>>>
>>>> -Matthias
>>>>
>>>> -Matthias
>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> Matthias Wessendorf wrote:
>>>>>> also...
>>>>>> doesn't this belong to the 12x trunk ?
>>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>>>
>>>>>> -M
>>>>>>
>>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>> + <version>1.0.0-alpha</version>
>>>>>>>> + <scope>provided</scope>
>>>>>>>> + </dependency>
>>>>>>>>
>>>>>>> I wonder fi is the right scope.
>>>>>>> Pretty much all containers don't really ship that JAR.
>>>>>>>
>>>>>>> -M
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> + <dependency>
>>>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>>>> <version>${myfaces.version}</version>
>>>>>>>>
>>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>>>> URL:
>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>
>>>>>>>> ==============================================================================
>>>>>>>>
>>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>>>> 13:35:43 2008
>>>>>>>> @@ -206,6 +206,11 @@
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>> + </dependency>
>>>>>>>> +
>>>>>>>> + <dependency>
>>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>> Modified:
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>>
>>>>>>>> URL:
>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>
>>>>>>>> ==============================================================================
>>>>>>>>
>>>>>>>> ---
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>> (original)
>>>>>>>> +++
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>> Tue Feb 19 13:35:43 2008
>>>>>>>> @@ -51,6 +51,11 @@
>>>>>>>>
>>>>>>>> import java.io.IOException;
>>>>>>>>
>>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>>>> +import
>>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>>>> +
>>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>>>> +
>>>>>>>> /**
>>>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>>>> @@ -966,6 +971,17 @@
>>>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>>>
>>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>>>
>>>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>>>> environment
>>>>>>>> +
>>>>>>>> if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>>>> + {
>>>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>>>> bridge,
>>>>>>>> + //this method should only be executed when we have a
>>>>>>>> portlet
>>>>>>>> + //request. If we do have a portlet request then the
>>>>>>>> bridge
>>>>>>>> + //should be available anyway.
>>>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> +
>>>>>>>> // must call restoreState so that we setup attributes,
>>>>>>>> listeners,
>>>>>>>> // uniqueIds, etc ...
>>>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>>>> @@ -984,6 +1000,37 @@
>>>>>>>>
>>>>>>>> return null;
>>>>>>>> }
>>>>>>>> +
>>>>>>>> + /**
>>>>>>>> + * This should only be executed if we are currently in a
>>>>>>>> Portlet Request.
>>>>>>>> + * If executed, this method introduces a dependency on the
>>>>>>>> JSR-301 bridge
>>>>>>>> + * which is required for Trinidad to run in a portal
>>>>>>>> environment. If this
>>>>>>>> + * method is not run, then the bridge api's remain
>>>>>>>> optional at runtime.
>>>>>>>> + *
>>>>>>>> + * This method checks the current UIViewRoot to see if it
>>>>>>>> is a
>>>>>>>> + * PortletNamingContainer. If it is, then this class
>>>>>>>> simply returns the
>>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>>>> is used to create
>>>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>>>> + */
>>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>>>> + {
>>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>>>> + //If the current root is not the real UIViewRoot object
>>>>>>>> in faces then
>>>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>>>> namespacing on its
>>>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>>>> Bridge spec.
>>>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>>>> + {
>>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>>>> portal.");
>>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + //TODO: Do we need a warning here if the view root is
>>>>>>>> not annotated
>>>>>>>> + //properly? This could happen if another renderkit is
>>>>>>>> involved and does
>>>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>>>> issue in Trin only
>>>>>>>> + //environments.
>>>>>>>> + return root;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> further stuff:
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> mail: matzew-at-apache-dot-org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
> 99.99999% of the code is shared and only a private inner class contains
> the change. I'll figure something out.
actually, I was just kidding but nevertheless noone said that the
Jsr301StateManagerImpl isn't allowed to inherit from the "plain"
StateManagerImpl.
> That said, I'm not sure it's the import necessarily. But I'll trace
> though it to see what I've got. I know that the ExternalContextUtils
> has the imports on the portlet classes and it loads fine in a servlet
> only environment. I may have to get at the class using reflection or
> something to prevent it from preloading.
Although I'm quite sure that the import statement causes this behaviour,
you're right, that it's not necessarily true. However, the class
definition somehow depends on PortletNamingUIViewRoot _directly_. As
I've already mentioned, you just have to introduce an additional
indirection to prevent preloading (for example by introducing a
Jsr301StateManagerUtils class - just don't use a nested class).
regards,
Bernhard
On 02/20/2008 +0100,
"Scott O'Bryan" <da...@gmail.com> wrote:
> LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
> 99.99999% of the code is shared and only a private inner class contains
> the change. I'll figure something out.
>
> That said, I'm not sure it's the import necessarily. But I'll trace
> though it to see what I've got. I know that the ExternalContextUtils
> has the imports on the portlet classes and it loads fine in a servlet
> only environment. I may have to get at the class using reflection or
> something to prevent it from preloading.
>
> Scott
>
> Bernhard Huemer wrote:
>> Hello,
>>
>> that's because there's a dependency to
>> PortletNamingContainerUIViewRoot even if you're using this
>> StateManager in a Servlet environment (due to the import). In order to
>> overcome this issue Scott could introduce an additional indirection so
>> that the class Portlet..UIViewRoot will only be loaded if Trinidad is
>> running in the appropriate environment (for example by introducing a
>> Jsr301StateManagerImpl ;-)).
>>
>> regards,
>> Bernhard
>>
>> On 02/20/2008 +0100,
>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>> Hi Scott,
>>>
>>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>>>> The Apache MVN website says this about providing a "compile only"
>>>> library:
>>>>
>>>> "The scope you should use for this is |provided|. This indicates to
>>>> Maven that the dependency will be provided at run time by its
>>>> container or the JDK, for example.
>>>>
>>>> "Dependencies with this scope will not be passed on transitively,
>>>> nor will they be bundled in an package such as a WAR, or
>>>> included in
>>>> the runtime classpath.
>>>>
>>>> This library is a runtime only library and is only needed when running
>>>> in the portlet environment. Currently Trinidad's demo's aren't portlet
>>>> compatible. Until I'm able to do some of this work, I would much
>>>> rather
>>>> this API (and the subsequent impl) not be added to the demo.
>>>
>>> I get a "java.lang.NoClassDefFoundError:
>>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
>>> running the demos...
>>> (on 1.2.6.1 branch)
>>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>>>
>>> when I change the dependency (as suggested) to compile, after building
>>> Trinidad again, all works fine.
>>>
>>> Also, the 301-fix is now here:
>>> -1.0.x trunk
>>> -1.2.6.1 branch
>>>
>>> not in 1.2_x trunk
>>>
>>> -Matthias
>>>
>>> -Matthias
>>>
>>>> Scott
>>>>
>>>>
>>>> Matthias Wessendorf wrote:
>>>>> also...
>>>>> doesn't this belong to the 12x trunk ?
>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>>
>>>>> -M
>>>>>
>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>> <dependency>
>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>> + <version>1.0.0-alpha</version>
>>>>>>> + <scope>provided</scope>
>>>>>>> + </dependency>
>>>>>>>
>>>>>> I wonder fi is the right scope.
>>>>>> Pretty much all containers don't really ship that JAR.
>>>>>>
>>>>>> -M
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> + <dependency>
>>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>>> <version>${myfaces.version}</version>
>>>>>>>
>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>>> URL:
>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>>> 13:35:43 2008
>>>>>>> @@ -206,6 +206,11 @@
>>>>>>> </dependency>
>>>>>>>
>>>>>>> <dependency>
>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>> + </dependency>
>>>>>>> +
>>>>>>> + <dependency>
>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>>> </dependency>
>>>>>>>
>>>>>>> Modified:
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>
>>>>>>> URL:
>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>> ---
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>> (original)
>>>>>>> +++
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>> Tue Feb 19 13:35:43 2008
>>>>>>> @@ -51,6 +51,11 @@
>>>>>>>
>>>>>>> import java.io.IOException;
>>>>>>>
>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>>> +import
>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>>> +
>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>>> +
>>>>>>> /**
>>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>>> @@ -966,6 +971,17 @@
>>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>>
>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>>
>>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>>> environment
>>>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>>> + {
>>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>>> bridge,
>>>>>>> + //this method should only be executed when we have a
>>>>>>> portlet
>>>>>>> + //request. If we do have a portlet request then the
>>>>>>> bridge
>>>>>>> + //should be available anyway.
>>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>>> + }
>>>>>>> +
>>>>>>> +
>>>>>>> // must call restoreState so that we setup attributes,
>>>>>>> listeners,
>>>>>>> // uniqueIds, etc ...
>>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>>> @@ -984,6 +1000,37 @@
>>>>>>>
>>>>>>> return null;
>>>>>>> }
>>>>>>> +
>>>>>>> + /**
>>>>>>> + * This should only be executed if we are currently in a
>>>>>>> Portlet Request.
>>>>>>> + * If executed, this method introduces a dependency on the
>>>>>>> JSR-301 bridge
>>>>>>> + * which is required for Trinidad to run in a portal
>>>>>>> environment. If this
>>>>>>> + * method is not run, then the bridge api's remain optional
>>>>>>> at runtime.
>>>>>>> + *
>>>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>>>> returns the
>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>>> is used to create
>>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>>> + */
>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>>> + {
>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>>> + //If the current root is not the real UIViewRoot object in
>>>>>>> faces then
>>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>>> namespacing on its
>>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>>> Bridge spec.
>>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>>> + {
>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>>> portal.");
>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>>> + }
>>>>>>> +
>>>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>>>> annotated
>>>>>>> + //properly? This could happen if another renderkit is
>>>>>>> involved and does
>>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>>> issue in Trin only
>>>>>>> + //environments.
>>>>>>> + return root;
>>>>>>> + }
>>>>>>> +
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> further stuff:
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> mail: matzew-at-apache-dot-org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
99.99999% of the code is shared and only a private inner class contains
the change. I'll figure something out.
That said, I'm not sure it's the import necessarily. But I'll trace
though it to see what I've got. I know that the ExternalContextUtils
has the imports on the portlet classes and it loads fine in a servlet
only environment. I may have to get at the class using reflection or
something to prevent it from preloading.
Scott
Bernhard Huemer wrote:
> Hello,
>
> that's because there's a dependency to
> PortletNamingContainerUIViewRoot even if you're using this
> StateManager in a Servlet environment (due to the import). In order to
> overcome this issue Scott could introduce an additional indirection so
> that the class Portlet..UIViewRoot will only be loaded if Trinidad is
> running in the appropriate environment (for example by introducing a
> Jsr301StateManagerImpl ;-)).
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
> "Matthias Wessendorf" <ma...@apache.org> wrote:
>> Hi Scott,
>>
>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>>> The Apache MVN website says this about providing a "compile only"
>>> library:
>>>
>>> "The scope you should use for this is |provided|. This indicates to
>>> Maven that the dependency will be provided at run time by its
>>> container or the JDK, for example.
>>>
>>> "Dependencies with this scope will not be passed on transitively,
>>> nor will they be bundled in an package such as a WAR, or
>>> included in
>>> the runtime classpath.
>>>
>>> This library is a runtime only library and is only needed when running
>>> in the portlet environment. Currently Trinidad's demo's aren't portlet
>>> compatible. Until I'm able to do some of this work, I would much
>>> rather
>>> this API (and the subsequent impl) not be added to the demo.
>>
>> I get a "java.lang.NoClassDefFoundError:
>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
>> running the demos...
>> (on 1.2.6.1 branch)
>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>>
>> when I change the dependency (as suggested) to compile, after building
>> Trinidad again, all works fine.
>>
>> Also, the 301-fix is now here:
>> -1.0.x trunk
>> -1.2.6.1 branch
>>
>> not in 1.2_x trunk
>>
>> -Matthias
>>
>> -Matthias
>>
>>> Scott
>>>
>>>
>>> Matthias Wessendorf wrote:
>>>> also...
>>>> doesn't this belong to the 12x trunk ?
>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>
>>>> -M
>>>>
>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + <version>1.0.0-alpha</version>
>>>>>> + <scope>provided</scope>
>>>>>> + </dependency>
>>>>>>
>>>>> I wonder fi is the right scope.
>>>>> Pretty much all containers don't really ship that JAR.
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>> <version>${myfaces.version}</version>
>>>>>>
>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>> 13:35:43 2008
>>>>>> @@ -206,6 +206,11 @@
>>>>>> </dependency>
>>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>> </dependency>
>>>>>>
>>>>>> Modified:
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> ---
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> (original)
>>>>>> +++
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> Tue Feb 19 13:35:43 2008
>>>>>> @@ -51,6 +51,11 @@
>>>>>>
>>>>>> import java.io.IOException;
>>>>>>
>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>> +import
>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>> +
>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>> +
>>>>>> /**
>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>> @@ -966,6 +971,17 @@
>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>
>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>
>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>> environment
>>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>> + {
>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>> bridge,
>>>>>> + //this method should only be executed when we have a
>>>>>> portlet
>>>>>> + //request. If we do have a portlet request then the
>>>>>> bridge
>>>>>> + //should be available anyway.
>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>> + }
>>>>>> +
>>>>>> +
>>>>>> // must call restoreState so that we setup attributes,
>>>>>> listeners,
>>>>>> // uniqueIds, etc ...
>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>> @@ -984,6 +1000,37 @@
>>>>>>
>>>>>> return null;
>>>>>> }
>>>>>> +
>>>>>> + /**
>>>>>> + * This should only be executed if we are currently in a
>>>>>> Portlet Request.
>>>>>> + * If executed, this method introduces a dependency on the
>>>>>> JSR-301 bridge
>>>>>> + * which is required for Trinidad to run in a portal
>>>>>> environment. If this
>>>>>> + * method is not run, then the bridge api's remain optional
>>>>>> at runtime.
>>>>>> + *
>>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>>> returns the
>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>> is used to create
>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>> + */
>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>> + {
>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>> + //If the current root is not the real UIViewRoot object in
>>>>>> faces then
>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>> namespacing on its
>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>> Bridge spec.
>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>> + {
>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>> portal.");
>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>> + }
>>>>>> +
>>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>>> annotated
>>>>>> + //properly? This could happen if another renderkit is
>>>>>> involved and does
>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>> issue in Trin only
>>>>>> + //environments.
>>>>>> + return root;
>>>>>> + }
>>>>>> +
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> further stuff:
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> mail: matzew-at-apache-dot-org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
that's because there's a dependency to PortletNamingContainerUIViewRoot
even if you're using this StateManager in a Servlet environment (due to
the import). In order to overcome this issue Scott could introduce an
additional indirection so that the class Portlet..UIViewRoot will only
be loaded if Trinidad is running in the appropriate environment (for
example by introducing a Jsr301StateManagerImpl ;-)).
regards,
Bernhard
On 02/20/2008 +0100,
"Matthias Wessendorf" <ma...@apache.org> wrote:
> Hi Scott,
>
> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>> The Apache MVN website says this about providing a "compile only" library:
>>
>> "The scope you should use for this is |provided|. This indicates to
>> Maven that the dependency will be provided at run time by its
>> container or the JDK, for example.
>>
>> "Dependencies with this scope will not be passed on transitively,
>> nor will they be bundled in an package such as a WAR, or included in
>> the runtime classpath.
>>
>> This library is a runtime only library and is only needed when running
>> in the portlet environment. Currently Trinidad's demo's aren't portlet
>> compatible. Until I'm able to do some of this work, I would much rather
>> this API (and the subsequent impl) not be added to the demo.
>
> I get a "java.lang.NoClassDefFoundError:
> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
> running the demos...
> (on 1.2.6.1 branch)
> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>
> when I change the dependency (as suggested) to compile, after building
> Trinidad again, all works fine.
>
> Also, the 301-fix is now here:
> -1.0.x trunk
> -1.2.6.1 branch
>
> not in 1.2_x trunk
>
> -Matthias
>
> -Matthias
>
>> Scott
>>
>>
>> Matthias Wessendorf wrote:
>>> also...
>>> doesn't this belong to the 12x trunk ?
>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>
>>> -M
>>>
>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + <version>1.0.0-alpha</version>
>>>>> + <scope>provided</scope>
>>>>> + </dependency>
>>>>>
>>>> I wonder fi is the right scope.
>>>> Pretty much all containers don't really ship that JAR.
>>>>
>>>> -M
>>>>
>>>>
>>>>
>>>>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>> <artifactId>myfaces-api</artifactId>
>>>>> <version>${myfaces.version}</version>
>>>>>
>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>> ==============================================================================
>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
>>>>> @@ -206,6 +206,11 @@
>>>>> </dependency>
>>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>> <artifactId>trinidad-build</artifactId>
>>>>> </dependency>
>>>>>
>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>> ==============================================================================
>>>>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
>>>>> @@ -51,6 +51,11 @@
>>>>>
>>>>> import java.io.IOException;
>>>>>
>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>> +
>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>> +
>>>>> /**
>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>> * SerializedView is stored on the server, and only a small token
>>>>> @@ -966,6 +971,17 @@
>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>
>>>>> + //This code handles automatic namespacing in a JSR-301 environment
>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>> + {
>>>>> + //To avoid introducing a runtime dependency on the bridge,
>>>>> + //this method should only be executed when we have a portlet
>>>>> + //request. If we do have a portlet request then the bridge
>>>>> + //should be available anyway.
>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>> + }
>>>>> +
>>>>> +
>>>>> // must call restoreState so that we setup attributes, listeners,
>>>>> // uniqueIds, etc ...
>>>>> newRoot.restoreState(fc, viewRootState);
>>>>> @@ -984,6 +1000,37 @@
>>>>>
>>>>> return null;
>>>>> }
>>>>> +
>>>>> + /**
>>>>> + * This should only be executed if we are currently in a Portlet Request.
>>>>> + * If executed, this method introduces a dependency on the JSR-301 bridge
>>>>> + * which is required for Trinidad to run in a portal environment. If this
>>>>> + * method is not run, then the bridge api's remain optional at runtime.
>>>>> + *
>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>> + * PortletNamingContainer. If it is, then this class simply returns the
>>>>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>> + */
>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>> + {
>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>> + //If the current root is not the real UIViewRoot object in faces then
>>>>> + //is no need to escape it. It is assumed it handles namespacing on its
>>>>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
>>>>> + if(rootClass == UIViewRoot.class)
>>>>> + {
>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>> + }
>>>>> +
>>>>> + //TODO: Do we need a warning here if the view root is not annotated
>>>>> + //properly? This could happen if another renderkit is involved and does
>>>>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
>>>>> + //environments.
>>>>> + return root;
>>>>> + }
>>>>> +
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> further stuff:
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> mail: matzew-at-apache-dot-org
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
Ok, yeah. Much to my embarrassment, my local trunk_1.2.x repository was
mapped to trunk.. Sorry. I'll fix that right away.
Scott
Scott O'Bryan wrote:
> Matthias,
>
> Yeah, both of these are issues. This should be in Trunk 1.2 and the
> demo should run without the classes in the classpath. I'll revert my
> change in trunk and move it. Sorry about that.
>
> As for compile scope, I'll check it out. The intent of this change
> was to NOT require the bridge API's in the classpath unless you are
> running in a portal. I'll redo this so that this is the case.
>
> Scott
>
> Matthias Wessendorf wrote:
>> Hi Scott,
>>
>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>>
>>> The Apache MVN website says this about providing a "compile only"
>>> library:
>>>
>>> "The scope you should use for this is |provided|. This indicates to
>>> Maven that the dependency will be provided at run time by its
>>> container or the JDK, for example.
>>>
>>> "Dependencies with this scope will not be passed on transitively,
>>> nor will they be bundled in an package such as a WAR, or
>>> included in
>>> the runtime classpath.
>>>
>>> This library is a runtime only library and is only needed when running
>>> in the portlet environment. Currently Trinidad's demo's aren't portlet
>>> compatible. Until I'm able to do some of this work, I would much
>>> rather
>>> this API (and the subsequent impl) not be added to the demo.
>>>
>>
>> I get a "java.lang.NoClassDefFoundError:
>> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
>> running the demos...
>> (on 1.2.6.1 branch)
>> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>>
>> when I change the dependency (as suggested) to compile, after building
>> Trinidad again, all works fine.
>>
>> Also, the 301-fix is now here:
>> -1.0.x trunk
>> -1.2.6.1 branch
>>
>> not in 1.2_x trunk
>>
>> -Matthias
>>
>> -Matthias
>>
>>
>>> Scott
>>>
>>>
>>> Matthias Wessendorf wrote:
>>>
>>>> also...
>>>> doesn't this belong to the 12x trunk ?
>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>
>>>> -M
>>>>
>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>> wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + <version>1.0.0-alpha</version>
>>>>>> + <scope>provided</scope>
>>>>>> + </dependency>
>>>>>>
>>>>>>
>>>>> I wonder fi is the right scope.
>>>>> Pretty much all containers don't really ship that JAR.
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>> <version>${myfaces.version}</version>
>>>>>>
>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>> 13:35:43 2008
>>>>>> @@ -206,6 +206,11 @@
>>>>>> </dependency>
>>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>> </dependency>
>>>>>>
>>>>>> Modified:
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> ---
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> (original)
>>>>>> +++
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> Tue Feb 19 13:35:43 2008
>>>>>> @@ -51,6 +51,11 @@
>>>>>>
>>>>>> import java.io.IOException;
>>>>>>
>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>> +import
>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>> +
>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>> +
>>>>>> /**
>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>> @@ -966,6 +971,17 @@
>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>
>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>
>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>> environment
>>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>> + {
>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>> bridge,
>>>>>> + //this method should only be executed when we have a
>>>>>> portlet
>>>>>> + //request. If we do have a portlet request then the
>>>>>> bridge
>>>>>> + //should be available anyway.
>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>> + }
>>>>>> +
>>>>>> +
>>>>>> // must call restoreState so that we setup attributes,
>>>>>> listeners,
>>>>>> // uniqueIds, etc ...
>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>> @@ -984,6 +1000,37 @@
>>>>>>
>>>>>> return null;
>>>>>> }
>>>>>> +
>>>>>> + /**
>>>>>> + * This should only be executed if we are currently in a
>>>>>> Portlet Request.
>>>>>> + * If executed, this method introduces a dependency on the
>>>>>> JSR-301 bridge
>>>>>> + * which is required for Trinidad to run in a portal
>>>>>> environment. If this
>>>>>> + * method is not run, then the bridge api's remain optional
>>>>>> at runtime.
>>>>>> + *
>>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>>> returns the
>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>> is used to create
>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>> + */
>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>> + {
>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>> + //If the current root is not the real UIViewRoot object in
>>>>>> faces then
>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>> namespacing on its
>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>> Bridge spec.
>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>> + {
>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>> portal.");
>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>> + }
>>>>>> +
>>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>>> annotated
>>>>>> + //properly? This could happen if another renderkit is
>>>>>> involved and does
>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>> issue in Trin only
>>>>>> + //environments.
>>>>>> + return root;
>>>>>> + }
>>>>>> +
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> further stuff:
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> mail: matzew-at-apache-dot-org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
Matthias,
Yeah, both of these are issues. This should be in Trunk 1.2 and the
demo should run without the classes in the classpath. I'll revert my
change in trunk and move it. Sorry about that.
As for compile scope, I'll check it out. The intent of this change was
to NOT require the bridge API's in the classpath unless you are running
in a portal. I'll redo this so that this is the case.
Scott
Matthias Wessendorf wrote:
> Hi Scott,
>
> On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
>
>> The Apache MVN website says this about providing a "compile only" library:
>>
>> "The scope you should use for this is |provided|. This indicates to
>> Maven that the dependency will be provided at run time by its
>> container or the JDK, for example.
>>
>> "Dependencies with this scope will not be passed on transitively,
>> nor will they be bundled in an package such as a WAR, or included in
>> the runtime classpath.
>>
>> This library is a runtime only library and is only needed when running
>> in the portlet environment. Currently Trinidad's demo's aren't portlet
>> compatible. Until I'm able to do some of this work, I would much rather
>> this API (and the subsequent impl) not be added to the demo.
>>
>
> I get a "java.lang.NoClassDefFoundError:
> javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
> running the demos...
> (on 1.2.6.1 branch)
> (trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
>
> when I change the dependency (as suggested) to compile, after building
> Trinidad again, all works fine.
>
> Also, the 301-fix is now here:
> -1.0.x trunk
> -1.2.6.1 branch
>
> not in 1.2_x trunk
>
> -Matthias
>
> -Matthias
>
>
>> Scott
>>
>>
>> Matthias Wessendorf wrote:
>>
>>> also...
>>> doesn't this belong to the 12x trunk ?
>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>
>>> -M
>>>
>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + <version>1.0.0-alpha</version>
>>>>> + <scope>provided</scope>
>>>>> + </dependency>
>>>>>
>>>>>
>>>> I wonder fi is the right scope.
>>>> Pretty much all containers don't really ship that JAR.
>>>>
>>>> -M
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>> <artifactId>myfaces-api</artifactId>
>>>>> <version>${myfaces.version}</version>
>>>>>
>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>> ==============================================================================
>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
>>>>> @@ -206,6 +206,11 @@
>>>>> </dependency>
>>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>> <artifactId>trinidad-build</artifactId>
>>>>> </dependency>
>>>>>
>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>> ==============================================================================
>>>>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
>>>>> @@ -51,6 +51,11 @@
>>>>>
>>>>> import java.io.IOException;
>>>>>
>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>> +
>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>> +
>>>>> /**
>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>> * SerializedView is stored on the server, and only a small token
>>>>> @@ -966,6 +971,17 @@
>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>
>>>>> + //This code handles automatic namespacing in a JSR-301 environment
>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>> + {
>>>>> + //To avoid introducing a runtime dependency on the bridge,
>>>>> + //this method should only be executed when we have a portlet
>>>>> + //request. If we do have a portlet request then the bridge
>>>>> + //should be available anyway.
>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>> + }
>>>>> +
>>>>> +
>>>>> // must call restoreState so that we setup attributes, listeners,
>>>>> // uniqueIds, etc ...
>>>>> newRoot.restoreState(fc, viewRootState);
>>>>> @@ -984,6 +1000,37 @@
>>>>>
>>>>> return null;
>>>>> }
>>>>> +
>>>>> + /**
>>>>> + * This should only be executed if we are currently in a Portlet Request.
>>>>> + * If executed, this method introduces a dependency on the JSR-301 bridge
>>>>> + * which is required for Trinidad to run in a portal environment. If this
>>>>> + * method is not run, then the bridge api's remain optional at runtime.
>>>>> + *
>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>> + * PortletNamingContainer. If it is, then this class simply returns the
>>>>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>> + */
>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>> + {
>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>> + //If the current root is not the real UIViewRoot object in faces then
>>>>> + //is no need to escape it. It is assumed it handles namespacing on its
>>>>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
>>>>> + if(rootClass == UIViewRoot.class)
>>>>> + {
>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>> + }
>>>>> +
>>>>> + //TODO: Do we need a warning here if the view root is not annotated
>>>>> + //properly? This could happen if another renderkit is involved and does
>>>>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
>>>>> + //environments.
>>>>> + return root;
>>>>> + }
>>>>> +
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> further stuff:
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> mail: matzew-at-apache-dot-org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi Scott,
On Feb 20, 2008 5:26 PM, Scott O'Bryan <da...@gmail.com> wrote:
> The Apache MVN website says this about providing a "compile only" library:
>
> "The scope you should use for this is |provided|. This indicates to
> Maven that the dependency will be provided at run time by its
> container or the JDK, for example.
>
> "Dependencies with this scope will not be passed on transitively,
> nor will they be bundled in an package such as a WAR, or included in
> the runtime classpath.
>
> This library is a runtime only library and is only needed when running
> in the portlet environment. Currently Trinidad's demo's aren't portlet
> compatible. Until I'm able to do some of this work, I would much rather
> this API (and the subsequent impl) not be added to the demo.
I get a "java.lang.NoClassDefFoundError:
javax/portlet/faces/component/PortletNamingContainerUIViewRoot" when
running the demos...
(on 1.2.6.1 branch)
(trinidad-demos in jetty => mvn clean jetty:run -PjettyConfig)
when I change the dependency (as suggested) to compile, after building
Trinidad again, all works fine.
Also, the 301-fix is now here:
-1.0.x trunk
-1.2.6.1 branch
not in 1.2_x trunk
-Matthias
-Matthias
>
> Scott
>
>
> Matthias Wessendorf wrote:
> > also...
> > doesn't this belong to the 12x trunk ?
> > My understanding is that the JSR 301 is kind of depending on JSF 1.2
> >
> > -M
> >
> > On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> >> Hi,
> >>
> >>
> >>> <dependency>
> >>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>> + <artifactId>portlet-bridge-api</artifactId>
> >>> + <version>1.0.0-alpha</version>
> >>> + <scope>provided</scope>
> >>> + </dependency>
> >>>
> >> I wonder fi is the right scope.
> >> Pretty much all containers don't really ship that JAR.
> >>
> >> -M
> >>
> >>
> >>
> >>
> >>> +
> >>> + <dependency>
> >>> <groupId>org.apache.myfaces.core</groupId>
> >>> <artifactId>myfaces-api</artifactId>
> >>> <version>${myfaces.version}</version>
> >>>
> >>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
> >>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
> >>> ==============================================================================
> >>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
> >>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
> >>> @@ -206,6 +206,11 @@
> >>> </dependency>
> >>>
> >>> <dependency>
> >>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> >>> + <artifactId>portlet-bridge-api</artifactId>
> >>> + </dependency>
> >>> +
> >>> + <dependency>
> >>> <groupId>org.apache.myfaces.trinidad</groupId>
> >>> <artifactId>trinidad-build</artifactId>
> >>> </dependency>
> >>>
> >>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> >>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
> >>> ==============================================================================
> >>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
> >>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
> >>> @@ -51,6 +51,11 @@
> >>>
> >>> import java.io.IOException;
> >>>
> >>> +import javax.portlet.faces.annotation.PortletNamingContainer;
> >>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
> >>> +
> >>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
> >>> +
> >>> /**
> >>> * StateManager that handles a hybrid client/server strategy: a
> >>> * SerializedView is stored on the server, and only a small token
> >>> @@ -966,6 +971,17 @@
> >>> UIViewRoot newRoot = (UIViewRoot)
> >>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
> >>>
> >>> + //This code handles automatic namespacing in a JSR-301 environment
> >>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
> >>> + {
> >>> + //To avoid introducing a runtime dependency on the bridge,
> >>> + //this method should only be executed when we have a portlet
> >>> + //request. If we do have a portlet request then the bridge
> >>> + //should be available anyway.
> >>> + newRoot = _getPortletRoot(newRoot);
> >>> + }
> >>> +
> >>> +
> >>> // must call restoreState so that we setup attributes, listeners,
> >>> // uniqueIds, etc ...
> >>> newRoot.restoreState(fc, viewRootState);
> >>> @@ -984,6 +1000,37 @@
> >>>
> >>> return null;
> >>> }
> >>> +
> >>> + /**
> >>> + * This should only be executed if we are currently in a Portlet Request.
> >>> + * If executed, this method introduces a dependency on the JSR-301 bridge
> >>> + * which is required for Trinidad to run in a portal environment. If this
> >>> + * method is not run, then the bridge api's remain optional at runtime.
> >>> + *
> >>> + * This method checks the current UIViewRoot to see if it is a
> >>> + * PortletNamingContainer. If it is, then this class simply returns the
> >>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
> >>> + * a new PortletNamingContainerUIViewRoot.
> >>> + */
> >>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
> >>> + {
> >>> + Class<? extends UIViewRoot> rootClass = root.getClass();
> >>> + //If the current root is not the real UIViewRoot object in faces then
> >>> + //is no need to escape it. It is assumed it handles namespacing on its
> >>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
> >>> + if(rootClass == UIViewRoot.class)
> >>> + {
> >>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
> >>> + root = new PortletNamingContainerUIViewRoot(root);
> >>> + }
> >>> +
> >>> + //TODO: Do we need a warning here if the view root is not annotated
> >>> + //properly? This could happen if another renderkit is involved and does
> >>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
> >>> + //environments.
> >>> + return root;
> >>> + }
> >>> +
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> mail: matzew-at-apache-dot-org
> >>
> >>
> >
> >
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
The Apache MVN website says this about providing a "compile only" library:
"The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided at run time by its
container or the JDK, for example.
"Dependencies with this scope will not be passed on transitively,
nor will they be bundled in an package such as a WAR, or included in
the runtime classpath.
This library is a runtime only library and is only needed when running
in the portlet environment. Currently Trinidad's demo's aren't portlet
compatible. Until I'm able to do some of this work, I would much rather
this API (and the subsequent impl) not be added to the demo.
Scott
Matthias Wessendorf wrote:
> also...
> doesn't this belong to the 12x trunk ?
> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>
> -M
>
> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>
>> Hi,
>>
>>
>>> <dependency>
>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>> + <artifactId>portlet-bridge-api</artifactId>
>>> + <version>1.0.0-alpha</version>
>>> + <scope>provided</scope>
>>> + </dependency>
>>>
>> I wonder fi is the right scope.
>> Pretty much all containers don't really ship that JAR.
>>
>> -M
>>
>>
>>
>>
>>> +
>>> + <dependency>
>>> <groupId>org.apache.myfaces.core</groupId>
>>> <artifactId>myfaces-api</artifactId>
>>> <version>${myfaces.version}</version>
>>>
>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>> ==============================================================================
>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
>>> @@ -206,6 +206,11 @@
>>> </dependency>
>>>
>>> <dependency>
>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>> + <artifactId>portlet-bridge-api</artifactId>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>> <artifactId>trinidad-build</artifactId>
>>> </dependency>
>>>
>>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>> ==============================================================================
>>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
>>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
>>> @@ -51,6 +51,11 @@
>>>
>>> import java.io.IOException;
>>>
>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>> +
>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>> +
>>> /**
>>> * StateManager that handles a hybrid client/server strategy: a
>>> * SerializedView is stored on the server, and only a small token
>>> @@ -966,6 +971,17 @@
>>> UIViewRoot newRoot = (UIViewRoot)
>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>
>>> + //This code handles automatic namespacing in a JSR-301 environment
>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>> + {
>>> + //To avoid introducing a runtime dependency on the bridge,
>>> + //this method should only be executed when we have a portlet
>>> + //request. If we do have a portlet request then the bridge
>>> + //should be available anyway.
>>> + newRoot = _getPortletRoot(newRoot);
>>> + }
>>> +
>>> +
>>> // must call restoreState so that we setup attributes, listeners,
>>> // uniqueIds, etc ...
>>> newRoot.restoreState(fc, viewRootState);
>>> @@ -984,6 +1000,37 @@
>>>
>>> return null;
>>> }
>>> +
>>> + /**
>>> + * This should only be executed if we are currently in a Portlet Request.
>>> + * If executed, this method introduces a dependency on the JSR-301 bridge
>>> + * which is required for Trinidad to run in a portal environment. If this
>>> + * method is not run, then the bridge api's remain optional at runtime.
>>> + *
>>> + * This method checks the current UIViewRoot to see if it is a
>>> + * PortletNamingContainer. If it is, then this class simply returns the
>>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
>>> + * a new PortletNamingContainerUIViewRoot.
>>> + */
>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>> + {
>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>> + //If the current root is not the real UIViewRoot object in faces then
>>> + //is no need to escape it. It is assumed it handles namespacing on its
>>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
>>> + if(rootClass == UIViewRoot.class)
>>> + {
>>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
>>> + root = new PortletNamingContainerUIViewRoot(root);
>>> + }
>>> +
>>> + //TODO: Do we need a warning here if the view root is not annotated
>>> + //properly? This could happen if another renderkit is involved and does
>>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
>>> + //environments.
>>> + return root;
>>> + }
>>> +
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Matthias Wessendorf
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>>
>
>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
This change does not impact 1.1.x at all. It's only a JSF 1.2 change..
Therefore it's only in the Trinidad 1.2 trunk. Do you still need this
change for 1.2? I'm not sure if the Apache Portals JSF Bridge even
works with 1.2.
Scott
Bernhard Huemer wrote:
> Hello,
>
> it would be great if you could check whether the class actually
> exists. I'm using the Apache Portals JSF Bridge with MyFaces 1.1.x.
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
> "Scott O'Bryan" <da...@gmail.com> wrote:
>> We can, but it's a lot of overkill. My concern going forward,
>> however, is that Trinidad is going to be expected to work with the
>> standard as it emerges and us trying to pay run with non-standard
>> bridges will limit our ability to support the standard ones.
>>
>> That said, I suppose I can put some checking to make sure that this
>> class actually exists in the classpath before actually using it. The
>> POM dependency shouldn't make a difference if I did this though.
>>
>> You mind me asking what Bridge you are using? Also, are you using
>> JSF 1.2?
>>
>> Scott
>>
>>
>>
>> Bernhard Huemer wrote:
>>> Hello,
>>>
>>> actually, I'm using Trinidad with a non JSR-301 bridge (even though
>>> it requires some "workarounds" ..). Isn't it possible to make this
>>> bugfix optional, for example by introducing a Jsr301StateManagerImpl?
>>>
>>> regards,
>>> Bernhard
>>>
>>> On 02/20/2008 +0100,
>>> "Scott O'Bryan" <da...@gmail.com> wrote:
>>>> There is no compatibility for Trinidad with non JSR-301 bridges.
>>>>
>>>> Scott
>>>>
>>>> Bernhard Huemer wrote:
>>>>> Hello,
>>>>>
>>>>> additionally I'm concerned whether this breaks compatibility with
>>>>> current (non JSR-301) portlet bridges ..
>>>>>
>>>>> regards,
>>>>> Bernhard
>>>>>
>>>>> On 02/20/2008 +0100,
>>>>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>>>>> also...
>>>>>> doesn't this belong to the 12x trunk ?
>>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>>>
>>>>>> -M
>>>>>>
>>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>> + <version>1.0.0-alpha</version>
>>>>>>>> + <scope>provided</scope>
>>>>>>>> + </dependency>
>>>>>>>
>>>>>>> I wonder fi is the right scope.
>>>>>>> Pretty much all containers don't really ship that JAR.
>>>>>>>
>>>>>>> -M
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> + <dependency>
>>>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>>>> <version>${myfaces.version}</version>
>>>>>>>>
>>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>>>> URL:
>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>
>>>>>>>> ==============================================================================
>>>>>>>>
>>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>>>> 13:35:43 2008
>>>>>>>> @@ -206,6 +206,11 @@
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>>> + </dependency>
>>>>>>>> +
>>>>>>>> + <dependency>
>>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>> Modified:
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>>
>>>>>>>> URL:
>>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>>
>>>>>>>> ==============================================================================
>>>>>>>>
>>>>>>>> ---
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>> (original)
>>>>>>>> +++
>>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>> Tue Feb 19 13:35:43 2008
>>>>>>>> @@ -51,6 +51,11 @@
>>>>>>>>
>>>>>>>> import java.io.IOException;
>>>>>>>>
>>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>>>> +import
>>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>>>> +
>>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>>>> +
>>>>>>>> /**
>>>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>>>> @@ -966,6 +971,17 @@
>>>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>>>
>>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>>>
>>>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>>>> environment
>>>>>>>> +
>>>>>>>> if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>>>> + {
>>>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>>>> bridge,
>>>>>>>> + //this method should only be executed when we have a
>>>>>>>> portlet
>>>>>>>> + //request. If we do have a portlet request then the
>>>>>>>> bridge
>>>>>>>> + //should be available anyway.
>>>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> +
>>>>>>>> // must call restoreState so that we setup attributes,
>>>>>>>> listeners,
>>>>>>>> // uniqueIds, etc ...
>>>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>>>> @@ -984,6 +1000,37 @@
>>>>>>>>
>>>>>>>> return null;
>>>>>>>> }
>>>>>>>> +
>>>>>>>> + /**
>>>>>>>> + * This should only be executed if we are currently in a
>>>>>>>> Portlet Request.
>>>>>>>> + * If executed, this method introduces a dependency on the
>>>>>>>> JSR-301 bridge
>>>>>>>> + * which is required for Trinidad to run in a portal
>>>>>>>> environment. If this
>>>>>>>> + * method is not run, then the bridge api's remain
>>>>>>>> optional at runtime.
>>>>>>>> + *
>>>>>>>> + * This method checks the current UIViewRoot to see if it
>>>>>>>> is a
>>>>>>>> + * PortletNamingContainer. If it is, then this class
>>>>>>>> simply returns the
>>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>>>> is used to create
>>>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>>>> + */
>>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>>>> + {
>>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>>>> + //If the current root is not the real UIViewRoot object
>>>>>>>> in faces then
>>>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>>>> namespacing on its
>>>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>>>> Bridge spec.
>>>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>>>> + {
>>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>>>> portal.");
>>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + //TODO: Do we need a warning here if the view root is
>>>>>>>> not annotated
>>>>>>>> + //properly? This could happen if another renderkit is
>>>>>>>> involved and does
>>>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>>>> issue in Trin only
>>>>>>>> + //environments.
>>>>>>>> + return root;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> further stuff:
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> mail: matzew-at-apache-dot-org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
it would be great if you could check whether the class actually exists.
I'm using the Apache Portals JSF Bridge with MyFaces 1.1.x.
regards,
Bernhard
On 02/20/2008 +0100,
"Scott O'Bryan" <da...@gmail.com> wrote:
> We can, but it's a lot of overkill. My concern going forward, however,
> is that Trinidad is going to be expected to work with the standard as it
> emerges and us trying to pay run with non-standard bridges will limit
> our ability to support the standard ones.
>
> That said, I suppose I can put some checking to make sure that this
> class actually exists in the classpath before actually using it. The
> POM dependency shouldn't make a difference if I did this though.
>
> You mind me asking what Bridge you are using? Also, are you using JSF 1.2?
>
> Scott
>
>
>
> Bernhard Huemer wrote:
>> Hello,
>>
>> actually, I'm using Trinidad with a non JSR-301 bridge (even though it
>> requires some "workarounds" ..). Isn't it possible to make this bugfix
>> optional, for example by introducing a Jsr301StateManagerImpl?
>>
>> regards,
>> Bernhard
>>
>> On 02/20/2008 +0100,
>> "Scott O'Bryan" <da...@gmail.com> wrote:
>>> There is no compatibility for Trinidad with non JSR-301 bridges.
>>>
>>> Scott
>>>
>>> Bernhard Huemer wrote:
>>>> Hello,
>>>>
>>>> additionally I'm concerned whether this breaks compatibility with
>>>> current (non JSR-301) portlet bridges ..
>>>>
>>>> regards,
>>>> Bernhard
>>>>
>>>> On 02/20/2008 +0100,
>>>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>>>> also...
>>>>> doesn't this belong to the 12x trunk ?
>>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>>
>>>>> -M
>>>>>
>>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> <dependency>
>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>> + <version>1.0.0-alpha</version>
>>>>>>> + <scope>provided</scope>
>>>>>>> + </dependency>
>>>>>>
>>>>>> I wonder fi is the right scope.
>>>>>> Pretty much all containers don't really ship that JAR.
>>>>>>
>>>>>> -M
>>>>>>
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> + <dependency>
>>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>>> <version>${myfaces.version}</version>
>>>>>>>
>>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>>> URL:
>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>>> 13:35:43 2008
>>>>>>> @@ -206,6 +206,11 @@
>>>>>>> </dependency>
>>>>>>>
>>>>>>> <dependency>
>>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>>> + </dependency>
>>>>>>> +
>>>>>>> + <dependency>
>>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>>> </dependency>
>>>>>>>
>>>>>>> Modified:
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>>
>>>>>>> URL:
>>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>> ---
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>> (original)
>>>>>>> +++
>>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>> Tue Feb 19 13:35:43 2008
>>>>>>> @@ -51,6 +51,11 @@
>>>>>>>
>>>>>>> import java.io.IOException;
>>>>>>>
>>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>>> +import
>>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>>> +
>>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>>> +
>>>>>>> /**
>>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>>> @@ -966,6 +971,17 @@
>>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>>
>>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>>
>>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>>> environment
>>>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>>> + {
>>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>>> bridge,
>>>>>>> + //this method should only be executed when we have a
>>>>>>> portlet
>>>>>>> + //request. If we do have a portlet request then the
>>>>>>> bridge
>>>>>>> + //should be available anyway.
>>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>>> + }
>>>>>>> +
>>>>>>> +
>>>>>>> // must call restoreState so that we setup attributes,
>>>>>>> listeners,
>>>>>>> // uniqueIds, etc ...
>>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>>> @@ -984,6 +1000,37 @@
>>>>>>>
>>>>>>> return null;
>>>>>>> }
>>>>>>> +
>>>>>>> + /**
>>>>>>> + * This should only be executed if we are currently in a
>>>>>>> Portlet Request.
>>>>>>> + * If executed, this method introduces a dependency on the
>>>>>>> JSR-301 bridge
>>>>>>> + * which is required for Trinidad to run in a portal
>>>>>>> environment. If this
>>>>>>> + * method is not run, then the bridge api's remain optional
>>>>>>> at runtime.
>>>>>>> + *
>>>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>>>> returns the
>>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>>> is used to create
>>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>>> + */
>>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>>> + {
>>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>>> + //If the current root is not the real UIViewRoot object in
>>>>>>> faces then
>>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>>> namespacing on its
>>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>>> Bridge spec.
>>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>>> + {
>>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>>> portal.");
>>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>>> + }
>>>>>>> +
>>>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>>>> annotated
>>>>>>> + //properly? This could happen if another renderkit is
>>>>>>> involved and does
>>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>>> issue in Trin only
>>>>>>> + //environments.
>>>>>>> + return root;
>>>>>>> + }
>>>>>>> +
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> further stuff:
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> mail: matzew-at-apache-dot-org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
We can, but it's a lot of overkill. My concern going forward, however,
is that Trinidad is going to be expected to work with the standard as it
emerges and us trying to pay run with non-standard bridges will limit
our ability to support the standard ones.
That said, I suppose I can put some checking to make sure that this
class actually exists in the classpath before actually using it. The
POM dependency shouldn't make a difference if I did this though.
You mind me asking what Bridge you are using? Also, are you using JSF 1.2?
Scott
Bernhard Huemer wrote:
> Hello,
>
> actually, I'm using Trinidad with a non JSR-301 bridge (even though it
> requires some "workarounds" ..). Isn't it possible to make this bugfix
> optional, for example by introducing a Jsr301StateManagerImpl?
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
> "Scott O'Bryan" <da...@gmail.com> wrote:
>> There is no compatibility for Trinidad with non JSR-301 bridges.
>>
>> Scott
>>
>> Bernhard Huemer wrote:
>>> Hello,
>>>
>>> additionally I'm concerned whether this breaks compatibility with
>>> current (non JSR-301) portlet bridges ..
>>>
>>> regards,
>>> Bernhard
>>>
>>> On 02/20/2008 +0100,
>>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>>> also...
>>>> doesn't this belong to the 12x trunk ?
>>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>>
>>>> -M
>>>>
>>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + <version>1.0.0-alpha</version>
>>>>>> + <scope>provided</scope>
>>>>>> + </dependency>
>>>>>
>>>>> I wonder fi is the right scope.
>>>>> Pretty much all containers don't really ship that JAR.
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>>> <artifactId>myfaces-api</artifactId>
>>>>>> <version>${myfaces.version}</version>
>>>>>>
>>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>>> 13:35:43 2008
>>>>>> @@ -206,6 +206,11 @@
>>>>>> </dependency>
>>>>>>
>>>>>> <dependency>
>>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>>> <artifactId>trinidad-build</artifactId>
>>>>>> </dependency>
>>>>>>
>>>>>> Modified:
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>>
>>>>>> URL:
>>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> ---
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> (original)
>>>>>> +++
>>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>> Tue Feb 19 13:35:43 2008
>>>>>> @@ -51,6 +51,11 @@
>>>>>>
>>>>>> import java.io.IOException;
>>>>>>
>>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>>> +import
>>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>>> +
>>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>>> +
>>>>>> /**
>>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>>> * SerializedView is stored on the server, and only a small token
>>>>>> @@ -966,6 +971,17 @@
>>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>>
>>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>>
>>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>>> environment
>>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>>> + {
>>>>>> + //To avoid introducing a runtime dependency on the
>>>>>> bridge,
>>>>>> + //this method should only be executed when we have a
>>>>>> portlet
>>>>>> + //request. If we do have a portlet request then the
>>>>>> bridge
>>>>>> + //should be available anyway.
>>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>>> + }
>>>>>> +
>>>>>> +
>>>>>> // must call restoreState so that we setup attributes,
>>>>>> listeners,
>>>>>> // uniqueIds, etc ...
>>>>>> newRoot.restoreState(fc, viewRootState);
>>>>>> @@ -984,6 +1000,37 @@
>>>>>>
>>>>>> return null;
>>>>>> }
>>>>>> +
>>>>>> + /**
>>>>>> + * This should only be executed if we are currently in a
>>>>>> Portlet Request.
>>>>>> + * If executed, this method introduces a dependency on the
>>>>>> JSR-301 bridge
>>>>>> + * which is required for Trinidad to run in a portal
>>>>>> environment. If this
>>>>>> + * method is not run, then the bridge api's remain optional
>>>>>> at runtime.
>>>>>> + *
>>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>>> returns the
>>>>>> + * UIViewRoot. If it does not then the current UIViewRoot
>>>>>> is used to create
>>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>>> + */
>>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>>> + {
>>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>>> + //If the current root is not the real UIViewRoot object in
>>>>>> faces then
>>>>>> + //is no need to escape it. It is assumed it handles
>>>>>> namespacing on its
>>>>>> + //own. This is the same as the logic in the JSR-301
>>>>>> Bridge spec.
>>>>>> + if(rootClass == UIViewRoot.class)
>>>>>> + {
>>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>>> portal.");
>>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>>> + }
>>>>>> +
>>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>>> annotated
>>>>>> + //properly? This could happen if another renderkit is
>>>>>> involved and does
>>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>>> issue in Trin only
>>>>>> + //environments.
>>>>>> + return root;
>>>>>> + }
>>>>>> +
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> further stuff:
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> mail: matzew-at-apache-dot-org
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
actually, I'm using Trinidad with a non JSR-301 bridge (even though it
requires some "workarounds" ..). Isn't it possible to make this bugfix
optional, for example by introducing a Jsr301StateManagerImpl?
regards,
Bernhard
On 02/20/2008 +0100,
"Scott O'Bryan" <da...@gmail.com> wrote:
> There is no compatibility for Trinidad with non JSR-301 bridges.
>
> Scott
>
> Bernhard Huemer wrote:
>> Hello,
>>
>> additionally I'm concerned whether this breaks compatibility with
>> current (non JSR-301) portlet bridges ..
>>
>> regards,
>> Bernhard
>>
>> On 02/20/2008 +0100,
>> "Matthias Wessendorf" <ma...@apache.org> wrote:
>>> also...
>>> doesn't this belong to the 12x trunk ?
>>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>>
>>> -M
>>>
>>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>>> Hi,
>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + <version>1.0.0-alpha</version>
>>>>> + <scope>provided</scope>
>>>>> + </dependency>
>>>>
>>>> I wonder fi is the right scope.
>>>> Pretty much all containers don't really ship that JAR.
>>>>
>>>> -M
>>>>
>>>>
>>>>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.core</groupId>
>>>>> <artifactId>myfaces-api</artifactId>
>>>>> <version>${myfaces.version}</version>
>>>>>
>>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>>
>>>>> ==============================================================================
>>>>>
>>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>>> 13:35:43 2008
>>>>> @@ -206,6 +206,11 @@
>>>>> </dependency>
>>>>>
>>>>> <dependency>
>>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>>> <artifactId>trinidad-build</artifactId>
>>>>> </dependency>
>>>>>
>>>>> Modified:
>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>>
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>>
>>>>> ==============================================================================
>>>>>
>>>>> ---
>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>> (original)
>>>>> +++
>>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>> Tue Feb 19 13:35:43 2008
>>>>> @@ -51,6 +51,11 @@
>>>>>
>>>>> import java.io.IOException;
>>>>>
>>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>>> +import
>>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>>> +
>>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>>> +
>>>>> /**
>>>>> * StateManager that handles a hybrid client/server strategy: a
>>>>> * SerializedView is stored on the server, and only a small token
>>>>> @@ -966,6 +971,17 @@
>>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>>
>>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>>
>>>>> + //This code handles automatic namespacing in a JSR-301
>>>>> environment
>>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>>> + {
>>>>> + //To avoid introducing a runtime dependency on the bridge,
>>>>> + //this method should only be executed when we have a
>>>>> portlet
>>>>> + //request. If we do have a portlet request then the bridge
>>>>> + //should be available anyway.
>>>>> + newRoot = _getPortletRoot(newRoot);
>>>>> + }
>>>>> +
>>>>> +
>>>>> // must call restoreState so that we setup attributes,
>>>>> listeners,
>>>>> // uniqueIds, etc ...
>>>>> newRoot.restoreState(fc, viewRootState);
>>>>> @@ -984,6 +1000,37 @@
>>>>>
>>>>> return null;
>>>>> }
>>>>> +
>>>>> + /**
>>>>> + * This should only be executed if we are currently in a
>>>>> Portlet Request.
>>>>> + * If executed, this method introduces a dependency on the
>>>>> JSR-301 bridge
>>>>> + * which is required for Trinidad to run in a portal
>>>>> environment. If this
>>>>> + * method is not run, then the bridge api's remain optional at
>>>>> runtime.
>>>>> + *
>>>>> + * This method checks the current UIViewRoot to see if it is a
>>>>> + * PortletNamingContainer. If it is, then this class simply
>>>>> returns the
>>>>> + * UIViewRoot. If it does not then the current UIViewRoot is
>>>>> used to create
>>>>> + * a new PortletNamingContainerUIViewRoot.
>>>>> + */
>>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>>> + {
>>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>>> + //If the current root is not the real UIViewRoot object in
>>>>> faces then
>>>>> + //is no need to escape it. It is assumed it handles
>>>>> namespacing on its
>>>>> + //own. This is the same as the logic in the JSR-301 Bridge
>>>>> spec.
>>>>> + if(rootClass == UIViewRoot.class)
>>>>> + {
>>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>>> portal.");
>>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>>> + }
>>>>> +
>>>>> + //TODO: Do we need a warning here if the view root is not
>>>>> annotated
>>>>> + //properly? This could happen if another renderkit is
>>>>> involved and does
>>>>> + //not correctly implement JSR-301. This will NOT be an
>>>>> issue in Trin only
>>>>> + //environments.
>>>>> + return root;
>>>>> + }
>>>>> +
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> further stuff:
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> mail: matzew-at-apache-dot-org
>>>>
>>>
>>>
>>>
>>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Scott O'Bryan <da...@gmail.com>.
There is no compatibility for Trinidad with non JSR-301 bridges.
Scott
Bernhard Huemer wrote:
> Hello,
>
> additionally I'm concerned whether this breaks compatibility with
> current (non JSR-301) portlet bridges ..
>
> regards,
> Bernhard
>
> On 02/20/2008 +0100,
> "Matthias Wessendorf" <ma...@apache.org> wrote:
>> also...
>> doesn't this belong to the 12x trunk ?
>> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>>
>> -M
>>
>> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>> Hi,
>>>
>>>> <dependency>
>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>> + <version>1.0.0-alpha</version>
>>>> + <scope>provided</scope>
>>>> + </dependency>
>>>
>>> I wonder fi is the right scope.
>>> Pretty much all containers don't really ship that JAR.
>>>
>>> -M
>>>
>>>
>>>
>>>> +
>>>> + <dependency>
>>>> <groupId>org.apache.myfaces.core</groupId>
>>>> <artifactId>myfaces-api</artifactId>
>>>> <version>${myfaces.version}</version>
>>>>
>>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>>> URL:
>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>>>
>>>> ==============================================================================
>>>>
>>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
>>>> 13:35:43 2008
>>>> @@ -206,6 +206,11 @@
>>>> </dependency>
>>>>
>>>> <dependency>
>>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>>> + <artifactId>portlet-bridge-api</artifactId>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>>> <artifactId>trinidad-build</artifactId>
>>>> </dependency>
>>>>
>>>> Modified:
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>>
>>>> URL:
>>>> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>>>
>>>> ==============================================================================
>>>>
>>>> ---
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>> (original)
>>>> +++
>>>> myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>>> Tue Feb 19 13:35:43 2008
>>>> @@ -51,6 +51,11 @@
>>>>
>>>> import java.io.IOException;
>>>>
>>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>>> +import
>>>> javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>>> +
>>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>>> +
>>>> /**
>>>> * StateManager that handles a hybrid client/server strategy: a
>>>> * SerializedView is stored on the server, and only a small token
>>>> @@ -966,6 +971,17 @@
>>>> UIViewRoot newRoot = (UIViewRoot)
>>>>
>>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>>
>>>> + //This code handles automatic namespacing in a JSR-301
>>>> environment
>>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>>> + {
>>>> + //To avoid introducing a runtime dependency on the bridge,
>>>> + //this method should only be executed when we have a
>>>> portlet
>>>> + //request. If we do have a portlet request then the bridge
>>>> + //should be available anyway.
>>>> + newRoot = _getPortletRoot(newRoot);
>>>> + }
>>>> +
>>>> +
>>>> // must call restoreState so that we setup attributes,
>>>> listeners,
>>>> // uniqueIds, etc ...
>>>> newRoot.restoreState(fc, viewRootState);
>>>> @@ -984,6 +1000,37 @@
>>>>
>>>> return null;
>>>> }
>>>> +
>>>> + /**
>>>> + * This should only be executed if we are currently in a
>>>> Portlet Request.
>>>> + * If executed, this method introduces a dependency on the
>>>> JSR-301 bridge
>>>> + * which is required for Trinidad to run in a portal
>>>> environment. If this
>>>> + * method is not run, then the bridge api's remain optional at
>>>> runtime.
>>>> + *
>>>> + * This method checks the current UIViewRoot to see if it is a
>>>> + * PortletNamingContainer. If it is, then this class simply
>>>> returns the
>>>> + * UIViewRoot. If it does not then the current UIViewRoot is
>>>> used to create
>>>> + * a new PortletNamingContainerUIViewRoot.
>>>> + */
>>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>>> + {
>>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>>> + //If the current root is not the real UIViewRoot object in
>>>> faces then
>>>> + //is no need to escape it. It is assumed it handles
>>>> namespacing on its
>>>> + //own. This is the same as the logic in the JSR-301 Bridge
>>>> spec.
>>>> + if(rootClass == UIViewRoot.class)
>>>> + {
>>>> + _LOG.fine("Creating PortletUIViewRoot for use with the
>>>> portal.");
>>>> + root = new PortletNamingContainerUIViewRoot(root);
>>>> + }
>>>> +
>>>> + //TODO: Do we need a warning here if the view root is not
>>>> annotated
>>>> + //properly? This could happen if another renderkit is
>>>> involved and does
>>>> + //not correctly implement JSR-301. This will NOT be an
>>>> issue in Trin only
>>>> + //environments.
>>>> + return root;
>>>> + }
>>>> +
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> further stuff:
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> mail: matzew-at-apache-dot-org
>>>
>>
>>
>>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
"Matthias Wessendorf" <ma...@apache.org> wrote:
> also...
> doesn't this belong to the 12x trunk ?
> My understanding is that the JSR 301 is kind of depending on JSF 1.2
>
> -M
>
> On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>> Hi,
>>
>>> <dependency>
>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>> + <artifactId>portlet-bridge-api</artifactId>
>>> + <version>1.0.0-alpha</version>
>>> + <scope>provided</scope>
>>> + </dependency>
>>
>> I wonder fi is the right scope.
>> Pretty much all containers don't really ship that JAR.
>>
>> -M
>>
>>
>>
>>> +
>>> + <dependency>
>>> <groupId>org.apache.myfaces.core</groupId>
>>> <artifactId>myfaces-api</artifactId>
>>> <version>${myfaces.version}</version>
>>>
>>> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
>>> ==============================================================================
>>> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
>>> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
>>> @@ -206,6 +206,11 @@
>>> </dependency>
>>>
>>> <dependency>
>>> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
>>> + <artifactId>portlet-bridge-api</artifactId>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> <groupId>org.apache.myfaces.trinidad</groupId>
>>> <artifactId>trinidad-build</artifactId>
>>> </dependency>
>>>
>>> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
>>> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
>>> ==============================================================================
>>> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
>>> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
>>> @@ -51,6 +51,11 @@
>>>
>>> import java.io.IOException;
>>>
>>> +import javax.portlet.faces.annotation.PortletNamingContainer;
>>> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
>>> +
>>> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
>>> +
>>> /**
>>> * StateManager that handles a hybrid client/server strategy: a
>>> * SerializedView is stored on the server, and only a small token
>>> @@ -966,6 +971,17 @@
>>> UIViewRoot newRoot = (UIViewRoot)
>>> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>>>
>>> + //This code handles automatic namespacing in a JSR-301 environment
>>> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
>>> + {
>>> + //To avoid introducing a runtime dependency on the bridge,
>>> + //this method should only be executed when we have a portlet
>>> + //request. If we do have a portlet request then the bridge
>>> + //should be available anyway.
>>> + newRoot = _getPortletRoot(newRoot);
>>> + }
>>> +
>>> +
>>> // must call restoreState so that we setup attributes, listeners,
>>> // uniqueIds, etc ...
>>> newRoot.restoreState(fc, viewRootState);
>>> @@ -984,6 +1000,37 @@
>>>
>>> return null;
>>> }
>>> +
>>> + /**
>>> + * This should only be executed if we are currently in a Portlet Request.
>>> + * If executed, this method introduces a dependency on the JSR-301 bridge
>>> + * which is required for Trinidad to run in a portal environment. If this
>>> + * method is not run, then the bridge api's remain optional at runtime.
>>> + *
>>> + * This method checks the current UIViewRoot to see if it is a
>>> + * PortletNamingContainer. If it is, then this class simply returns the
>>> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
>>> + * a new PortletNamingContainerUIViewRoot.
>>> + */
>>> + private UIViewRoot _getPortletRoot(UIViewRoot root)
>>> + {
>>> + Class<? extends UIViewRoot> rootClass = root.getClass();
>>> + //If the current root is not the real UIViewRoot object in faces then
>>> + //is no need to escape it. It is assumed it handles namespacing on its
>>> + //own. This is the same as the logic in the JSR-301 Bridge spec.
>>> + if(rootClass == UIViewRoot.class)
>>> + {
>>> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
>>> + root = new PortletNamingContainerUIViewRoot(root);
>>> + }
>>> +
>>> + //TODO: Do we need a warning here if the view root is not annotated
>>> + //properly? This could happen if another renderkit is involved and does
>>> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
>>> + //environments.
>>> + return root;
>>> + }
>>> +
>>> }
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>
>
>
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Matthias Wessendorf <ma...@apache.org>.
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi,
>
> > <dependency>
> > + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> > + <artifactId>portlet-bridge-api</artifactId>
> > + <version>1.0.0-alpha</version>
> > + <scope>provided</scope>
> > + </dependency>
>
>
> I wonder fi is the right scope.
> Pretty much all containers don't really ship that JAR.
>
> -M
>
>
>
> > +
> > + <dependency>
> > <groupId>org.apache.myfaces.core</groupId>
> > <artifactId>myfaces-api</artifactId>
> > <version>${myfaces.version}</version>
> >
> > Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
> > URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
> > ==============================================================================
> > --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
> > +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
> > @@ -206,6 +206,11 @@
> > </dependency>
> >
> > <dependency>
> > + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> > + <artifactId>portlet-bridge-api</artifactId>
> > + </dependency>
> > +
> > + <dependency>
> > <groupId>org.apache.myfaces.trinidad</groupId>
> > <artifactId>trinidad-build</artifactId>
> > </dependency>
> >
> > Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> > URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
> > ==============================================================================
> > --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
> > +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
> > @@ -51,6 +51,11 @@
> >
> > import java.io.IOException;
> >
> > +import javax.portlet.faces.annotation.PortletNamingContainer;
> > +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
> > +
> > +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
> > +
> > /**
> > * StateManager that handles a hybrid client/server strategy: a
> > * SerializedView is stored on the server, and only a small token
> > @@ -966,6 +971,17 @@
> > UIViewRoot newRoot = (UIViewRoot)
> > fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
> >
> > + //This code handles automatic namespacing in a JSR-301 environment
> > + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
> > + {
> > + //To avoid introducing a runtime dependency on the bridge,
> > + //this method should only be executed when we have a portlet
> > + //request. If we do have a portlet request then the bridge
> > + //should be available anyway.
> > + newRoot = _getPortletRoot(newRoot);
> > + }
> > +
> > +
> > // must call restoreState so that we setup attributes, listeners,
> > // uniqueIds, etc ...
> > newRoot.restoreState(fc, viewRootState);
> > @@ -984,6 +1000,37 @@
> >
> > return null;
> > }
> > +
> > + /**
> > + * This should only be executed if we are currently in a Portlet Request.
> > + * If executed, this method introduces a dependency on the JSR-301 bridge
> > + * which is required for Trinidad to run in a portal environment. If this
> > + * method is not run, then the bridge api's remain optional at runtime.
> > + *
> > + * This method checks the current UIViewRoot to see if it is a
> > + * PortletNamingContainer. If it is, then this class simply returns the
> > + * UIViewRoot. If it does not then the current UIViewRoot is used to create
> > + * a new PortletNamingContainerUIViewRoot.
> > + */
> > + private UIViewRoot _getPortletRoot(UIViewRoot root)
> > + {
> > + Class<? extends UIViewRoot> rootClass = root.getClass();
> > + //If the current root is not the real UIViewRoot object in faces then
> > + //is no need to escape it. It is assumed it handles namespacing on its
> > + //own. This is the same as the logic in the JSR-301 Bridge spec.
> > + if(rootClass == UIViewRoot.class)
> > + {
> > + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
> > + root = new PortletNamingContainerUIViewRoot(root);
> > + }
> > +
> > + //TODO: Do we need a warning here if the view root is not annotated
> > + //properly? This could happen if another renderkit is involved and does
> > + //not correctly implement JSR-301. This will NOT be an issue in Trin only
> > + //environments.
> > + return root;
> > + }
> > +
> > }
> >
> >
> >
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
> <dependency>
> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> + <artifactId>portlet-bridge-api</artifactId>
> + <version>1.0.0-alpha</version>
> + <scope>provided</scope>
> + </dependency>
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
> +
> + <dependency>
> <groupId>org.apache.myfaces.core</groupId>
> <artifactId>myfaces-api</artifactId>
> <version>${myfaces.version}</version>
>
> Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff
> ==============================================================================
> --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
> +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
> @@ -206,6 +206,11 @@
> </dependency>
>
> <dependency>
> + <groupId>org.apache.myfaces.portlet-bridge</groupId>
> + <artifactId>portlet-bridge-api</artifactId>
> + </dependency>
> +
> + <dependency>
> <groupId>org.apache.myfaces.trinidad</groupId>
> <artifactId>trinidad-build</artifactId>
> </dependency>
>
> Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
> URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff
> ==============================================================================
> --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original)
> +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
> @@ -51,6 +51,11 @@
>
> import java.io.IOException;
>
> +import javax.portlet.faces.annotation.PortletNamingContainer;
> +import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
> +
> +import org.apache.myfaces.trinidad.util.ExternalContextUtils;
> +
> /**
> * StateManager that handles a hybrid client/server strategy: a
> * SerializedView is stored on the server, and only a small token
> @@ -966,6 +971,17 @@
> UIViewRoot newRoot = (UIViewRoot)
> fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
>
> + //This code handles automatic namespacing in a JSR-301 environment
> + if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
> + {
> + //To avoid introducing a runtime dependency on the bridge,
> + //this method should only be executed when we have a portlet
> + //request. If we do have a portlet request then the bridge
> + //should be available anyway.
> + newRoot = _getPortletRoot(newRoot);
> + }
> +
> +
> // must call restoreState so that we setup attributes, listeners,
> // uniqueIds, etc ...
> newRoot.restoreState(fc, viewRootState);
> @@ -984,6 +1000,37 @@
>
> return null;
> }
> +
> + /**
> + * This should only be executed if we are currently in a Portlet Request.
> + * If executed, this method introduces a dependency on the JSR-301 bridge
> + * which is required for Trinidad to run in a portal environment. If this
> + * method is not run, then the bridge api's remain optional at runtime.
> + *
> + * This method checks the current UIViewRoot to see if it is a
> + * PortletNamingContainer. If it is, then this class simply returns the
> + * UIViewRoot. If it does not then the current UIViewRoot is used to create
> + * a new PortletNamingContainerUIViewRoot.
> + */
> + private UIViewRoot _getPortletRoot(UIViewRoot root)
> + {
> + Class<? extends UIViewRoot> rootClass = root.getClass();
> + //If the current root is not the real UIViewRoot object in faces then
> + //is no need to escape it. It is assumed it handles namespacing on its
> + //own. This is the same as the logic in the JSR-301 Bridge spec.
> + if(rootClass == UIViewRoot.class)
> + {
> + _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
> + root = new PortletNamingContainerUIViewRoot(root);
> + }
> +
> + //TODO: Do we need a warning here if the view root is not annotated
> + //properly? This could happen if another renderkit is involved and does
> + //not correctly implement JSR-301. This will NOT be an issue in Trin only
> + //environments.
> + return root;
> + }
> +
> }
>
>
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org