myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernhard Huemer <bernhard.hue...@gmail.com>
Subject 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
Date Thu, 21 Feb 2008 06:50:45 GMT
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" <darkarena@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" <darkarena@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" <matzew@apache.org> wrote:
>>>>> Hi Scott,
>>>>>
>>>>> On Feb 20, 2008 5:26 PM, Scott O'Bryan <darkarena@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 <matzew@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 


Mime
View raw message