Pluto
  1. Pluto
  2. PLUTO-267

Implementation of the new Eventing Model

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1-286-COMPATIBILITY, 2.0.0
    • Fix Version/s: 1.1-286-COMPATIBILITY, 2.0.0
    • Component/s: None
    • Labels:
      None
    1. eventing.021106.patch
      47 kB
      Christian Raschka
    2. eventing.moreeventsbug.051106.patch
      25 kB
      Christian Raschka
    3. eventing_rev14.240507.patch
      484 kB
      Christian Raschka
    4. eventing.fire_event_proposal.070607.patch
      5 kB
      Tuomas Kiviaho
    5. eventing.fire_event_proposal.070607_2.patch
      0.8 kB
      Christian Raschka
    6. eventing.parameter_saving.070607.patch
      1 kB
      Tuomas Kiviaho
    7. eventing.parameter_propagation.070607.patch
      2 kB
      Tuomas Kiviaho
    8. eventing.provided_jaxb_proposal.020807.patch
      18 kB
      Tuomas Kiviaho
    9. eventing_0400807.patch
      70 kB
      Christian Raschka
    10. eventing_0400807_missingEventDefRefDD.patch
      2 kB
      Christian Raschka
    11. eventing.provided_jaxb_proposal.130807_r21.patch
      27 kB
      Tuomas Kiviaho
    12. eventing.provided_jaxb_proposal.150807_r22.patch
      27 kB
      Tuomas Kiviaho
    13. eventing.bugfixes.280807.patch
      7 kB
      Christian Raschka
    14. eventing.provided_jaxb_proposal.090907_r23.patch
      33 kB
      Tuomas Kiviaho
    15. eventing.provided_jaxb_proposal2.120907_rev574692.patch
      15 kB
      Tuomas Kiviaho
    16. eventAliases.070108.patch
      13 kB
      Christian Raschka
    There are no Sub-Tasks for this issue.

      Activity

      Hide
      Christian Raschka added a comment -

      Implementation of the new event model

      Show
      Christian Raschka added a comment - Implementation of the new event model
      Hide
      Craig Doremus added a comment -

      Applied patch in SVN revision 470984. Thank you, Christian!

      Show
      Craig Doremus added a comment - Applied patch in SVN revision 470984. Thank you, Christian!
      Hide
      Christian Raschka added a comment -

      This patch is a bugfix. Now it is possible to have more than one event.

      Also i have done some refactoring and commenting.

      Show
      Christian Raschka added a comment - This patch is a bugfix. Now it is possible to have more than one event. Also i have done some refactoring and commenting.
      Hide
      Craig Doremus added a comment -

      Applied second patch in SVN revision 473305. Thank you!

      Show
      Craig Doremus added a comment - Applied second patch in SVN revision 473305. Thank you!
      Hide
      Christian Raschka added a comment -
      • this updates to spec revision 14
      • it is now possible to set more than one event at once
      • there is one thread for all portlet windows, while the events for a portlet window are queued.
      • (I'll add more information about the eventing algorithm in the next days)

      ALL:

      • added JavaDoc

      Revision update & license headers:
      M portlet2-api/src/main/java/javax/portlet/UnavailableException.java
      M portlet2-api/src/main/java/javax/portlet/CacheControl.java
      M portlet2-api/src/main/java/javax/portlet/ValidatorException.java
      M portlet2-api/src/main/java/javax/portlet/PortalContext.java
      M portlet2-api/src/main/java/javax/portlet/ResourceResponse.java
      M portlet2-api/src/main/java/javax/portlet/PreferencesValidator.java
      M portlet2-api/src/main/java/javax/portlet/PortletResponse.java
      M portlet2-api/src/main/java/javax/portlet/PortletException.java
      M portlet2-api/src/main/java/javax/portlet/PortletRequestDispatcher.java
      M portlet2-api/src/main/java/javax/portlet/ResourceURL.java
      M portlet2-api/src/main/java/javax/portlet/PortletPreferences.java
      M portlet2-api/src/main/java/javax/portlet/PortletURL.java
      M portlet2-api/src/main/java/javax/portlet/PortletConfig.java
      A portlet2-api/src/main/java/javax/portlet/ClientDataRequest.java
      M portlet2-api/src/main/java/javax/portlet/Event.java
      M portlet2-api/src/main/java/javax/portlet/ActionRequest.java
      M portlet2-api/src/main/java/javax/portlet/GenericPortlet.java
      M portlet2-api/src/main/java/javax/portlet/WindowStateException.java
      M portlet2-api/src/main/java/javax/portlet/PortletSessionUtil.java
      M portlet2-api/src/main/java/javax/portlet/PortletContext.java
      M portlet2-api/src/main/java/javax/portlet/RenderResponse.java
      M portlet2-api/src/main/java/javax/portlet/ResourceServingPortlet.java
      M portlet2-api/src/main/java/javax/portlet/PortletSecurityException.java
      M portlet2-api/src/main/java/javax/portlet/EventResponse.java
      M portlet2-api/src/main/java/javax/portlet/ResourceRequest.java
      M portlet2-api/src/main/java/javax/portlet/PortletRequest.java
      M portlet2-api/src/main/java/javax/portlet/filter/RenderResponseWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/EventResponseWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/ResourceRequestWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/ResourceResponseWrapper.java
      D portlet2-api/src/main/java/javax/portlet/filter/FragmentFilter.java
      M portlet2-api/src/main/java/javax/portlet/filter/FilterConfig.java
      D portlet2-api/src/main/java/javax/portlet/filter/FragmentRequestWrapper.java
      A portlet2-api/src/main/java/javax/portlet/filter/package.html
      D portlet2-api/src/main/java/javax/portlet/filter/FragmentResponseWrapper.java
      D portlet2-api/src/main/java/javax/portlet/filter/Filter.java
      M portlet2-api/src/main/java/javax/portlet/filter/ActionRequestWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/FilterChain.java
      M portlet2-api/src/main/java/javax/portlet/filter/RenderRequestWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/EventRequestWrapper.java
      M portlet2-api/src/main/java/javax/portlet/filter/ActionResponseWrapper.java
      A portlet2-api/src/main/java/javax/portlet/MimeResponse.java
      M portlet2-api/src/main/java/javax/portlet/WindowState.java
      M portlet2-api/src/main/java/javax/portlet/PortletModeException.java
      A portlet2-api/src/main/java/javax/portlet/package.html
      M portlet2-api/src/main/java/javax/portlet/StateAwareResponse.java
      A portlet2-api/src/main/java/javax/portlet/portlet.xml.txt
      M portlet2-api/src/main/java/javax/portlet/RenderRequest.java
      M portlet2-api/src/main/java/javax/portlet/Portlet.java
      M portlet2-api/src/main/java/javax/portlet/ReadOnlyException.java
      M portlet2-api/src/main/java/javax/portlet/PortletSession.java
      M portlet2-api/src/main/java/javax/portlet/BaseURL.java
      M portlet2-api/src/main/java/javax/portlet/PortletMode.java
      M portlet2-api/pom.xml
      M pluto-container/src/main/java/org/apache/pluto/wrappers/RenderResponseWrapper.java
      M pluto-container/src/main/java/org/apache/pluto/wrappers/PortletResponseWrapper.java

      --------------

      M pluto-container/src/test/java/org/apache/pluto/spi/optional/UserInfoAttributesServicesImplTest.java

      • added needed method for mock object

      --------------

      M pluto-container/src/main/java/org/apache/pluto/core/PortletContainerImpl.java
      M pluto-container/src/main/java/org/apache/pluto/spi/EventProvider.java
      M pluto-container/src/main/java/org/apache/pluto/Constants.java
      M pluto-container/src/main/java/org/apache/pluto/EventContainer.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletConfigImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/EventRequestImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletContextImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/RenderResponseImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/CacheControlImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletResponseImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletRequestDispatcherImpl.java
      M pluto-container/src/main/java/org/apache/pluto/internal/impl/ResourceURLImpl.java

      • added an eventNumber, which is stored in the request, so we see, which event was fired
      • clear render parameter only once per request, (there could be more than one (eventing))
      • added a helper method (isAlreadyCleared(PortletRequest request))
      • new constant

      --------------

      M pluto-container/src/main/java/org/apache/pluto/internal/impl/StateAwareResponseImpl.java

      • clean up code

      --------------

      M pluto-container/src/main/resources/org/apache/pluto/core/pluto-configuration.properties

      • added comment of how to switch back to castor

      --------------

      M pluto-container/pom.xml
      M pluto-descriptor-api/pom.xml
      M pom.xml
      M pluto-descriptor-impl/pom.xml

      • changed version numbers

      --------------

      A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventAttribute.java
      A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/PortletWindowThread.java
      A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventList.java
      M pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventProviderImpl.java

      • new classes for eventing
      • changed the eventing algorithm, see jira issue Pluto-267 for more information

      --------------

      M pluto-descriptor-impl/src/test/java/org/apache/pluto/descriptors/services/jaxb/JaxBDescriptorServiceImplTest.java

      • removed printStrackTrace()
      Show
      Christian Raschka added a comment - this updates to spec revision 14 it is now possible to set more than one event at once there is one thread for all portlet windows, while the events for a portlet window are queued. (I'll add more information about the eventing algorithm in the next days) ALL: added JavaDoc Revision update & license headers: M portlet2-api/src/main/java/javax/portlet/UnavailableException.java M portlet2-api/src/main/java/javax/portlet/CacheControl.java M portlet2-api/src/main/java/javax/portlet/ValidatorException.java M portlet2-api/src/main/java/javax/portlet/PortalContext.java M portlet2-api/src/main/java/javax/portlet/ResourceResponse.java M portlet2-api/src/main/java/javax/portlet/PreferencesValidator.java M portlet2-api/src/main/java/javax/portlet/PortletResponse.java M portlet2-api/src/main/java/javax/portlet/PortletException.java M portlet2-api/src/main/java/javax/portlet/PortletRequestDispatcher.java M portlet2-api/src/main/java/javax/portlet/ResourceURL.java M portlet2-api/src/main/java/javax/portlet/PortletPreferences.java M portlet2-api/src/main/java/javax/portlet/PortletURL.java M portlet2-api/src/main/java/javax/portlet/PortletConfig.java A portlet2-api/src/main/java/javax/portlet/ClientDataRequest.java M portlet2-api/src/main/java/javax/portlet/Event.java M portlet2-api/src/main/java/javax/portlet/ActionRequest.java M portlet2-api/src/main/java/javax/portlet/GenericPortlet.java M portlet2-api/src/main/java/javax/portlet/WindowStateException.java M portlet2-api/src/main/java/javax/portlet/PortletSessionUtil.java M portlet2-api/src/main/java/javax/portlet/PortletContext.java M portlet2-api/src/main/java/javax/portlet/RenderResponse.java M portlet2-api/src/main/java/javax/portlet/ResourceServingPortlet.java M portlet2-api/src/main/java/javax/portlet/PortletSecurityException.java M portlet2-api/src/main/java/javax/portlet/EventResponse.java M portlet2-api/src/main/java/javax/portlet/ResourceRequest.java M portlet2-api/src/main/java/javax/portlet/PortletRequest.java M portlet2-api/src/main/java/javax/portlet/filter/RenderResponseWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/EventResponseWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/ResourceRequestWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/ResourceResponseWrapper.java D portlet2-api/src/main/java/javax/portlet/filter/FragmentFilter.java M portlet2-api/src/main/java/javax/portlet/filter/FilterConfig.java D portlet2-api/src/main/java/javax/portlet/filter/FragmentRequestWrapper.java A portlet2-api/src/main/java/javax/portlet/filter/package.html D portlet2-api/src/main/java/javax/portlet/filter/FragmentResponseWrapper.java D portlet2-api/src/main/java/javax/portlet/filter/Filter.java M portlet2-api/src/main/java/javax/portlet/filter/ActionRequestWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/FilterChain.java M portlet2-api/src/main/java/javax/portlet/filter/RenderRequestWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/EventRequestWrapper.java M portlet2-api/src/main/java/javax/portlet/filter/ActionResponseWrapper.java A portlet2-api/src/main/java/javax/portlet/MimeResponse.java M portlet2-api/src/main/java/javax/portlet/WindowState.java M portlet2-api/src/main/java/javax/portlet/PortletModeException.java A portlet2-api/src/main/java/javax/portlet/package.html M portlet2-api/src/main/java/javax/portlet/StateAwareResponse.java A portlet2-api/src/main/java/javax/portlet/portlet.xml.txt M portlet2-api/src/main/java/javax/portlet/RenderRequest.java M portlet2-api/src/main/java/javax/portlet/Portlet.java M portlet2-api/src/main/java/javax/portlet/ReadOnlyException.java M portlet2-api/src/main/java/javax/portlet/PortletSession.java M portlet2-api/src/main/java/javax/portlet/BaseURL.java M portlet2-api/src/main/java/javax/portlet/PortletMode.java M portlet2-api/pom.xml M pluto-container/src/main/java/org/apache/pluto/wrappers/RenderResponseWrapper.java M pluto-container/src/main/java/org/apache/pluto/wrappers/PortletResponseWrapper.java -------------- M pluto-container/src/test/java/org/apache/pluto/spi/optional/UserInfoAttributesServicesImplTest.java added needed method for mock object -------------- M pluto-container/src/main/java/org/apache/pluto/core/PortletContainerImpl.java M pluto-container/src/main/java/org/apache/pluto/spi/EventProvider.java M pluto-container/src/main/java/org/apache/pluto/Constants.java M pluto-container/src/main/java/org/apache/pluto/EventContainer.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletConfigImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/EventRequestImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletContextImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/RenderResponseImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/CacheControlImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletResponseImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/PortletRequestDispatcherImpl.java M pluto-container/src/main/java/org/apache/pluto/internal/impl/ResourceURLImpl.java added an eventNumber, which is stored in the request, so we see, which event was fired clear render parameter only once per request, (there could be more than one (eventing)) added a helper method (isAlreadyCleared(PortletRequest request)) new constant -------------- M pluto-container/src/main/java/org/apache/pluto/internal/impl/StateAwareResponseImpl.java clean up code -------------- M pluto-container/src/main/resources/org/apache/pluto/core/pluto-configuration.properties added comment of how to switch back to castor -------------- M pluto-container/pom.xml M pluto-descriptor-api/pom.xml M pom.xml M pluto-descriptor-impl/pom.xml changed version numbers -------------- A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventAttribute.java A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/PortletWindowThread.java A pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventList.java M pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/EventProviderImpl.java new classes for eventing changed the eventing algorithm, see jira issue Pluto-267 for more information -------------- M pluto-descriptor-impl/src/test/java/org/apache/pluto/descriptors/services/jaxb/JaxBDescriptorServiceImplTest.java removed printStrackTrace()
      Hide
      Christian Raschka added a comment -

      Information about the new eventing algorithm:

      Portlets can fire events during their action or event phase (processAction()/processEvent()).
      Furthermore container events exist to give notice that modes or parameter have changed. Those
      events are sent to all interested portlets (to be precise PortletWindows). To be able to process
      events the portlets have to declare it in the portlet.xml (<supported-processing-event>).
      After the action phase has ended (at the end of doAction()) a message is sent to the
      EventProvider (fireEvent()). Thereupon the EventProvider begins to send events.

      Now the provider spools those events in a loop until all events are processed (including newly
      added events in the processEvent() method). For that purpose all events are entered into an
      event list and the flag notProcessed is set. After an event is processd the flag is set to false.

      Description of the loop body:
      An arbitrary event is taken. Then all interested PortletWindows are seeked for this event in the
      registry. A new thread will be applied to all of those PortletWindows (if it is not done yet).
      Within this thread every event will be fired, which is collected for that PortletWindow, by calling
      the event container's (PortletContainerImpl's) fireEvent() method.

      After the loop the algorithm waits until all threads are processed. Now the render phase can start,
      because all events are processed. The prior parameter will only be deleted at the first time (flag
      in the request), to enable that different render parameter can be set in dissimilar events in the same
      request.

      Unfortunatly I have to apply a trick until now, to make firing of events during the event processing
      possible:
      Within the loop the thread is created and started. If it is a normal flow, than the impression arises
      that there are no events which should be processed. Therefore I wait a reasonable time, before
      the need of doing something is checked. In theory it can happen that events are not noticed (if
      processEvent() takes too much time), but on that you cannot rely according to the specification.
      This problem has to be solved in the future.

      It is also possible to specify how many events are allowed to be on the event list. So an infinte loop
      of events can be avoided.

      In fact it could be possible that an event call takes an infinite time and the thread does not end, too.
      Then the program flow cannot switch over to the render phase.

      Any comments or questions are welcome

      Show
      Christian Raschka added a comment - Information about the new eventing algorithm: Portlets can fire events during their action or event phase (processAction()/processEvent()). Furthermore container events exist to give notice that modes or parameter have changed. Those events are sent to all interested portlets (to be precise PortletWindows). To be able to process events the portlets have to declare it in the portlet.xml (<supported-processing-event>). After the action phase has ended (at the end of doAction()) a message is sent to the EventProvider (fireEvent()). Thereupon the EventProvider begins to send events. Now the provider spools those events in a loop until all events are processed (including newly added events in the processEvent() method). For that purpose all events are entered into an event list and the flag notProcessed is set. After an event is processd the flag is set to false. Description of the loop body: An arbitrary event is taken. Then all interested PortletWindows are seeked for this event in the registry. A new thread will be applied to all of those PortletWindows (if it is not done yet). Within this thread every event will be fired, which is collected for that PortletWindow, by calling the event container's (PortletContainerImpl's) fireEvent() method. After the loop the algorithm waits until all threads are processed. Now the render phase can start, because all events are processed. The prior parameter will only be deleted at the first time (flag in the request), to enable that different render parameter can be set in dissimilar events in the same request. Unfortunatly I have to apply a trick until now, to make firing of events during the event processing possible: Within the loop the thread is created and started. If it is a normal flow, than the impression arises that there are no events which should be processed. Therefore I wait a reasonable time, before the need of doing something is checked. In theory it can happen that events are not noticed (if processEvent() takes too much time), but on that you cannot rely according to the specification. This problem has to be solved in the future. It is also possible to specify how many events are allowed to be on the event list. So an infinte loop of events can be avoided. In fact it could be possible that an event call takes an infinite time and the thread does not end, too. Then the program flow cannot switch over to the render phase. Any comments or questions are welcome
      Hide
      Tuomas Kiviaho added a comment -

      Here's a small proposal/patch how to simplify the event firing. I maybe missing something, but to me carrying index and event name extracted already from the event itself is a more complex than just passing the event itself to the EventContainer.fireEvent method. This would also make the event providers requirement to serve a ordered collection of events to the event request obsolete. This removes the need of handling certain concurrency issues if providing of registered events could be removed completely from driver api.

      Show
      Tuomas Kiviaho added a comment - Here's a small proposal/patch how to simplify the event firing. I maybe missing something, but to me carrying index and event name extracted already from the event itself is a more complex than just passing the event itself to the EventContainer.fireEvent method. This would also make the event providers requirement to serve a ordered collection of events to the event request obsolete. This removes the need of handling certain concurrency issues if providing of registered events could be removed completely from driver api.
      Hide
      Christian Raschka added a comment -

      Thank you Tuomas for your nice proposal. I have tested it, and it works fine for me. (I only had to change one line of code in the PortletEventThread class, see Patch).

      Could anyone commit these two patches please?

      Show
      Christian Raschka added a comment - Thank you Tuomas for your nice proposal. I have tested it, and it works fine for me. (I only had to change one line of code in the PortletEventThread class, see Patch). Could anyone commit these two patches please?
      Hide
      Tuomas Kiviaho added a comment -

      Here one bug patch as well (though I added this already, oh well). Spec rev. 15 states about render parameters as follows in PLT.11.1.1.2 Action, Resource and Event Request Parameters:

      "The set render parameters must be provided to the processEvent and render calls of at least the current client request. lxxiv"
      Since parameter saving is done after processing the events, the render parameters set in processAction are not provided to the events.

      Patch just moves the saving to be done before event processing.

      Show
      Tuomas Kiviaho added a comment - Here one bug patch as well (though I added this already, oh well). Spec rev. 15 states about render parameters as follows in PLT.11.1.1.2 Action, Resource and Event Request Parameters: "The set render parameters must be provided to the processEvent and render calls of at least the current client request. lxxiv" Since parameter saving is done after processing the events, the render parameters set in processAction are not provided to the events. Patch just moves the saving to be done before event processing.
      Hide
      Tuomas Kiviaho added a comment -

      The same paragraph describing render parameters also states.

      "The portlet-container must not propagate parameters received in an action, resource or event request to subsequent render requests of the portlet.lxxii"
      Event provider must take care of hiding these parameters before firing the event for processing which is only done currently in the rendering phase.

      There is already made wrapper for rendering purposes that hides the query parameters. A remnant part has been removed from it and the reason it to be obsolete is described in the trunk.

      Show
      Tuomas Kiviaho added a comment - The same paragraph describing render parameters also states. "The portlet-container must not propagate parameters received in an action, resource or event request to subsequent render requests of the portlet.lxxii" Event provider must take care of hiding these parameters before firing the event for processing which is only done currently in the rendering phase. There is already made wrapper for rendering purposes that hides the query parameters. A remnant part has been removed from it and the reason it to be obsolete is described in the trunk.
      Hide
      Torsten Dettborn added a comment -

      The patch "eventing_rev14.240507.patch " has been committed, the new revision number is 541884.

      Show
      Torsten Dettborn added a comment - The patch "eventing_rev14.240507.patch " has been committed, the new revision number is 541884.
      Hide
      Torsten Dettborn added a comment -

      The patch
      "eventing.fire_event_proposal.070607.patch
      +eventing.fire_event_proposal.070607_2.patch
      +eventing.parameter_propagation.070607.patch (2 kb)
      +eventing.parameter_saving.070607.patch "
      has been committed, the new revision number is 547160.

      Show
      Torsten Dettborn added a comment - The patch "eventing.fire_event_proposal.070607.patch +eventing.fire_event_proposal.070607_2.patch +eventing.parameter_propagation.070607.patch (2 kb) +eventing.parameter_saving.070607.patch " has been committed, the new revision number is 547160.
      Hide
      Tuomas Kiviaho added a comment -

      Portlet spec r21 states:

      "The default XML to Java mapping that every container must
      support is the JAXB mapping (see PLT.27).clv Portlet
      containers are free to support additional mapping mechanisms
      beyond the JAXB mapping."

      eventing.provided_jaxb_proposal.020807.patch moves responsibility of event payload handling completely to event provider away from portlet api implementation.classes. JAXB crunching and exception recovery are relocated to driver side. This allows additional mechanisms to be plugged in easily and doesn't enforce JAXB as per following sentence from the spec.

      "For optimization purposes in local Java runtime environments the
      portlet container can use Java Serialization or direct Java object
      passing for the event payload. The portlet must not make any
      assumptions on the mechanism the portlet container chooses to
      pass the event payload."

      Show
      Tuomas Kiviaho added a comment - Portlet spec r21 states: "The default XML to Java mapping that every container must support is the JAXB mapping (see PLT.27).clv Portlet containers are free to support additional mapping mechanisms beyond the JAXB mapping." eventing.provided_jaxb_proposal.020807.patch moves responsibility of event payload handling completely to event provider away from portlet api implementation.classes. JAXB crunching and exception recovery are relocated to driver side. This allows additional mechanisms to be plugged in easily and doesn't enforce JAXB as per following sentence from the spec. "For optimization purposes in local Java runtime environments the portlet container can use Java Serialization or direct Java object passing for the event payload. The portlet must not make any assumptions on the mechanism the portlet container chooses to pass the event payload."
      Hide
      Craig Doremus added a comment -

      Tuomas,
      Thanks for the latest patch. I applied the patch locally, but it threw a compile error on line 160 of EventProviderImpl.java. It appears that the EventDefinitionDD class does not have the getValueType() method in our SVN repository.

      I also had problems applying the patch to PortletWindowThread, but I think I was able to patch it manually. Please check the resulting run() method:

      public void run() {
      super.run();
      while (events.size() > 0) {
      HttpServletRequest req = new PortalServletRequest(eventProvider.getRequest(), this.portletWindow);
      HttpServletResponse res = eventProvider.getResponse();
      try {
      synchronized (this) {
      Event event = events.get(0);
      Object value = event.getValue();
      if (value instanceof XMLStreamReader) {
      XMLStreamReader xml = (XMLStreamReader) event.getValue();
      EventDefinitionDD eventDefinitionDD = eventProvider.getEventDefinition(event.getQName());
      try

      { // now test if object is jaxb ClassLoader loader = Thread.currentThread().getContextClassLoader(); Class<? extends Serializable> clazz = loader.loadClass(eventDefinitionDD.getJavaClass()).asSubclass(Serializable.class); JAXBContext jc = JAXBContext.newInstance(clazz); Unmarshaller unmarshaller = jc.createUnmarshaller(); unmarshaller.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler()); JAXBElement<? extends Serializable> result = unmarshaller.unmarshal(xml,clazz); event = new EventImpl(event.getQName(),result.getValue()); }

      catch (JAXBException e)

      { throw new IllegalStateException(e); } catch (ClassNotFoundException e) { throw new IllegalStateException(e); }

      }
      eventContainer.fireEvent(req, res, portletWindow, event);
      //wait();
      Thread.sleep(1);
      events.remove(0);
      }
      } catch (InterruptedException e)

      { System.out.println(); System.out.println("============interupted exception==============="); e.printStackTrace(); }

      catch (PortletException e)

      { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); }


      }
      }

      Show
      Craig Doremus added a comment - Tuomas, Thanks for the latest patch. I applied the patch locally, but it threw a compile error on line 160 of EventProviderImpl.java. It appears that the EventDefinitionDD class does not have the getValueType() method in our SVN repository. I also had problems applying the patch to PortletWindowThread, but I think I was able to patch it manually. Please check the resulting run() method: public void run() { super.run(); while (events.size() > 0) { HttpServletRequest req = new PortalServletRequest(eventProvider.getRequest(), this.portletWindow); HttpServletResponse res = eventProvider.getResponse(); try { synchronized (this) { Event event = events.get(0); Object value = event.getValue(); if (value instanceof XMLStreamReader) { XMLStreamReader xml = (XMLStreamReader) event.getValue(); EventDefinitionDD eventDefinitionDD = eventProvider.getEventDefinition(event.getQName()); try { // now test if object is jaxb ClassLoader loader = Thread.currentThread().getContextClassLoader(); Class<? extends Serializable> clazz = loader.loadClass(eventDefinitionDD.getJavaClass()).asSubclass(Serializable.class); JAXBContext jc = JAXBContext.newInstance(clazz); Unmarshaller unmarshaller = jc.createUnmarshaller(); unmarshaller.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler()); JAXBElement<? extends Serializable> result = unmarshaller.unmarshal(xml,clazz); event = new EventImpl(event.getQName(),result.getValue()); } catch (JAXBException e) { throw new IllegalStateException(e); } catch (ClassNotFoundException e) { throw new IllegalStateException(e); } } eventContainer.fireEvent(req, res, portletWindow, event); //wait(); Thread.sleep(1); events.remove(0); } } catch (InterruptedException e) { System.out.println(); System.out.println("============interupted exception==============="); e.printStackTrace(); } catch (PortletException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } }
      Hide
      Christian Raschka added a comment - - edited

      ( eventing_0400807.patch )

      Changes for Eventing:
      =====================

      • dynamical search of the portlets, which are receivers of events
      • only events, declared as "supported-publishing-events" are delivered
      • aliasing is implemented, e.g.:

      <event-defintion>
      <qname xmlns:x="http://x">events.x</.>
      <alias xmlns:y="http://y">events.y</alias>
      </.>

      <supported-processing-event><qname xmlns:y="http://y">events.y</.></.>

      Now if you set (send) the "

      {http://x}

      events.x" event, the portlet with this
      declaration will receive it.

      • DefaultNamespace is implemented
      • JAXB EventDefinitionDD class changed from java-class to value-type
        (new type EventDefinitionReferenceDD, (+ObjectFactory,+jaxb.index))
      • changed corresponding junit test

      Other small changes:
      ====================

      • removed some unnecessary methods out of the EventProvider SPI
      • implemented: supportedLocale -> List<String> instead of String
      • PortletConfig:
      • implemented: getProcessingEventQNames(), getPublishingEventQNames(),
        getSupportedLocales(),
      • PortletRequestImpl.getWindowID -> implemented
      • PortletSessionImpl.getMap implemented
      • ActionResponseWrapper: removed some (wrong) methods, implemented setEvent()
      • PortletRequestWrapper removed some (wrong) methods, implemented
        getPrivateParameterMap(), getPublicParameterMap
      • PortletResponseWrapper implemented addProperty()
      Show
      Christian Raschka added a comment - - edited ( eventing_0400807.patch ) Changes for Eventing: ===================== dynamical search of the portlets, which are receivers of events possiblity to group events (see https://issues.apache.org/jira/browse/PLUTO-374 ) only events, declared as "supported-publishing-events" are delivered aliasing is implemented, e.g.: <event-defintion> <qname xmlns:x="http://x">events.x</.> <alias xmlns:y="http://y">events.y</alias> </.> <supported-processing-event><qname xmlns:y="http://y">events.y</.></.> Now if you set (send) the " {http://x} events.x" event, the portlet with this declaration will receive it. DefaultNamespace is implemented JAXB EventDefinitionDD class changed from java-class to value-type (new type EventDefinitionReferenceDD, (+ObjectFactory,+jaxb.index)) changed corresponding junit test Other small changes: ==================== removed some unnecessary methods out of the EventProvider SPI implemented: supportedLocale -> List<String> instead of String PortletConfig: implemented: getProcessingEventQNames(), getPublishingEventQNames(), getSupportedLocales(), PortletRequestImpl.getWindowID -> implemented PortletSessionImpl.getMap implemented ActionResponseWrapper: removed some (wrong) methods, implemented setEvent() PortletRequestWrapper removed some (wrong) methods, implemented getPrivateParameterMap(), getPublicParameterMap PortletResponseWrapper implemented addProperty()
      Hide
      Craig Doremus added a comment -

      Christian,
      The EventDefinitionReferenceDD class appears to be missing from your patch (eventing_0400807.patch).

      Show
      Craig Doremus added a comment - Christian, The EventDefinitionReferenceDD class appears to be missing from your patch (eventing_0400807.patch).
      Hide
      Christian Raschka added a comment -

      grml ... everytime i forget to add the new files ;-(

      Show
      Christian Raschka added a comment - grml ... everytime i forget to add the new files ;-(
      Hide
      Ulrich Küster added a comment -

      The patches

      8. eventing_0400807.patch
      9. eventing_0400807_missingEventDefRefDD.patch

      have been committed, the new revision number is 562844.
      This solves problems in subtasks 372 and 374.

      Show
      Ulrich Küster added a comment - The patches 8. eventing_0400807.patch 9. eventing_0400807_missingEventDefRefDD.patch have been committed, the new revision number is 562844. This solves problems in subtasks 372 and 374.
      Hide
      Tuomas Kiviaho added a comment -

      Here's a fixed version of eventing.provided_jaxb_proposal against r21 (note trunk is already r22). I hope I manage to pull out a r22 compatible version this week. The idea is still the same with fixed cases mentioned by Craig. The idea is still to have responsibility of event creation/receiving completely in hands of EventProvider. There are still some methods left in setEvent that in my opinion belong to provider side, but bringing portletWindow nicely (just adding it to registerToFireEvent is not in alignment with semantics of other providers) there is big enough task to have it's own patch after this one.

      I've continued the path Christian already took with EventProvider cleanup on methods that no longer need to be public. Minor details: Usage of some private fields have been replaced with ones from parent in order to get rid of these duplicates in the future. Some left over methods from earlier specs have been removed as are private methods that no longer serve any purpose

      Show
      Tuomas Kiviaho added a comment - Here's a fixed version of eventing.provided_jaxb_proposal against r21 (note trunk is already r22). I hope I manage to pull out a r22 compatible version this week. The idea is still the same with fixed cases mentioned by Craig. The idea is still to have responsibility of event creation/receiving completely in hands of EventProvider. There are still some methods left in setEvent that in my opinion belong to provider side, but bringing portletWindow nicely (just adding it to registerToFireEvent is not in alignment with semantics of other providers) there is big enough task to have it's own patch after this one. I've continued the path Christian already took with EventProvider cleanup on methods that no longer need to be public. Minor details: Usage of some private fields have been replaced with ones from parent in order to get rid of these duplicates in the future. Some left over methods from earlier specs have been removed as are private methods that no longer serve any purpose
      Hide
      Tuomas Kiviaho added a comment -

      eventing.provided_jaxb_proposal meant for r21 is apparently r22 compatible as well since there was only changes to portlet api

      Show
      Tuomas Kiviaho added a comment - eventing.provided_jaxb_proposal meant for r21 is apparently r22 compatible as well since there was only changes to portlet api
      Hide
      Christian Raschka added a comment -

      Tuomas,

      thank you for your work and your patches. I've tried to apply your patch, but it seems that the PortalCallbackProvider and its implementation is missing?!

      Show
      Christian Raschka added a comment - Tuomas, thank you for your work and your patches. I've tried to apply your patch, but it seems that the PortalCallbackProvider and its implementation is missing?!
      Hide
      Tuomas Kiviaho added a comment -

      EventProvider provider = callback.getEventProvider(

      • getHttpServletRequest(),getHttpServletResponse(), container);
        + getHttpServletRequest(),getInternalPortletWindow());

      It seems that I've goofed up the patch by adding stuff from the next intended proposal. I'll checkout 1.1-286-COMPATIBILITY and repatch this proposal. Sorry about not being thorough.

      Show
      Tuomas Kiviaho added a comment - EventProvider provider = callback.getEventProvider( getHttpServletRequest(),getHttpServletResponse(), container); + getHttpServletRequest(),getInternalPortletWindow()); It seems that I've goofed up the patch by adding stuff from the next intended proposal. I'll checkout 1.1-286-COMPATIBILITY and repatch this proposal. Sorry about not being thorough.
      Hide
      Tuomas Kiviaho added a comment -

      eventing.provided_jaxb_proposal.150807_r22.patch: Fixed StateAwareResponseImpl having faulty getEventProvider parameters. EventProviderImpl had somehow lost PortletApplicationConfigs retrieval.

      Show
      Tuomas Kiviaho added a comment - eventing.provided_jaxb_proposal.150807_r22.patch: Fixed StateAwareResponseImpl having faulty getEventProvider parameters. EventProviderImpl had somehow lost PortletApplicationConfigs retrieval.
      Hide
      Christian Raschka added a comment -

      This patch resolves a small bug in the getDefaultNamespace behavior and adds a null pointer check if the event payload is not given.

      Show
      Christian Raschka added a comment - This patch resolves a small bug in the getDefaultNamespace behavior and adds a null pointer check if the event payload is not given.
      Hide
      Torsten Dettborn added a comment -

      I add the 1.1-286-trunk-merge version to the versions.

      Show
      Torsten Dettborn added a comment - I add the 1.1-286-trunk-merge version to the versions.
      Hide
      Torsten Dettborn added a comment -

      I committed eventing.bugfixes.280807.patch for 1.1-286-COMPATIBILITY Version. The new rev. number is: 570757

      Show
      Torsten Dettborn added a comment - I committed eventing.bugfixes.280807.patch for 1.1-286-COMPATIBILITY Version. The new rev. number is: 570757
      Hide
      Craig Doremus added a comment -

      Applied eventing.bugfixes.280807.patch to 1.1-286-trunk-merge branch in SVN rev 570946.

      Show
      Craig Doremus added a comment - Applied eventing.bugfixes.280807.patch to 1.1-286-trunk-merge branch in SVN rev 570946.
      Hide
      Tuomas Kiviaho added a comment -

      Christian,

      Have you been able to apply the patch meant to push JAXB handling completely over to the EventProvider. I'd be glad to repatch it against current revisions if it has a chance of being applied. I'm a bit stuck here since the current StateAwareResponseImpl and EventRequestImpl require JAXB capable classes when producing/consuming events.

      Show
      Tuomas Kiviaho added a comment - Christian, Have you been able to apply the patch meant to push JAXB handling completely over to the EventProvider. I'd be glad to repatch it against current revisions if it has a chance of being applied. I'm a bit stuck here since the current StateAwareResponseImpl and EventRequestImpl require JAXB capable classes when producing/consuming events.
      Hide
      Christian Raschka added a comment -

      Hi Tuomas,

      thx for your work so far. I have tested your patch and it looks fine with me. However I am not able to commit it, because I havn't got the rights. Maybe a committer could do this.

      Show
      Christian Raschka added a comment - Hi Tuomas, thx for your work so far. I have tested your patch and it looks fine with me. However I am not able to commit it, because I havn't got the rights. Maybe a committer could do this.
      Hide
      Tuomas Kiviaho added a comment -

      Here's a fresh eventing.provided_jaxb_proposal.090907_r23.patch I promised to deliver. It is basically the same as the previous ones but I had to tweak the org.apache.pluto.internal.impl.StateAwareResponseImpl.isDeclaredAsPublishingEvent(QName) a bit to meet the event provider interface that has been narrowed down. This method and isValueInstanceOfDefinedClass could be pushed to provider side as well in order maximize extensibility (value-type could be interface or sub type etc.), but that would have bloated the patch too much at the moment.

      Tuomas

      Show
      Tuomas Kiviaho added a comment - Here's a fresh eventing.provided_jaxb_proposal.090907_r23.patch I promised to deliver. It is basically the same as the previous ones but I had to tweak the org.apache.pluto.internal.impl.StateAwareResponseImpl.isDeclaredAsPublishingEvent(QName) a bit to meet the event provider interface that has been narrowed down. This method and isValueInstanceOfDefinedClass could be pushed to provider side as well in order maximize extensibility (value-type could be interface or sub type etc.), but that would have bloated the patch too much at the moment. Tuomas
      Hide
      Torsten Dettborn added a comment -

      Applied patch eventing.provided_jaxb_proposal.090907_r23.patch in 1.1-286-COMPATIBILITY version. New rev. 574206.

      Show
      Torsten Dettborn added a comment - Applied patch eventing.provided_jaxb_proposal.090907_r23.patch in 1.1-286-COMPATIBILITY version. New rev. 574206.
      Hide
      Tuomas Kiviaho added a comment -

      Here's the second part of provided JAXB proposal. Decision whether to allow event to be published or not is pushed to provider side as well. Reference to portlet window or at least descriptor is required in provider in order to do this so instead of simply adding it as parameter wasn't an option because that same parameter value may be required when firing portlets as well. Callback service contains already factory methods that implement this approach so I used the same technique. This gives also the possibility to cache portlet window (portletdd) derived data into the provider itself while remaining same event queue across the request. Clone could also be cached based on portlet window id, but I tried to keep the patch as simple as possible so EventProviderImpl again just got logic from StateAwareImpl with minimal changes.

      BTW: I hope you don't remove the other getEventProvider method in the future, because I find it very useful for other purposes than what it has been currently used. Giving PortletContainer as a parameter for that one might come handy, but that's another issue then...

      Show
      Tuomas Kiviaho added a comment - Here's the second part of provided JAXB proposal. Decision whether to allow event to be published or not is pushed to provider side as well. Reference to portlet window or at least descriptor is required in provider in order to do this so instead of simply adding it as parameter wasn't an option because that same parameter value may be required when firing portlets as well. Callback service contains already factory methods that implement this approach so I used the same technique. This gives also the possibility to cache portlet window (portletdd) derived data into the provider itself while remaining same event queue across the request. Clone could also be cached based on portlet window id, but I tried to keep the patch as simple as possible so EventProviderImpl again just got logic from StateAwareImpl with minimal changes. BTW: I hope you don't remove the other getEventProvider method in the future, because I find it very useful for other purposes than what it has been currently used. Giving PortletContainer as a parameter for that one might come handy, but that's another issue then...
      Hide
      Torsten Dettborn added a comment -

      Committed patchs:

      eventing.provided_jaxb_proposal2.120907_rev574692.patch from JIRA 267,

      taglib_091407.patch from JIRA 433 ,
      response.patch from JIRA 432 .

      New revision version: 575619

      Show
      Torsten Dettborn added a comment - Committed patchs: eventing.provided_jaxb_proposal2.120907_rev574692.patch from JIRA 267, taglib_091407.patch from JIRA 433 , response.patch from JIRA 432 . New revision version: 575619
      Hide
      Craig Doremus added a comment -

      Applied eventing.provided_jaxb_proposal.090907_r23.patch to 1.1-286-trunk-merge branch in SVN rev 577690. Thanks, Tuomas.

      Show
      Craig Doremus added a comment - Applied eventing.provided_jaxb_proposal.090907_r23.patch to 1.1-286-trunk-merge branch in SVN rev 577690. Thanks, Tuomas.
      Hide
      Craig Doremus added a comment -

      Applied eventing.provided_jaxb_proposal2.120907_rev574692.patch to 1.1-286-trunk-merge branch. Thanks, Tuomas!

      Show
      Craig Doremus added a comment - Applied eventing.provided_jaxb_proposal2.120907_rev574692.patch to 1.1-286-trunk-merge branch. Thanks, Tuomas!
      Hide
      Christian Raschka added a comment -

      After successful fighting against a jaxb issue i have a problem with unmarhalling the events at the EventProvider:

      At this this time i havn't the right classloader for the event payloads. The event payloads have to be unmarshalled into the right object lying in the web application of the receiving event. But the EventProvider doesn't know this application / classloader and therefor a ClassNotFoundException occurs. If the unmarshalling is done at the container everything is fine.

      Any ideas how to solve this issue?

      Show
      Christian Raschka added a comment - After successful fighting against a jaxb issue i have a problem with unmarhalling the events at the EventProvider: At this this time i havn't the right classloader for the event payloads. The event payloads have to be unmarshalled into the right object lying in the web application of the receiving event. But the EventProvider doesn't know this application / classloader and therefor a ClassNotFoundException occurs. If the unmarshalling is done at the container everything is fine. Any ideas how to solve this issue?
      Hide
      Torsten Dettborn added a comment -

      I want to bring this issue on top of the mailing- list for discussion. Christian has tests his implementation on the old implementation, before the patch from Tuomas has committed(all was fine). From design questions it is right that all functionality is in the portal, but the question is, how we can get the classloader from the portlet app. This we need for the unmarshalling, as Christian has written.

      Show
      Torsten Dettborn added a comment - I want to bring this issue on top of the mailing- list for discussion. Christian has tests his implementation on the old implementation, before the patch from Tuomas has committed(all was fine). From design questions it is right that all functionality is in the portal, but the question is, how we can get the classloader from the portlet app. This we need for the unmarshalling, as Christian has written.
      Hide
      Craig Doremus added a comment -

      Torsten, can you or Christian provide more details about exactly where the problem is occurring? A stack trace would be helpful.

      Also, if there is a JUnit test that would illuminate this issue, please commit it to SVN (noting here the svn rev) or post a patch file here. Thanks.

      Show
      Craig Doremus added a comment - Torsten, can you or Christian provide more details about exactly where the problem is occurring? A stack trace would be helpful. Also, if there is a JUnit test that would illuminate this issue, please commit it to SVN (noting here the svn rev) or post a patch file here. Thanks.
      Hide
      Christian Raschka added a comment -
      • this patch fixes the alias handling
      • moved some methods (contains() & getAllAliases()) to the appropriate DD classes
        NOTE: I don't know exactly if it's a good idea to move functionality in the DD classes, but to my mind this should be there. Maybe you could comment this. I think there are a lot of more functionality we could move there. With the benefit, that the EventProviderImpl (and other) classes will be much cleaner.
      • now the fired event payload MUST have a @XmlRootElement Annotation (marshalling is now done without jaxb framing), more queries (type etc.) will be done soon ...
      Show
      Christian Raschka added a comment - this patch fixes the alias handling moved some methods (contains() & getAllAliases()) to the appropriate DD classes NOTE: I don't know exactly if it's a good idea to move functionality in the DD classes, but to my mind this should be there. Maybe you could comment this. I think there are a lot of more functionality we could move there. With the benefit, that the EventProviderImpl (and other) classes will be much cleaner. now the fired event payload MUST have a @XmlRootElement Annotation (marshalling is now done without jaxb framing), more queries (type etc.) will be done soon ...
      Hide
      Ate Douma added a comment -

      Implemented

      Show
      Ate Douma added a comment - Implemented

        People

        • Assignee:
          Unassigned
          Reporter:
          Christian Raschka
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development