9:40 a.m.
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.
10:07 a.m.
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> 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
https://lists.jboss.org/mailman/listinfo/gatein-dev
2:23 a.m.
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>> 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>
https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
2:39 a.m.
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> 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>> 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>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
*Patrice Lamarque eXo - VP Products *
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
8:53 a.m.
Patrice,
Cool, it seems to work. I've sent a pull request for GateIn to
incorporate this: https://github.com/gatein/gatein-portal/pull/709
You might notice that I did it only for the favicon.
- Juca.
On 11/29/2013 10:00 AM, Juraci Paixão Kröhling wrote:
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
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
9:28 a.m.
Well done! Happy to help!
On Fri, Nov 29, 2013 at 9:53 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
Patrice,
Cool, it seems to work. I've sent a pull request for GateIn to
incorporate this: https://github.com/gatein/gatein-portal/pull/709
You might notice that I did it only for the favicon.
- Juca.
On 11/29/2013 10:00 AM, Juraci Paixão Kröhling wrote:
> 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(a)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
>>
>
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
*Patrice Lamarque eXo - VP Products *
4071
days inactive
4072
days old
6 comments
3 participants
participants (3)
-
Juraci Paixão Kröhling -
Nicolas Filotto -
Patrice LAMARQUE