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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:Hi Scott, On Feb 20, 2008 5:26 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:The Apache MVN website says this about providing a "compile only" library:"The scope you should use for this is |provided|. This indicates toMaven 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 inthe 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 ratherthis 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 -MatthiasScott 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 -MOn Feb 20, 2008 3:31 PM, Matthias Wessendorf <[EMAIL PROTECTED]> 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.xmlURL: 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
