Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-alpha
    • Fix Version/s: 1.0.0-alpha-2
    • Component/s: General
    • Labels:
      None

      Description

      The MyFaces Portlet Bridge is currently under active development for use as the R.I. for JSR-301. There are a log of challenges to setting up test cases and projects for this bridge which will hamper accurate development and testing. Therefore I think we need a series of demo project and project templates to be used with some official documentation that could guide the developer into quickly setting up a demo application using the Bridge so that various scenarios could be tested.

      I personally think that a self-contained HelloWorld! JSF application would be fine to start off with and would provide us the ability to expand upon in the future. It would be best if this application could be built either with MyFaces 1.2 (including the jars in the portlet war file) OR built without the Jars for use in a true J2EE5 compatible container. The ability to run in many portals would be ideal and this should be the goal of the bridge's project in general, but an initial test using Pluto is probably sufficient to start off with.

      1. portlet.xml
        1 kB
        Eduardo Millan

        Activity

        Hide
        Scott O'Bryan added a comment -

        Note, this has been applied to the Bridge 1.0 branch only at this time. We'll look at moving these over to the Bridge 2.0 branch before it's alpha release which will be a bit yet. It's dependent on Portlet 2.0 which isn't even in the mvn repos yet.

        Show
        Scott O'Bryan added a comment - Note, this has been applied to the Bridge 1.0 branch only at this time. We'll look at moving these over to the Bridge 2.0 branch before it's alpha release which will be a bit yet. It's dependent on Portlet 2.0 which isn't even in the mvn repos yet.
        Hide
        Scott O'Bryan added a comment -

        I've added some projects to handle this:

        examples
        examples/blank - a bare-bones application with mvn support for pluto/jetty which can be used to get started with portlet apps
        examples/demo - a demo project. Not much in there right now, but should provide a base framework going forward.

        I've also added a number of profiles and a jetty portal configuration that can either run the demos in jetty under pluto with either MyFaces or the R.I. All in all, a good start I think.

        Show
        Scott O'Bryan added a comment - I've added some projects to handle this: examples examples/blank - a bare-bones application with mvn support for pluto/jetty which can be used to get started with portlet apps examples/demo - a demo project. Not much in there right now, but should provide a base framework going forward. I've also added a number of profiles and a jetty portal configuration that can either run the demos in jetty under pluto with either MyFaces or the R.I. All in all, a good start I think.
        Hide
        Scott O'Bryan added a comment -

        Oops. The demo project still need to be created.. Reopening issue.

        Show
        Scott O'Bryan added a comment - Oops. The demo project still need to be created.. Reopening issue.
        Hide
        Scott O'Bryan added a comment -

        This does work because JSR-301 scopes everything to the "portlet-scope" wherease the MyFaces Bridge scopes everything to the application scope. As such, the use of the JSF usebean copies everything to the application scope by default.

        The JSR-301 Expert Group discussed this and enhancing useBean is outside of the scope of a bridge spec. Indeed using JSF mechanism's to create the managed bean would work correctly. There are two options. Using Portlet 2.0 spec, you can force Portlet Scope for the application. Likewise the usecase can be adjusted to EITHER pull the value from the application scope (which we provide EL for) or you can use a managed bean in the faces-config.

        In either case, we cannot handle this in a Bridge environment. This is considered a non-portlet friendly usage.

        Scott

        Show
        Scott O'Bryan added a comment - This does work because JSR-301 scopes everything to the "portlet-scope" wherease the MyFaces Bridge scopes everything to the application scope. As such, the use of the JSF usebean copies everything to the application scope by default. The JSR-301 Expert Group discussed this and enhancing useBean is outside of the scope of a bridge spec. Indeed using JSF mechanism's to create the managed bean would work correctly. There are two options. Using Portlet 2.0 spec, you can force Portlet Scope for the application. Likewise the usecase can be adjusted to EITHER pull the value from the application scope (which we provide EL for) or you can use a managed bean in the faces-config. In either case, we cannot handle this in a Bridge environment. This is considered a non-portlet friendly usage. Scott
        Hide
        Michael Freedman added a comment - - edited

        Eduardo,
        I think I know why the HelloDuke sample isn't working. However, I don't understand why it works in the MyFaces 1.2/bridge environment. Based on the following can you investigate why this works and let me know?

        The Problem relates to JSP vs. JSF EL evaluation. The HelloDuke sample creates the UserNameBean object via a JSP tag at session scope. By spec (JSR 168) this object is added to the portletSession's APPLICATION_SCOPE. However the JSF EL expression (used in the InputText field) resolves via the ExternalContext. It relies on the ScopedAttributeResolver as the explicit (session) object is not named. The JSR 301 ExternalContext session impl resolves at PORTLET_SCOPE. The two expression evaluators are looking at different scopes. This issue/limitation is explicitly cited in the specification (chapter 6).

        Because the jsp relies on scoped attribute lookup a fix would be to expand the Bridge's ELResolver to look the attribute up on the APPLICATION_SCOPE. Though this works for this sample, a potential problem of this is a property is prematurely found – obscures the correct usage/resolution. I will have to discuss with the EG to see if this "fix" should go into the spec.

        In the meantime I am a little stumped as to why this sample works for the MyFaces original/built-in bridge. Its ExternalContext seems to be implemented like the 301 EC pointing to the portlet_scope. And there doesn't appear to be any portlet based EL resolver to handle the stuff there. Can you dig into this a little and determine which ELResolver is resolving the UserNameBean in the JSF expression?
        Mike

        Show
        Michael Freedman added a comment - - edited Eduardo, I think I know why the HelloDuke sample isn't working. However, I don't understand why it works in the MyFaces 1.2/bridge environment. Based on the following can you investigate why this works and let me know? The Problem relates to JSP vs. JSF EL evaluation. The HelloDuke sample creates the UserNameBean object via a JSP tag at session scope. By spec (JSR 168) this object is added to the portletSession's APPLICATION_SCOPE. However the JSF EL expression (used in the InputText field) resolves via the ExternalContext. It relies on the ScopedAttributeResolver as the explicit (session) object is not named. The JSR 301 ExternalContext session impl resolves at PORTLET_SCOPE. The two expression evaluators are looking at different scopes. This issue/limitation is explicitly cited in the specification (chapter 6). Because the jsp relies on scoped attribute lookup a fix would be to expand the Bridge's ELResolver to look the attribute up on the APPLICATION_SCOPE. Though this works for this sample, a potential problem of this is a property is prematurely found – obscures the correct usage/resolution. I will have to discuss with the EG to see if this "fix" should go into the spec. In the meantime I am a little stumped as to why this sample works for the MyFaces original/built-in bridge. Its ExternalContext seems to be implemented like the 301 EC pointing to the portlet_scope. And there doesn't appear to be any portlet based EL resolver to handle the stuff there. Can you dig into this a little and determine which ELResolver is resolving the UserNameBean in the JSF expression? Mike
        Hide
        Michael Freedman added a comment -

        Okay, I canceled the patch for you, just to clean things up. Does this mean you were able to get your/a sample up and running? What Faces did you use? What portlet container? What Web server?

        Show
        Michael Freedman added a comment - Okay, I canceled the patch for you, just to clean things up. Does this mean you were able to get your/a sample up and running? What Faces did you use? What portlet container? What Web server?
        Hide
        Christian Raschka added a comment -

        Sorry, the patch available status was my failure and I didn't know how to cancel this operation.

        I will upload my example in the next days ...

        Show
        Christian Raschka added a comment - Sorry, the patch available status was my failure and I didn't know how to cancel this operation. I will upload my example in the next days ...
        Hide
        Michael Freedman added a comment -

        What is the status here? Its marked patch available but the only attached file is a portlet.xml? There also seem to be two conversations going on. Could you guys either upload or e-mail the samples (in particular the ones not working) to me so I can test them directly in my environment? Make sure you send me the web.xml/face-config.xml you are using in addition to the other stuff. I want to first rule out the bridge before looking to see if there are issues related to running the bridge in a Tomcat/Pluto environment.

        Note: The patch Scott refers to will impact images/other resources that are referenced by absolute links. It shouldn't impact navigation.

        By the way, thanks for taking this effort on. However, I hope you aren't beating your heads against a wall. I am very happy to help out to make sure we get you both up and running smoothly so you can help this project.
        Mike

        Show
        Michael Freedman added a comment - What is the status here? Its marked patch available but the only attached file is a portlet.xml? There also seem to be two conversations going on. Could you guys either upload or e-mail the samples (in particular the ones not working) to me so I can test them directly in my environment? Make sure you send me the web.xml/face-config.xml you are using in addition to the other stuff. I want to first rule out the bridge before looking to see if there are issues related to running the bridge in a Tomcat/Pluto environment. Note: The patch Scott refers to will impact images/other resources that are referenced by absolute links. It shouldn't impact navigation. By the way, thanks for taking this effort on. However, I hope you aren't beating your heads against a wall. I am very happy to help out to make sure we get you both up and running smoothly so you can help this project. Mike
        Hide
        Christian Raschka added a comment -

        Hi Scott,

        I know, that there will be two versions of the spec. I am a new member of the JSR 301 EG and want to participate in development of the spec and the RI. I am also working on the RI of JSR 286.

        Currently I am writing my diploma thesis about JSR 286 (and a bit about 301).

        My first thing, was to test the actual impl of the Bridge, but I was wondering that the navigation failed, but i didn't know, if it was my mistakte or not. Please let me know, if I can do some testing or helping.

        Show
        Christian Raschka added a comment - Hi Scott, I know, that there will be two versions of the spec. I am a new member of the JSR 301 EG and want to participate in development of the spec and the RI. I am also working on the RI of JSR 286. Currently I am writing my diploma thesis about JSR 286 (and a bit about 301). My first thing, was to test the actual impl of the Bridge, but I was wondering that the navigation failed, but i didn't know, if it was my mistakte or not. Please let me know, if I can do some testing or helping.
        Hide
        Eduardo Millan added a comment -

        Correct, I never got this work with the 301 bridge, I have a lot of JSF portlets working with the portlet-bridges-myfaces and page navigation has no problem.

        Of course, I am here to help. Tell me when the Michael Freedman pacth is ready and I will check again the helloDuke sample.

        Show
        Eduardo Millan added a comment - Correct, I never got this work with the 301 bridge, I have a lot of JSF portlets working with the portlet-bridges-myfaces and page navigation has no problem. Of course, I am here to help. Tell me when the Michael Freedman pacth is ready and I will check again the helloDuke sample.
        Hide
        Scott O'Bryan added a comment -

        Hey Eduardo,

        Thanks for doing some of this demo work. I do have a few questions...

        You never got this to work with the 301 bridge (this project), correct? I'm assuming that the "previous MyFaces Portlet Bridge" you are referring to it the one build into MyFaces. We have had some issues with URL re-writing because the 301 vastly expands upon the requirements for this compared to the other bridges, but the fact that the simple case isn't working concerns me a bit and it is something that we would really need to fix. Next week Michael Freedman should be checking in a patch he wrote to help with URL rewiting. When he does this, could you check your usecase again to make sure the navigation functions?

        Scott

        Show
        Scott O'Bryan added a comment - Hey Eduardo, Thanks for doing some of this demo work. I do have a few questions... You never got this to work with the 301 bridge (this project), correct? I'm assuming that the "previous MyFaces Portlet Bridge" you are referring to it the one build into MyFaces. We have had some issues with URL re-writing because the 301 vastly expands upon the requirements for this compared to the other bridges, but the fact that the simple case isn't working concerns me a bit and it is something that we would really need to fix. Next week Michael Freedman should be checking in a patch he wrote to help with URL rewiting. When he does this, could you check your usecase again to make sure the navigation functions? Scott
        Hide
        Eduardo Millan added a comment -

        Attached is the sample portlet.xml file I am using. I cannot navigate to another page either. This has been tested on Jetspeed 2.1.2 with the former myfaces portlet bridge and it works.

        Container: Jetspeed 2.1.2 on Tomcat 6
        JSF version: 1.2.

        Please, tell me if you need any other information about this.

        Show
        Eduardo Millan added a comment - Attached is the sample portlet.xml file I am using. I cannot navigate to another page either. This has been tested on Jetspeed 2.1.2 with the former myfaces portlet bridge and it works. Container: Jetspeed 2.1.2 on Tomcat 6 JSF version: 1.2. Please, tell me if you need any other information about this.
        Hide
        Scott O'Bryan added a comment -

        Christian,

        This SHOULD work with Pluto2, but the JSR-301 is going to have another spec which will cover JSR-286 and I imagine we'll split off a branch on the bridge project to cover this second spec as well. If you do get a simple example ironed out and want to check it in, I would be much appreciative if you could also test it on pluto 1. The JSR-286 compatibility branch for JSR-301 will, of course, be tested on a minimum of Pluto2.

        Thanks!
        Scott

        Show
        Scott O'Bryan added a comment - Christian, This SHOULD work with Pluto2, but the JSR-301 is going to have another spec which will cover JSR-286 and I imagine we'll split off a branch on the bridge project to cover this second spec as well. If you do get a simple example ironed out and want to check it in, I would be much appreciative if you could also test it on pluto 1. The JSR-286 compatibility branch for JSR-301 will, of course, be tested on a minimum of Pluto2. Thanks! Scott
        Hide
        Christian Raschka added a comment -

        Hi, i am currently working on getting a sample jsf portlet application to work with Tomcat6 and Pluto2.
        I know, that the current implementation is for jsr 168 only, but this has to work with Pluto2, too.
        It seems that everything is ok (no exeptions) but i can't navigate to another page.

        Has anyone a working example I can test with?

        Maybe I can help with the implementation and / or documentation of the demo and the bridge, if i could acquire more knowledge about the Bridge.

        Show
        Christian Raschka added a comment - Hi, i am currently working on getting a sample jsf portlet application to work with Tomcat6 and Pluto2. I know, that the current implementation is for jsr 168 only, but this has to work with Pluto2, too. It seems that everything is ok (no exeptions) but i can't navigate to another page. Has anyone a working example I can test with? Maybe I can help with the implementation and / or documentation of the demo and the bridge, if i could acquire more knowledge about the Bridge.
        Hide
        Eduardo Millan added a comment -

        Currently, I am setting up Jetspeed 2.1.2 on Tomcat 6 for testing the sample applications. Now trying to implement the helloDuke sample.

        The reason to use Tomcat 6 is, as far as I now, the Portlet Bridge only runs on JSP 2.1 because of JSF 1.2.

        Show
        Eduardo Millan added a comment - Currently, I am setting up Jetspeed 2.1.2 on Tomcat 6 for testing the sample applications. Now trying to implement the helloDuke sample. The reason to use Tomcat 6 is, as far as I now, the Portlet Bridge only runs on JSP 2.1 because of JSF 1.2.
        Hide
        Eduardo Millan added a comment -

        Yes Kito, that would be fine, go ahead and let me know when you're done.

        Show
        Eduardo Millan added a comment - Yes Kito, that would be fine, go ahead and let me know when you're done.
        Hide
        Kito D. Mann added a comment -

        I just got the guessnumber demo from Sun's portlet bridge to work with eXo 2.0. I'd be happy to add a guessNumber to the demos project. Let me know if I can help.

        Show
        Kito D. Mann added a comment - I just got the guessnumber demo from Sun's portlet bridge to work with eXo 2.0. I'd be happy to add a guessNumber to the demos project. Let me know if I can help.
        Hide
        Scott O'Bryan added a comment -

        That would certainly be a good start and would give us the framework in place to do more.

        Show
        Scott O'Bryan added a comment - That would certainly be a good start and would give us the framework in place to do more.
        Hide
        Eduardo Millan added a comment -

        I can help with this. This year I have been programming with Jetspeed 2, Websphere Portal 6 Express and JSF, to check the old portlet-bridge implementation may be useful to build portal-native projects.

        What about to create the typical "greetings" application?

        Show
        Eduardo Millan added a comment - I can help with this. This year I have been programming with Jetspeed 2, Websphere Portal 6 Express and JSF, to check the old portlet-bridge implementation may be useful to build portal-native projects. What about to create the typical "greetings" application?

          People

          • Assignee:
            Scott O'Bryan
            Reporter:
            Scott O'Bryan
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development