Hi,
On Feb 20, 2008 5:54 PM, Bernhard Huemer <[EMAIL PROTECTED]> 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" <[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 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
