Portlet Container 1.2 changes

[julien1]

I keep track here of the main refactorings done to the project in order to facilitate its integration in JBoss Portal 2.x project.

[julien1]

Renamed RenderResponse to UpdateNavigationalStateResponse since it is really what it does. That stroke me when I introduced event feature since the delivery of events can update the nav state the same way the action phase does.

[julien1]

Introduced StateResponse as parent class of UpdateNavigationalStateResponse and RedirectionResponse since both classes can specify delivery of events after/before the response action is executed by the portal.

[julien1]

1/ renamed RequestContext to ServerContext as it provides services delivered by the server

2/ introduced RequestContext that contains the data provided by the HTTP client request when it connects using a POST with a non application/x-www-form-urlencoded content type. That was before on the ActionContext interface but it needs to be decoupled from it in order to be usable for the Resource requests.

[julien1]

Removed PortletInvocation.getPortletContext() since now it is possible override getContext() with a PortletInvocationContext type.

XXXInvocation now returns XXXInvocationContext related interfaces using the same mechanism. For instance:

 public RenderInvocation extends PortletInvocation {
 ...
 public RenderContext getContext()
 {
 return renderContext; // instead of InvocationContext
 }

[julien1]

In order to implement the "next possible portlet mode" feature I did:

- remove on PortletInvocation the properties "supportedModes" and "supportedWindowStates"
- remove the ModesInterceptor and WindowStatesInterceptor
- updates -beans.xml to remove those interceptors

I have added on the FragmentResponse a Set nextModes which indicates the next possible modes to the portal.

[julien1]

I haven't mentioned it yet but I did remove the ProducerCacheInterceptor due to the addition of the CacheControl feature in 286. Now the same job is executed when the initial CacheControl impl is built and can be overwritten by the portlet at runtime using the API.

[julien1]

I removed PortletInvocation.REQUEST_PROPERTIES and PortletInvocatin.RESPONSE_PROPERTIES

the reason is that they are not used anymore as the properties now are part of the API.

[julien1]

I have introduced ContentResponse as super class of FragmentResponse. All the FragmentResponse fields and accessors have been moved to that class except the nextModes and the title.

The ContentResponse is a response of a portlet render or a portlet resource serving. In the case of a portlet render, it will return the FragmentResponse as usual.

[julien1]

I deprecated the class org.jboss.portal.common.util.MediaType as it is "broken" on several aspects (not thread safe, does not represent the right concepts).

I have introduced the class org.jboss.portal.common.net.media.MediaType which represent a media type value as defined by the proper RFC.

There is also a MediaTypeMap (which is not related to java.util.Map) which allow to store arbitrary values for MediaType or TypeDef (the definition of a type of a MediaType as defined by RFV blah blah...).

This map object has the concept of wildcard mapping which is used during resolution of a media type (in the portlet container from which I extracted the code), for instance when a portlet declares:

<supports>
 <mime-type>text/*</mime-type>
 ...
</supports>

or

<supports>
 <mime-type>*/*</mime-type>
 ...
</supports>

The class ContentInfo has been updated to use the new media type class and the portlet container has been updated also for that.

Note that in portlet 2.0 it is possible to declare the window states for a media type similar to how it is done for portlet mode support (which is the original motivation of the refactor defined here http://jira.jboss.com/jira/browse/JBPORTAL-1893).

Also the new MediaTypeMap impl is a bit smarter than the code that was originally in ContainerCapabilitiesInfo as it does not need to create object at runtime when it is queried (and it was creating temporary object previously, not a big deal I agree but if it can be saved just by a better impl) and also should be a few nanosecond faster (since it's direct map lookups).

So it is a new migration point that needs to be adressed when getting a snapshot of common + portlet.

[julien1]

I renamed PortletContainerInvoker class to ContainerPortletInvoker (http://jira.jboss.com/jira/browse/JBPORTAL-1937).

I had to rename the beans in the f -beans.xml files.

[julien1]

I have done the following renaming that will affect versions of JBPC after 2.0.0.CR2:

WindowNavigationalState -> PortletWindowNavigationalState
PageNavigationalState -> PortletPageNavigationalState
Event -> PortletWindowEvent

the reason is that those term were not precise enough and are conflicting with terms in 2.7 core.

JBoss Portal 2.7 WindowNavigationalState is more broad and PortletWindowNavigationalState of JBPC controller is window navigational state for a portlet window.

Note that renaming can easily be done with Idea which has a function to migrate class names.

[julien1]

I removed the usage of the classes org.jboss.portal.common.value.* in the portlet container and instead use a List for a preference value.

This will affect the implementation of the property store implementation build on top of hibernate.

I plan to remove the entire package from common once 2.7 does not use it anymore as it should not be use elsewhere.

[julien1]

I simplified the interceptor/invocation of the portlet container in order to simplify and unify the framework.

The PortletInvocation base class does not extend anymore the o.j.p.common.invocation.Invocation class.

The PortletInterceptor class has been removed and replace by a PortletInvokerInterceptor class that is code such as:

public class PortletInvokerInterceptor implements PortletInvoker {

..

private PortletInvoker next;

public void setNext(PortletInvoker next)
{
 this.next = next;
}

public Set<Portlet> getPortlets()
{
 if (next == null)
 {
 throw new IllegalStateException();
 }
 return next.getPortlets();
}

...

}

The different interceptors of the portlet module have been updated to extend that class.

The classes ProducerPortletInvoker / ConsumerPortletInvoker / ContainerPortletInvoker now also extend that class.

The benefit for interceptors is that now they can intercept all methods and not only the portlet life cycle method which extend the range of what an interceptor can do (such as a security interceptor can intercept all methods).

I was considering also the ProducerPortletInvoker and such as interceptor anyway, so it's a good thing to remove the now obsolete dependency on the o.j.p.common.invocation.* package and unify these interceptors.

Beside the minor API changes, I think the most important update is the wiring since the InterceptorStack and InterceptorStackFactory are not used anymore in favor of a direct wiring with the getNext/setNext field on each interceptor.

[julien1]

I have update the common / web / portlet modules to use JBoss Microcontainer 2.0.0.Beta13 .

the good news is that I made a lot of cleanup and that MC also now looks more modular (i.e it does not need the VFS / Deployment / AOP stuff anymore) and it looks more maintainable overally (in poms + build.xml).