Re: Result (was: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled )
Hi Number 2 and 3 were implemented and it is now on trunk. The idea was create some classes to wrap existing servlet 3.0 methods and if it is a 2.5 servlet container, parse the file and get the same information. I tested it in tomcat 7 and jetty 7 and it works well. The next step is remove the filter code (number 4). regards, Leonardo Uribe 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi Thanks to all community members who vote. Here are the results 1. No votes 2. 5 votes (Martin Marinschek, Jakob Korherr, Gerhard Petracek, Rudy de Busscher, Jan Kees Van Andel) 3. 7 votes (Leonardo Uribe, Martin Marinschek, Jakob Korherr, Gerhard Petracek, Rudy de Busscher, Jan Kees Van Andel, Bruno Aranda) 4. 2 votes (Leonardo Uribe, Bruno Aranda) It is clear do option 3 seems the most preferred option, but if it is not present, option 2 an aceptable fallback (but at least there is one mention that could be confusing). There are no votes to get rid 4, but 2 is preferred over 4, so 2 takes precedence. When 3 is done, we can get rid 4. So the plan is: a. Implement 2 fully. b. Implement 3 fully. best regards, Leonardo Uribe
Result (was: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled )
Hi Thanks to all community members who vote. Here are the results 1. No votes 2. 5 votes (Martin Marinschek, Jakob Korherr, Gerhard Petracek, Rudy de Busscher, Jan Kees Van Andel) 3. 7 votes (Leonardo Uribe, Martin Marinschek, Jakob Korherr, Gerhard Petracek, Rudy de Busscher, Jan Kees Van Andel, Bruno Aranda) 4. 2 votes (Leonardo Uribe, Bruno Aranda) It is clear do option 3 seems the most preferred option, but if it is not present, option 2 an aceptable fallback (but at least there is one mention that could be confusing). There are no votes to get rid 4, but 2 is preferred over 4, so 2 takes precedence. When 3 is done, we can get rid 4. So the plan is: a. Implement 2 fully. b. Implement 3 fully. best regards, Leonardo Uribe
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
I can agree with jacob that Suffix mapping is bad for resource-requests
but the choosen option shouldn't block developers from using suffix mapping
for pages.
As far as I can understand the discussion - +1 for option 2 (option 3 if we
want to have an advanced config version)
Regards
Rudy
On 3 July 2011 02:33, Bruno Aranda brunoara...@gmail.com wrote:
+1 for 3
Between 2 and 4, I still prefer a filter. For me an init param to deal with
such a specific case is more obscure than a filter, but it may be my
intuition,
Cheers,
Bruno
On 3 July 2011 00:20, Gerhard Petracek gerhard.petra...@gmail.com wrote:
i agree with martin and jakob.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/2 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Martin on the preferred options and the filter
question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code
as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to
change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks
something
like this:
http://
[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web
config
init param to indicate that mapping will be used to handle
resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be
provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically,
looking
on application map if the filter was set or not and a web config
init
param to know the mapping used, without parse xml files or servlet
3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
+1 for option 3, but I'm not sure how much time it takes to implement this
option.
(If it's too much effort, option 2 looks okay to me)
Regards,
Jan-Kees
2011/7/4 Rudy De Busscher rdebussc...@gmail.com
I can agree with jacob that Suffix mapping is bad for resource-requests
but the choosen option shouldn't block developers from using suffix mapping
for pages.
As far as I can understand the discussion - +1 for option 2 (option 3 if
we want to have an advanced config version)
Regards
Rudy
On 3 July 2011 02:33, Bruno Aranda brunoara...@gmail.com wrote:
+1 for 3
Between 2 and 4, I still prefer a filter. For me an init param to deal
with such a specific case is more obscure than a filter, but it may be my
intuition,
Cheers,
Bruno
On 3 July 2011 00:20, Gerhard Petracek gerhard.petra...@gmail.comwrote:
i agree with martin and jakob.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/2 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Martin on the preferred options and the filter
question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in
this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code
as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to
change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with
the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks
something
like this:
http://
[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module
and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web
config
init param to indicate that mapping will be used to handle
resources.
If such param is no present, assume /faces as prefix mapping
used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be
provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically,
looking
on application map if the filter was set or not and a web config
init
param to know the mapping
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Hi,
I totally agree with Martin on the preferred options and the filter question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
i agree with martin and jakob.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/2 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Martin on the preferred options and the filter
question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as
is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://
[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
+1 for 3
Between 2 and 4, I still prefer a filter. For me an init param to deal with
such a specific case is more obscure than a filter, but it may be my
intuition,
Cheers,
Bruno
On 3 July 2011 00:20, Gerhard Petracek gerhard.petra...@gmail.com wrote:
i agree with martin and jakob.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/2 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Martin on the preferred options and the filter
question.
IMO there should not be any filter. Furthermore I really don't
understand why you want suffix mapping to work so badly, Leonardo.
Suffix mapping is bad for resource-requests (maybe even an epic fail),
because a css file is accessed via e.g. style.css.jsf. If the
mime-type is stripped or ignored or whatever, the browser (note there
are pretty bad browsers out there) might think this is a *.jsf file..
And there are some more reasons, that I can explain on request to
everyone interested.
Regards,
Jakob
2011/7/1 Leonardo Uribe lu4...@gmail.com:
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as
is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to
change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks
something
like this:
http://
[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web
config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be
provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically,
looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet
3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice
selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jakob Korherr
blog: http://www.jakobk.com
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Hi Leo,
how is 4 better than 2?
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Hi Martin
2011/7/1 Martin Marinschek mmarinsc...@apache.org:
Hi Leo,
how is 4 better than 2?
I was thinking on a scenario where some user want some other feature
in myfaces-commons-resourcehandler like gzip compression, i18n locale
appended to request path, library relocation of provide a custom
request path pointing to a Content Delivery Network or just a
directory inside the web application, and he/she is not interested in
solution to the issue presented before.
In such case, suffix mapping alone should work. Note 2 requires a
prefixed mapping (note the assumption that /faces), but 4 does not
enforce that, so it will work on both prefix and suffix mapping, but
if you want a solution for the previous problem you just add the
filter and problem solved. A filter is a simple solution to implement,
and it will work without problem in any scenario. Note in this case
the filter will be used only when suffix mapping is used.
best regards,
Leonardo Uribe
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
