3 a.m.
Patrice,
Thanks a lot! We indeed have RedefinableResourceFilter, but not this
specific component plugin.
Would it be a problem if I implement this as a GateIn feature? Do you
foresee any possible conflicts with your implementation?
- Juca.
On 11/29/2013 09:39 AM, Patrice LAMARQUE wrote:
We've done this in eXo Platform
: https://jira.exoplatform.org/browse/PLF-497
https://github.com/exoplatform/platform/commit/586e1b411c9a9509e3d415a9f0...
<external-component-plugins>
<target-component>org.exoplatform.web.filter.ExtensibleFilter</target-component>
<component-plugin>
<name>JSP filter Plugin</name>
<set-method>addFilterDefinitions</set-method>
<type>org.exoplatform.web.filter.FilterDefinitionPlugin</type>
<init-params>
<object-param>
<name>JSP Filter</name>
<object
type="org.exoplatform.web.filter.FilterDefinition">
<field
name="filter"><object
type="org.exoplatform.commons.platform.RedefinableResourceFilter"/></field>
<field name="patterns">
<!-- WARNING: the mapping is expressed with
regular expressions -->
<collection
type="java.util.ArrayList" item-type="java.lang.String">
<value>
<string>.*/.*\.jsp</string>
</value>
<value>
<string>.*/favicon\.ico</string>
</value>
</collection>
</field>
</object>
</object-param>
</init-params>
</component-plugin>
</external-component-plugins>
It's leveraging a customized filter called : RedefinableResourceFilter
that I'm not sure exists in Gatein (but should IMO) :
package org.exoplatform.web.filter;
import org.exoplatform.container.PortalContainer;
import java.io.IOException;
import javax.servlet.FilterChain;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
public class RedefinableResourceFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException,
ServletException
{
HttpServletRequest req = (HttpServletRequest) request;
PortalContainer pContainer =
PortalContainer.getInstance(req.getSession().getServletContext());
ServletContext context = pContainer.getPortalContext();
String path = req.getRequestURI();
String ctx = req.getContextPath();
if (ctx != null && ctx.length() > 1 && path.startsWith(ctx)) {
path = path.substring(ctx.length());
}
context.getRequestDispatcher(path).include(request, response);
}
}
On Fri, Nov 29, 2013 at 3:23 PM, Juraci Paixão Kröhling
<jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
Nicolas,
My goal is to change the favicon from /portal, without affecting custom
modifications that might have been done at /sample-portal. I think we
have already this behavior for templates via extensions, but it doesn't
seem to work for other resources (like .ico files).
The final solution could be anything (extensions, service, ...), hence
the request for suggestions :-)
- Juca.
On 11/28/2013 05:07 PM, Nicolas Filotto wrote:
> I'm not sure I understand what you want to do, you want to be able to
> modify the favicon from an extension (like sample-extension) or
from an
> new portal (like sample-portal)?
>
>
> On Thu, Nov 28, 2013 at 3:40 PM, Juraci Paixão Kröhling
> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>
<mailto:jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>>>
wrote:
>
> All,
>
> We have a request to display a specific favicon for JBoss
Portal, and it
> seems there's no "easy" (or correct) solution in place for
that
> right now.
>
> The first intuitive solution would be to override the
templates, to make
> them link to the desired favicon. This doesn't scales, as the
whole
> template is duplicated and it will only cause headaches in the
future.
>
> The second possible solution would be to incorporate the path
to the
> favicon into the properties file, but this means having a
fixed path to
> the favicon, which is a step backwards from what there is
today: in one
> of the templates for /portal, it gets the favicon for the
context path,
> so, if the current portal is /example-portal, it currently
gets the
> favicon at /example-portal/favicon . With the favicon coming
from the
> properties file, this would not be the case anymore, as all
favicons
> would be coming from a fixed path.
>
> The third solution would be to build a FaviconService, that
would take
> care of determining the proper favicon path. It sounds to me
that this
> is a bit of overkill, but would be a clean solution.
>
> Of course, the best option would be to be possible to override the
> favicon from /portal, but this doesn't seems to be possible at the
> moment. It seems that only templates are overriden.
>
> Before proceeding with the third solution (which seems the most
> desirable as of now), I would like to get your comments,
opinions and
> suggestions on how this could be better handled.
>
> Best Regards,
> Juca.
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
<mailto:gatein-dev@lists.jboss.org <mailto:gatein-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
*Patrice Lamarque
eXo - VP Products
*
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev