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









Reply via email to