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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137627#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...