thank!
and yes, jetty is a damn cool container ;-)
-Matthias
On Thu, Feb 21, 2008 at 3:13 AM, Scott O'Bryan <[EMAIL PROTECTED]> 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" <[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 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
