[jira] [Resolved] (EXTCDI-147) test extension points
[ https://issues.apache.org/jira/browse/EXTCDI-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-147. - Resolution: Fixed test extension points - Key: EXTCDI-147 URL: https://issues.apache.org/jira/browse/EXTCDI-147 Project: MyFaces CODI Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-189) add further proxy implementations to the alternative modules
[ https://issues.apache.org/jira/browse/EXTCDI-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-189. - Resolution: Won't Fix not needed with the new approach add further proxy implementations to the alternative modules Key: EXTCDI-189 URL: https://issues.apache.org/jira/browse/EXTCDI-189 Project: MyFaces CODI Issue Type: Task Components: Alternative Implementation Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
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
[VOTE] Release of Extensions CDI (CODI) 1.0.0
Hi, I was running the needed tasks to get the 7th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-009/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-009/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.0/myfaces-extcdi-parent-1.0.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.0
+1 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/3 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 7th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-009/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-009/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.0/myfaces-extcdi-parent-1.0.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
