[update] I read too quickly.
You can only extend classes which are part of the portlet bundle's exported API, which is not typical for portlets.
Overriding JSPs is handled through fragments. This is documented in the developer guide here.
However, I would suggest integrating with existing portlets through clean APIs such as the example below demonstrates.
[original below]
Yup!
Portlet support in Liferay 7.0 has been enhanced such that any of the portlet related integration points can be provided as plain OSGi services, the key piece of information is typically the service property `javax.portlet.name`. This is what binds the service to the portlet. There are too many integration points to list here, but effectively looking at the types supported by the old `liferay-portlet.xml` are supported by this mechanism, plus several more.
For instance, if you wish to attach a `javax.portlet.filter.RenderFilter` to an existing portlet who's `javax.portlet.name` is `foo` you would do (I'm using DS since that's the preferred way to work in OSGi):
and that's it!
You can only extend classes which are part of the portlet bundle's exported API, which is not typical for portlets.
Overriding JSPs is handled through fragments. This is documented in the developer guide here.
However, I would suggest integrating with existing portlets through clean APIs such as the example below demonstrates.
[original below]
Yup!
Portlet support in Liferay 7.0 has been enhanced such that any of the portlet related integration points can be provided as plain OSGi services, the key piece of information is typically the service property `javax.portlet.name`. This is what binds the service to the portlet. There are too many integration points to list here, but effectively looking at the types supported by the old `liferay-portlet.xml` are supported by this mechanism, plus several more.
For instance, if you wish to attach a `javax.portlet.filter.RenderFilter` to an existing portlet who's `javax.portlet.name` is `foo` you would do (I'm using DS since that's the preferred way to work in OSGi):
@Component(
property = {
"javax.portlet.name=foo"
}
)
public class FooRenderFilter implements RenderFilter {
public void destroy() {
// TODO Auto-generated method stub
}
public void init(FilterConfig config) throws PortletException {
// TODO Auto-generated method stub
}
@Override
public void doFilter(
RenderRequest request, RenderResponse response, FilterChain chain)
throws IOException, PortletException {
// TODO Auto-generated method stub
}
}
and that's it!