Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=JD0D4N5r29KJFRqYGhRdU/mpyZ8h+H0k1y2x6dMyYkh2dbJijyvs3idYMTc+m8YU4If+GPP/MtKkypQFlbrGumHthr9RNZqm7ElZjqHn33GarzQ2CotU0LOV23uXw7K5LX9txKPdro9SVwcfjtzXfXBY+mQcqTHdSGwei7zuQ40=;
References: <1319753799.61080.YahooMailNeo@web27807.mail.ukl.yahoo.com>
 <CABujnVcU_KMe8okwML9S2q_6SM8NQLMGJ4EQmWs=tNk0wchZMw@mail.gmail.com>
 <1319800085.2304.YahooMailNeo@web27804.mail.ukl.yahoo.com>
 <CABujnVfV+tTqnSTwhQwDbj8A0XTa20mB5u+LvwycKAafhjxQaQ@mail.gmail.com>
 <1319832435.41678.YahooMailNeo@web27802.mail.ukl.yahoo.com>
 <CABujnVfOzBHrs3quSk+vfzvKKa+AFyt_O7zKzHgcDUm1G4oASA@mail.gmail.com>
Message-ID: <1319875112.66418.YahooMailNeo@web27808.mail.ukl.yahoo.com>
Date: Sat, 29 Oct 2011 08:58:32 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: [DISCUSS] why do we overcomplicate our code soooo much?
To: myfaces-dev <dev@myfaces.apache.org>
In-Reply-To: 
 <CABujnVfOzBHrs3quSk+vfzvKKa+AFyt_O7zKzHgcDUm1G4oASA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Actually I DID touch the code. Because I helped Jakob with one of the very =
first versions. Thus I was involved pretty much from the very beginning. Ev=
en before the code got imported.=0A=0A=0AActually I'm also still missing th=
e answers to my technical questions...=0A=0A=0A=0A> So, how can we get some=
thing productive from all previous discussion?=0A> Create a new proposal ta=
king every lesson we have learned and don't=0A> repeat the same mistakes. =
=0A=0A=0AYes, I think that is something we should really do. I will try to =
convince Jakob to import his project again into a new sub-folder (myfaces-c=
ommons-restful-resources or something) and then we'll start over again. =0A=
=0AAny help is welcome, but please file a JIRA before you like something to=
 change. Please note that Jakob is currently making his Bak thesis about th=
is very topic and I'm assisting him in our institute. =0A=0A=0AAt the end o=
f the day (oki 2 months) we compare the 2 versions and VOTE which to keep. =
I hope this is ok for you.=0A=0A=0Atxs and LieGrue,=0Astrub=0A=0A=0A=0A----=
- Original Message -----=0A> From: Leonardo Uribe <lu4242@gmail.com>=0A> To=
: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg <struberg@yah=
oo.de>=0A> Cc: =0A> Sent: Friday, October 28, 2011 11:38 PM=0A> Subject: Re=
: [DISCUSS] why do we overcomplicate our code soooo much?=0A> =0A> Hi=0A> =
=0A> I think this discussion is going to nowhere. It is not worth I=0A> ded=
icate more time to answer each point because at the end what=0A> matters is=
 code. If you didn't participate or get involved in the=0A> development, do=
n't blame the code made by the people who try to do the=0A> code, participa=
te and take the time to try to make things better. It=0A> is pointless to h=
ave a discussion that doesn't focus on technical=0A> reasons, and instead i=
t is questioned the way this process has been=0A> done for about 7 months b=
y someone who never said a word at that=0A> moment.=0A> =0A> So, how can we=
 get something productive from all previous discussion?=0A> Create a new pr=
oposal taking every lesson we have learned and don't=0A> repeat the same mi=
stakes. Vote the proposal and then implement it from=0A> scratch, reusing w=
hat is necessary and discarding what is not.=0A> =0A> I'm not going to veto=
 anything, because at the end the community=0A> should impose its will. I'l=
l continue participating in the process=0A> just as an observer.=0A> =0A> r=
egards,=0A> =0A> Leonardo=0A> =0A> 2011/10/28 Mark Struberg <struberg@yahoo=
.de>:=0A>>  Exactly there was a vote. Please go on and read the threads you=
 posted =0A> again!=0A>> =0A>> =0A>>  a.) the vote you linked to has nothin=
g to do with what you did implement =0A> and b) exactly in this thread you =
can see that already 5 people mentioned 15 =0A> times that you are really w=
rong and that they do not share your opinion in this =0A> points! You even =
force people to fork off the project because you cannot accept =0A> a diffe=
rent opinion and randomly revert the work done by others.=0A>> =0A>> =0A>> =
 Leo, I really like the work you do on myfaces-core, but please let others =
=0A> do their projects as well. This was Jakobs project and you perfectly s=
crewed him =0A> off. I originally didn't pay too much attention on the tech=
nical side, thus =0A> I didn't say much - but after having a detailed look =
at the problem (because =0A> I need to make use of it), I can only say that=
 the changes are far from good.=0A>> =0A>> =0A>>>  That's something new. Th=
at wiki page has date from October 13.=0A>>  The wiki page of the project i=
s actually older. Plus most of this was also =0A> documented in the code yo=
u deleted.=0A>> =0A>>  Another option for getting this info would have been=
 ASKING. Or just =0A> listening to the explanations you got (for example on=
 the threads you linked).=0A>> =0A>>>  but that does=0A>>>  not means that =
the final code should solve ONLY this case.=0A>> =0A>>  Actually yes. The p=
roject Jakob started had the pure intention to just =0A> remove the need th=
at JSF resources cannot get cached, thus they hit the server =0A> with each=
 and every page reload. That is really the ONLY problem this code =0A> shou=
ld solve! If there are some neat little side goodies than I'm fine with =0A=
> that as well. But please don't introduce new features which blow up the c=
ode =0A> to 10-times the LOC.=0A>> =0A>> =0A>> =0A>>>  There was an origina=
l list and then=0A>>>  we try to add some features.=0A>>  where did _we_ tr=
y to add some features? JIRA number?=0A>> =0A>> =0A>>>>  =C2=A0* Prevent us=
e #{resource['...']} on css files, using =0A> prefix mapping=0A>>>>  =C2=A0=
a.) there is no JIRA for it.=0A>>> =0A>>>  If that comes from the spec, isn=
't suppose a "extended" =0A> resource=0A>>>  handler should implement it? I=
 created an issue to fix a problem=0A>>>  related to this one:=0A>>> =0A>>>=
  https://issues.apache.org/jira/browse/MFCOMMONS-38=0A>>  Again: JIRA numb=
er? because MFCOMMONS-38 has nothing to do with it due to =0A> the fact tha=
t the logic is the wrong way around...=0A>> =0A>>>  I don't think that's co=
mplicated. There is one custom =0A> InputStream that=0A>>>  checks=0A>>>  t=
he output for #{ and if it found something, it try to evaluate, if is =0A> =
success=0A>>>  it output the result, if it is not, it continues.=0A>>  We c=
an get rid of all the ValueExpressionFilterInputStream and associated =0A> =
other sources.=0A>>  It really doesn't matter if the EL in the css is valid=
 or not. Not a =0A> bit, njente, nada...=0A>>  Thats just useless code... I=
f there is any #{ (or "#{resource" =0A> would need to think about it) in th=
e code, then it's just not cacheable.=0A>>  What problem did you like to so=
lve by evaluating the ELs?=0A>> =0A>>>  Maybe you're saying web.xml parsing=
. That's for prefix mapping =0A> automatic=0A>>>  detection.=0A>>  Oki, the=
n I vote for manually configuring the prefix.=0A>>  a.) parsing web.xml is =
not easy and error prone. because the =0A> META-INF/web.xml is NOT what fin=
ally will get used! It will be merged with the =0A> server provided web.xml=
. It might get changed by web-fragments in Servlet-3.0 =0A> environments, e=
tc.=0A>>  b.) by configuring an absolute address for a pattern, you will al=
so get =0A> your (another 10++ classes heavy) solution for configuring 'ext=
ernal' =0A> resources for free. E.g. if you like to use 1 shared resource a=
ddress for =0A> multiple webapps.=0A>> =0A>> =0A>>  In general: I think the=
 whole configuration must not be done in web.xml or =0A> faces-config.xml. =
It really should be done in an own config file. And it should =0A> support =
a mechanism to exchange the config programmatically or via ProjectStage. =
=0A> This is needed becaues you might like to use different configs in prod=
uction.=0A>> =0A>> =0A>>>>  =C2=A0I agree that it could be usable to have t=
his configurable - but =0A> why via EL?=0A>>>  Just too complicated.=0A>>>>=
 =0A>>> =0A>>>  I don't think so. In faces-config.xml files we use EL for =
=0A> navigation rules.=0A>>>  Suggestions are welcome.=0A>>  This was not r=
eally an answer. Please bring arguments. Why do we need =0A> dynamic config=
uration for static information?=0A>> =0A>> =0A>>>>  =C2=A0resourceName of o=
ur resourcehandler !=3D resourceName of JSF =0A> resource=0A>>>  handling!=
=0A>>>> =0A>>> =0A>>>  I know, but it is a terrible trick. I have told this=
 before, but that=0A>>>  strategy leads=0A>>>  with some ambiguities.=0A>> =
=0A>>  Actually it's not a 'trick' but it's a really well working =0A> patt=
ern. We expand all information we have to get a new restful URI.=0A>> =0A>>=
 =0A>>>  But it is evidence that the code has design mistakes, and is not u=
sing=0A>>>  the API as it is supposed.=0A>>  Actually I think the spec has =
design mistakes in this area. We try to solve =0A> this in a portable, but =
not too tightly integrated fashion.=0A>> =0A>>> =0A> http://{server}[:port]=
/{appPath}/javax.faces.resource/de_AT/mydir/myresource.js=0A>>> =0A>>>  The=
 algorithm will detect de as a locale prefix, mydir as a library and=0A>>> =
 myresource.js as a resource name, but that's wrong because the=0A>>>  reso=
urce name is de/mydir/myresource.js. ...."=0A>>  Thats exactly why this doe=
sn't work. And there is a really easy =0A> solution for it by using reprodu=
cible restful URLs.=0A>>  But first we would need to drop all the stuff we =
don't need. And I =0A> honestly fear this is more work than just starting f=
rom scratch again and =0A> consider the current trunk as 'prototype' which =
just didn't work =0A> out.=0A>> =0A>> =0A>>  LieGrue,=0A>>  strub=0A>> =0A>=
> =0A>>  ----- Original Message -----=0A>>>  From: Leonardo Uribe <lu4242@g=
mail.com>=0A>>>  To: MyFaces Development <dev@myfaces.apache.org>; Mark Str=
uberg =0A> <struberg@yahoo.de>=0A>>>  Cc:=0A>>>  Sent: Friday, October 28, =
2011 7:13 PM=0A>>>  Subject: Re: [DISCUSS] why do we overcomplicate our cod=
e soooo much?=0A>>> =0A>>>  Hi Mark=0A>>> =0A>>>  2011/10/28 Mark Struberg =
<struberg@yahoo.de>:=0A>>>>  =C2=A0Leo,=0A>>>> =0A>>>> =0A>>>>>  =C2=A0Is l=
ike the blind that try to see the elephant=0A>>>> =0A>>>> =0A>>>>  =C2=A0Th=
anks for the flowers, but actually we USE this already in =0A> practice! An=
d=0A>>>  we cannot use=0A>>>>  =C2=A0mf-commons-resourcehandler because it =
crashes with multiple =0A> servlets.=0A>>>>  =C2=A0Thus I was looking wheth=
er we can fix mf-commons-resourcehandler, =0A> or we=0A>>>>  =C2=A0shall go=
 and improve Jakobs version.=0A>>>> =0A>>>>  =C2=A0Also I don't see why Jak=
obs @author tags got removed from =0A> sources which=0A>>>>  =C2=A0obviousl=
y originated from him (although now renamed and changed). =0A> Also=0A>>>> =
 =C2=A0SVN is fuuu up most probably because of some svn mv. I cannot just=
=0A>>>>  =C2=A0revert the code locally to see what was there originally (al=
though =0A> svn=0A>>>>  =C2=A0log shows the changes).=0A>>>> =0A>>> =0A>>> =
 Checking the svn log the code committed by jakob was removed in=0A>>>  rev=
 1170571 and rev 1170292 with date 14 September 2011, which=0A>>>  was just=
 a month ago. Why? because I wanted to keep it on the svn=0A>>>  as referen=
ce, and the idea was discuss about both strategies.=0A>>>  Check these link=
s to see the files:=0A>>> =0A>>> =0A> http://svn.apache.org/viewvc/myfaces/=
commons/branches/jsf_20/myfaces-commons-resourcehandler/src/main/java/org/a=
pache/myfaces/commons/resourcehandler/AdvancedResource.java?revision=3D1095=
901&view=3Dmarkup&pathrev=3D1147474=0A>>> =0A> http://svn.apache.org/viewvc=
/myfaces/commons/branches/jsf_20/myfaces-commons-resourcehandler/src/main/j=
ava/org/apache/myfaces/commons/resourcehandler/AdvancedResourceHandler.java=
?revision=3D1095901&view=3Dmarkup&pathrev=3D1147474=0A>>> =0A>>>  You can s=
vn update the code to an specified revision to see=0A>>>  which code was on=
 the svn in that time. You don't need to revert =0A> it.=0A>>> =0A>>>  Just=
 as reference below there are the original mails where all this=0A>>>  disc=
ussion started:=0A>>> =0A>>> =0A> http://markmail.org/message/glr356g45uta5=
yys?q=3DAdvanced+Resource+Handler=0A>>> =0A> http://markmail.org/message/zu=
ydfi2kug3ns52w?q=3Dvote+how+to+list:org%2Eapache%2Emyfaces%2Edev+order:date=
-backward&page=3D8=0A>>> =0A>>>  So, this discussion dates from February, t=
he alternate proposal=0A>>>  was committed on Jun 13, but the other code wa=
s not removed,=0A>>>  instead a mail was sent to start a discussion about h=
ow this=0A>>>  module should looks like.=0A>>> =0A>>>> =0A>>>>  =C2=A0Let's=
 go through the list:=0A>>>> =0A>>>>>  =C2=A0I think you have the wrong imp=
ression, basically because you=0A>>>  haven't=0A>>>>>  =C2=A0tried to solve=
 each one of the problems that the code try to =0A> solve.=0A>>>>  =C2=A0Ac=
tually I know that there are a few things to do, but the =0A> 'new'=0A>>>  =
code solves=0A>>>>  =C2=A0problems which just do not exist! It's now comple=
tely =0A> over-engineered=0A>>>>  =C2=A0imo - more details later on.=0A>>>>=
 =0A>>>>>  =C2=A01. Which features should be included:=0A>>>> =0A>>>>  =C2=
=A0For the requirements please read=0A>>>> =0A>>> =0A> http://code.google.c=
om/a/apache-extras.org/p/relative-resource-handler/wiki/Requirements=0A>>>>=
 =0A>>> =0A>>>  That's something new. That wiki page has date from October =
13. So=0A>>>  I suppose it is a "refined" list from the original intention =
=0A> sent on=0A>>>  February 23=0A>>>  to this list.=0A>>> =0A>>>>  =C2=A0J=
ust to explain this again: We _only_ really need to handle=0A>>>>  =C2=A0ja=
vax.faces.application.Resource#getRequestPath()=0A>>>> =0A>>>>  =C2=A0and t=
he special handling is only for 'new resources' which=0A>>>  don't contain =
EL or any other dynamic stuff! Of course the =0A> structure and=0A>>>  fall=
backs still might be dynamic - but reproducable (as example: if no =0A> okB=
utton=0A>>>  for language=3Dcn exists the resource with language=3Den will =
get served).=0A>>>> =0A>>>> =0A>>>>  =C2=A0In case of such a =E2=80=98new r=
esource=E2=80=99 we will expand ALL variable =0A> parameters=0A>>>>  =C2=A0=
(language, version, useragent - this list should finally be=0A>>>>  =C2=A0u=
ser-extendable) to one bit REST URL, always containing =C2=A0ALL =0A> param=
eters=0A>>>>  =C2=A0(and if it=E2=80=99s only the default value, e.g _en_ f=
or language =0A> =E2=80=98english=E2=80=99 as=0A>>>>  =C2=A0default).=0A>>>=
> =0A>>>>  =C2=A0This URL doesn=E2=80=99t necessarily need to be treated vi=
a a JSF resource =0A> request=0A>>>  - actually it=E2=80=99s something COMP=
LETELY different! This can also be a pure=0A>>>>  =C2=A0Servlet! It=E2=80=
=99s really completely split from JSF - there is no info =0A> needed=0A>>> =
 from JSF anymore, because ALL the info is in the restful resource URL=0A>>=
>>  =C2=A0itself! There is no =E2=80=98?ln=3Dcss=E2=80=99 or whatever in th=
ose URLs, just pure =0A> static=0A>>>  info packed into the restful URL.=0A=
>>>> =0A>>>>  =C2=A0The only thing we need to make sure is that _other_ res=
ources will =0A> still=0A>>>  get served via the standard JSF resource mech=
anism.=0A>>>>  =C2=A0But really, we don=E2=80=99t even need to intercept th=
e JSF resource GET =0A> requests.=0A>>>>  =C2=A0Because the =E2=80=98new=E2=
=80=99 resources might not even be served as such...=0A>>>> =0A>>> =0A>>>  =
Ok, that's new information. Thanks for the clarifications about =0A> your=
=0A>>>  needs and the intention. I see this more as a "use case" than=0A>>>=
  myfaces-commons-resourcehandler should solve, but that does=0A>>>  not me=
ans that the final code should solve ONLY this case.=0A>>> =0A>>>> =0A>>>> =
 =C2=A0We imo don=E2=80=99t need (points from your list):=0A>>>> =0A>>> =0A=
>>>  It is not my list, that should be clear. There was an original list an=
d =0A> then=0A>>>  we try to add some features.=0A>>> =0A>>>>  =C2=A0* gzip=
 stuff: can be applied via Filter or httpd mod in front as =0A> already=0A>=
>>>  =C2=A0explained. There are perfect solutions on the market for this =
=0A> already.=0A>>>> =0A>>> =0A>>>  After thinking about it, the code that =
handle gzip stuff has these=0A>>>  advantages:=0A>>> =0A>>>  - No additiona=
l buffer, reducing memory usage.=0A>>>  - Cache files on temp dir using JSF=
 2 Resource Handler logic.=0A>>> =0A>>>  but its disadvantages=0A>>> =0A>>>=
  - Hinder Resource Handler API abstractions=0A>>>  - No pluggable.=0A>>>  =
- Better known ways.=0A>>>  - Lack of agent detection and configuration usi=
ng other params=0A>>> =0A>>>  At first it sounded like a good idea but afte=
r implement it and see the=0A>>>  result, it is clear remove gzip stuff is =
the right choice.=0A>>> =0A>>>>  =C2=A0* caching: don=E2=80=99t needed beca=
use the new solution will enable =0A> caching on the=0A>>>  CLIENT!=0A>>>> =
 =C2=A0If you really need server side caching, then any users can enable =
=0A> a=0A>>>>  =C2=A0caching Filter or http mod_cache or mod_file_cache, be=
cause the =0A> URLs are=0A>>>  fully REST! One URL will _always_ return the=
 same binary!=0A>>>> =0A>>> =0A>>>  caching was for gzip resources, so yes,=
 let's remove that too.=0A>>> =0A>>>>  =C2=A0* Prevent use #{resource['...'=
]} on css files, using =0A> prefix mapping=0A>>>>  =C2=A0a.) there is no JI=
RA for it.=0A>>> =0A>>>  If that comes from the spec, isn't suppose a "exte=
nded" =0A> resource=0A>>>  handler should implement it? I created an issue =
to fix a problem=0A>>>  related to this one:=0A>>> =0A>>>  https://issues.a=
pache.org/jira/browse/MFCOMMONS-38=0A>>> =0A>>>  but the default behavior w=
as inherited from the default algorithm.=0A>>> =0A>>>>  =C2=A0b.) Actually =
(given the expense we have for doing this in the =0A> current code=0A>>>>  =
=C2=A0base + the expense this costs at runtime atm) I=E2=80=99d favour to n=
ot do =0A> the=0A>>>>  =C2=A0check at runtime.=0A>>>>  =C2=A0Why? Because e=
very developer will quickly see that his resources =0A> will be=0A>>>>  =C2=
=A0broken anyway. And for resources provided by some 3-rd party, =0A> those=
=0A>>>>  =C2=A0can/should get excluded in the config.=0A>>>>  =C2=A0We coul=
d probably just log a warning if css contains =E2=80=9C#{=E2=80=9C in=0A>>>=
>  =C2=A0ProjectStage.Development to make excluding easier. This is just 10=
 =0A> lines of=0A>>>  code and we are done.=0A>>>> =0A>>>>  =C2=A0Otoh I=E2=
=80=99m not sure why doing this properly (even at runtime) should =0A> be s=
oo=0A>>>  complicated.=0A>>>>  =C2=A0When building the getRequestPath() we =
scan the css if it contains =0A> =E2=80=9C#{=E2=80=9C and=0A>>>>  =C2=A0if =
so, it cannot be served restfully. In this case we just return =0A> the=0A>=
>>>  =C2=A0default request URI from the underlying wrapped ResourceHandler.=
 =0A> This=0A>>>>  =C2=A0info (static/dynamic) can also easily get cached b=
y using the =0A> fully=0A>>>>  =C2=A0expanded restful URL as cache key. Tha=
ts another 15 lines of code =0A> =E2=80=A6 Why=0A>>>>  =C2=A0do we need 10 =
classes for that?=0A>>>> =0A>>> =0A>>>  I don't think that's complicated. T=
here is one custom =0A> InputStream that=0A>>>  checks=0A>>>  the output fo=
r #{ and if it found something, it try to evaluate, if is =0A> success=0A>>=
>  it output the result, if it is not, it continues.=0A>>> =0A>>>  What to =
do? find a bad #{ in a .css looks very, very unlikely. I =0A> don't see=0A>=
>>  any=0A>>>  problem to let this processing as default.=0A>>> =0A>>>>  =
=C2=A0* Prefix mapping automatic detection:=0A>>>>  =C2=A0a.) there is no J=
IRA for it.=0A>>>>  =C2=A0b.) This clashes with the REST approach. Read Jak=
obs original =0A> intent and my=0A>>>  explanation above. It=E2=80=99s just=
 not needed. If this will some day finally=0A>>>>  =C2=A0be included in JSF=
 itself, then we might use the resource serving=0A>>>>  =C2=A0mechanism - b=
ut then again this will all reside in myfaces-core =0A> anyway.=0A>>>>  =C2=
=A0Until then we don=E2=80=99t need it.=0A>>>> =0A>>> =0A>>>  This point wa=
s discussed on dev list and this is the first time I hear =0A> these=0A>>> =
 arguments. This utility is for 2.0.x and 2.1.x, right?. If the spec =0A> i=
ncludes it=0A>>>  or not in a later version, we still have the problem. I t=
hink your =0A> previous=0A>>>  explanations are a "use case", but this is a=
 library thought =0A> to deal=0A>>>  with=0A>>>  multiple use cases. If you=
 don't need is ok, but that's not =0A> enough to=0A>>>  conclude this is no=
t useful.=0A>>> =0A>>>  The intention is not solve just one use case, is bu=
ild a extended =0A> resource=0A>>>  handler that can be applied to many dif=
ferent use cases.=0A>>> =0A>>>  Could you please be more specific about why=
 this clashes with REST=0A>>>  approach?=0A>>> =0A>>>>  =C2=A0* faces-confi=
g.xml parsing: not needed imo. What do we need it =0A> for? (there=0A>>>  g=
oes another 15 classes)=0A>>>> =0A>>> =0A>>>  Maybe you're saying web.xml p=
arsing. That's for prefix mapping =0A> automatic=0A>>>  detection.=0A>>> =
=0A>>>>  =C2=A0* - Override request path generation using EL expressions=0A=
>>>>  =C2=A0a.) there is no JIRA for it!=0A>>>>  =C2=A0b.) What do we need =
this for? (in hindsight of the explanation =0A> above)=0A>>>>  =C2=A0I agre=
e that it could be usable to have this configurable - but =0A> why via EL?=
=0A>>>  Just too complicated.=0A>>>> =0A>>> =0A>>>  I don't think so. In fa=
ces-config.xml files we use EL for =0A> navigation rules.=0A>>>  Suggestion=
s are welcome.=0A>>> =0A>>>>  =C2=A0* - Redirect library names to prevent d=
uplicate usage against =0A> other JSF=0A>>>  libraries.=0A>>>>  =C2=A0a.) t=
here is no JIRA for it!=0A>>>>  =C2=A0b.) actually I didn=E2=80=99t get tha=
t point.=0A>>>> =0A>>> =0A>>>  Suppose you use the same javascript library =
in two different jsf=0A>>>  libraries, how can=0A>>>  you make them work to=
gether without redirect one library? Otherwise the =0A> same=0A>>>  js file=
 will be included twice on the same page.=0A>>> =0A>>>>>  =C2=A0To support =
this point check this:=0A>>>>  =C2=A0You didn=E2=80=99t even gave Jakob a c=
hance to fix that after he imported =0A> his code.=0A>>>  You created MFCOM=
MONS-33 at 13/Jun/11 21:11 and checked in all the=0A>>>>  =C2=A0=E2=80=98ch=
anges=E2=80=99 (effectively dropping jakobs logic) at Jun 13 21:12:27 =0A> =
thus=0A>>>>  =C2=A0making it ummaintainable in just 1 minute...=0A>>>>  =C2=
=A0You really just overnight =E2=80=98fixed=E2=80=99 the code by completely=
 changing =0A> it=E2=80=99s=0A>>>  meaning and imported tons of classes fro=
m other projects.=0A>>> =0A>>>  But a mail was written on May 18 and before=
 suggesting some changes. =0A> For more=0A>>>  than 1 month I didn't receiv=
e any feedback. Then I committed the =0A> change but=0A>>>  I never removed=
 the code. Then I started a discussion about this.=0A>>>  Everything has=0A=
>>>  been done in public. If you don't like something and you don't =0A> me=
ntion=0A>>>  it, too bad,=0A>>>  it is your problem. But anyway it is absur=
d to discuss about the past. =0A> I'm=0A>>>  more=0A>>>  interested about t=
he present and the future.=0A>>> =0A>>>>  =C2=A0Especially the=0A>>>>  =C2=
=A0// (FIXME this must be done in a better way when changing=0A>>>>  =C2=A0=
// JSF's own ResourceHandler in JSF 2.2)=0A>>>>  =C2=A0was most probably me=
ant that this must get changed IF this logic =0A> will be=0A>>>>  =C2=A0ado=
pted for the JSF-2.2 specification. This was most probably =0A> never=0A>>>=
>  =C2=A0meant that we need to do this for JSF-2.1 and below!=0A>>>> =0A>>>=
>  =C2=A0THAT would have required a VOTE!=0A>>>> =0A>>> =0A>>>  But it is e=
vidence that the code has design mistakes, and is not using=0A>>>  the API =
as it is supposed.=0A>>> =0A>>>> =0A>>>>>  =C2=A0which put everything on re=
sourceName without decode it.=0A>>>>  =C2=A0Leo really, thats EXACTLY the t=
rick!=0A>>>>  =C2=A0The resourceName will just not be the =E2=80=98name=E2=
=80=99 but the fully blown =0A> restful=0A>>>  indicator!=0A>>>>  =C2=A0res=
ourceName of our resourcehandler !=3D resourceName of JSF =0A> resource=0A>=
>>  handling!=0A>>>> =0A>>> =0A>>>  I know, but it is a terrible trick. I h=
ave told this before, but that=0A>>>  strategy leads=0A>>>  with some ambig=
uities.=0A>>> =0A>>>  ".... I think the opposite in this case, because the =
previous =0A> syntax is=0A>>>  ambiguous, so you can't decide how to get th=
e libraryName and=0A>>>  resourceName from the resourceBasePath, and the sp=
ec requires=0A>>>  describe that in a explicit way. Think about a resource =
on:=0A>>> =0A>>>  /de/mydir/myresource.js =0A> (resourceName=3D"de/mydir/my=
resource.js")=0A>>> =0A>>>  will produce this request path:=0A>>> =0A>>> =
=0A> http://{server}[:port]/{appPath}/javax.faces.resource/de_AT/mydir/myre=
source.js=0A>>> =0A>>>  The algorithm will detect de as a locale prefix, my=
dir as a library and=0A>>>  myresource.js as a resource name, but that's wr=
ong because the=0A>>>  resource name is de/mydir/myresource.js. ...."=0A>>>=
 =0A>>>  Are you willing to continue promoting a hack with so many holes, j=
ust =0A> because=0A>>>  makes your code smaller? why don't do things right?=
, and use =0A> resource=0A>>>  handler=0A>>>  API as expected, without any =
bad shorcuts.=0A>>> =0A>>>> =0A>>>>  =C2=A0I suggest to put a VOTE on renam=
ing what we currently have in SVN =0A> and=0A>>>>  =C2=A0re-import Jakobs o=
riginal sources and cleanly start the work from =0A> there.=0A>>>>  =C2=A0R=
eally, we should get back to discuss about what is needed - and =0A> once w=
e=0A>>>  found=0A>>>>  =C2=A0that then we can implement it. Just defining n=
ew features and =0A> checking=0A>>>>  =C2=A0them in 1 minute later just mea=
ns is not ok. I think this should =0A> get=0A>>>>  =C2=A0reverted.=0A>>>> =
=0A>>> =0A>>>  I think that we should agree first on which features should =
be=0A>>>  included. You can=0A>>>  create a branch for this one and start w=
ork there on the mean time.=0A>>>  But first it is=0A>>>  necessary to prov=
ide reasons why that hack is the way to go. At the end =0A> this=0A>>>  dis=
cussion should be about strong and well thought technical reasons. I =0A> j=
ust=0A>>>  can't support that vote knowing its foundation is so weak. I'm =
=0A> always +1=0A>>>  to=0A>>>  make things better, even if that means star=
t over again from scratch. =0A> But at=0A>>>  this moment, my reasoning mak=
es me conclude the code we have on=0A>>>  the svn right now is ok, and if w=
e apply the previous suggestions =0A> (remove gzip=0A>>>  code) the code wi=
ll look better and easier to understand.=0A>>> =0A>>>  regards,=0A>>> =0A>>=
>  Leonardo Uribe=0A>>> =0A>>>>  =C2=A0LieGrue,=0A>>>>  =C2=A0strub=0A>>>> =
=0A>>>> =0A>>>> =0A>>>> =0A>>>>  =C2=A0----- Original Message -----=0A>>>>>=
  =C2=A0From: Leonardo Uribe <lu4242@gmail.com>=0A>>>>>  =C2=A0To: MyFaces =
Development <dev@myfaces.apache.org>; Mark =0A> Struberg=0A>>>  <struberg@y=
ahoo.de>=0A>>>>>  =C2=A0Cc:=0A>>>>>  =C2=A0Sent: Friday, October 28, 2011 3=
:17 AM=0A>>>>>  =C2=A0Subject: Re: [DISCUSS] why do we overcomplicate our c=
ode soooo =0A> much?=0A>>>>> =0A>>>>>  =C2=A0Hi=0A>>>>> =0A>>>>>  =C2=A0I t=
hink you have the wrong impression, basically because you=0A>>>  haven't=0A=
>>>>>  =C2=A0tried to solve each one of the problems that the code try to =
=0A> solve. Is=0A>>>>>  =C2=A0like the blind that try to see the elephant a=
nd say that is =0A> like a=0A>>>>>  =C2=A0tree, because it touching its leg=
.=0A>>>>> =0A>>>>>  =C2=A0To keep things simple, I'll describe and explain =
one by =0A> one each=0A>>>>>  =C2=A0problem "without mercy". Please don't g=
et me =0A> wrong.=0A>>>>> =0A>>>>>  =C2=A01. Which features should be inclu=
ded: The original =0A> functionality=0A>>>>>  =C2=A0proposed by Jakob on th=
e first mail was this:=0A>>>>> =0A>>>>>  =C2=A0- relative paths between res=
ources (css files referencing =0A> images=0A>>>>>  =C2=A0without using #res=
ource['..'])=0A>>>>>  =C2=A0- caching resources in the client (disabled if =
ProjectStage =3D=3D=0A>>>  Development)=0A>>>>>  =C2=A0- GZIP compression a=
nd local cache in tmp dir (disabled if=0A>>>>>  =C2=A0ProjectStage =3D=3D D=
evelopment)=0A>>>>>  =C2=A0- i18n (supporting country code and language).=
=0A>>>>> =0A>>>>>  =C2=A0The current list is this:=0A>>>>> =0A>>>>>  =C2=A0=
- GZIP compression and local cache in tmp dir.=0A>>>>>  =C2=A0- i18n (suppo=
rting country code and language).=0A>>>>>  =C2=A0- Prevent use #{resource['=
...']} on css files, using =0A> prefix=0A>>>  mapping=0A>>>>>  =C2=A0- Pref=
ix mapping automatic detection=0A>>>>>  =C2=A0- Override request path gener=
ation using EL expressions=0A>>>>>  =C2=A0- Redirect library names to preve=
nt duplicate usage against =0A> other JSF=0A>>>  libraries.=0A>>>>> =0A>>>>=
>  =C2=A0If you want to get rid a feature by whatever reason please =0A> se=
nd a vote=0A>>>>>  =C2=A0describing the reasons why that feature is not wor=
th to =0A> include it and=0A>>>>>  =C2=A0should be removed on the next vers=
ion.=0A>>>>> =0A>>>>>  =C2=A0The first thing we need to do is come to an ag=
reement about =0A> how that=0A>>>>>  =C2=A0should looks like. As simple as =
that.=0A>>>>> =0A>>>>>  =C2=A02. You have the impression that the original =
code provided by =0A> Jakob or=0A>>>>>  =C2=A0the code in apache extras wor=
ks correctly. I doubt that. =0A> Probably it=0A>>>>>  =C2=A0works on simple=
 cases but the code has 'holes' that =0A> can't=0A>>>  be fixed=0A>>>>>  =
=C2=A0without take the code in myfaces core about resource handler =0A> and=
 reuse=0A>>>>>  =C2=A0it. To support this point check this:=0A>>>>> =0A>>>>=
>  =C2=A0=C2=A0 =C2=A0 @Override=0A>>>>>  =C2=A0=C2=A0 =C2=A0 public Resour=
ce createResource(String resourceName, String=0A>>>>>  =C2=A0libraryName, S=
tring contentType)=0A>>>>>  =C2=A0=C2=A0 =C2=A0 {=0A>>>>>  =C2=A0=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 FacesContext facesContext =3D =0A> FacesContext.getCurren=
tInstance();=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 String requestedLoc=
alePrefix =3D null;=0A>>>>> =0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 // =
check if libraryName is null and the current =0A> request is a=0A>>>>>  =C2=
=A0resource request=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 // (FIXME th=
is must be done in a better way when =0A> changing=0A>>>>>  =C2=A0JSF's own=
 ResourceHandler in JSF 2.2)=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 if =
(libraryName =3D=3D null &&=0A>>>>> =0A>>> =0A> facesContext.getApplication=
().getResourceHandler().isResourceRequest(facesContext))=0A>>>>>  =C2=A0=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 {=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // extract the libraryName and the locale from the=0A>>>  resour=
ceName=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // --> vali=
d resource url:=0A>>>  de/library/Name/resourceName.css=0A>>>>> =0A>>>>>  =
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // trim any slashes at begi=
n or end=0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resourceN=
ame =3D =0A> ResourceUtils.trimSlashes(resourceName);=0A>>>>> =0A>>>>>  =C2=
=A0Can you see what's wrong? Inclusive it has a note that =0A> says:=0A>>>>=
> =0A>>>>>  =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 // (FIXME this must be done i=
n a better way when =0A> changing=0A>>>>>  =C2=A0JSF's own ResourceHandler =
in JSF 2.2)=0A>>>>> =0A>>>>>  =C2=A0The problem is the code try to extract =
the libraryName from=0A>>>>>  =C2=A0resourceName field. Why?, because the o=
riginal proposal try to =0A> change=0A>>>>>  =C2=A0the way a resource reque=
st path is generated, and make use of =0A> a=0A>>>  "side=0A>>>>>  =C2=A0ef=
fect" when that request path is interpreted by the =0A> default=0A>>>>>  =
=C2=A0ResourceHandler, which put everything on resourceName without =0A> de=
code=0A>>>>>  =C2=A0it.=0A>>>>> =0A>>>>>  =C2=A0If you want to do it right,=
 and have control about what's =0A> going on=0A>>>  it=0A>>>>>  =C2=A0is ne=
cessary to override =0A> ResourceHandler.handleResourceRequest()=0A>>>>>  =
=C2=A0method. That means reuse a lot of code that comes from the =0A> defau=
lt=0A>>>>>  =C2=A0resourcehandler implementation and change it so libraryNa=
me =0A> and=0A>>>>>  =C2=A0resourceName can be decoded correctly and create=
Resource() =0A> method can=0A>>>>>  =C2=A0be called with the right params !=
!!!!!.=0A>>>>> =0A>>>>>  =C2=A0As you can see, all metrics you mention does=
n't say =0A> anything about=0A>>>>>  =C2=A0correctness, and that's the most=
 important thing. This =0A> fact, makes=0A>>>  all=0A>>>>>  =C2=A0previous =
conclusions you claim pure lies, that does not resist =0A> any=0A>>>>>  =C2=
=A0analysis.=0A>>>>> =0A>>>>>  =C2=A03. ".... containing lots of functional=
ity which we NEVER =0A> will=0A>>>  need!=0A>>>>>  =C2=A0..." who says that=
? you? do you have any probe about =0A> that? Please=0A>>>  be=0A>>>>>  =C2=
=A0more specific, otherwise it is not possible to take this kind =0A> of=0A=
>>>>>  =C2=A0comments seriously.=0A>>>>> =0A>>>>>  =C2=A0I think the best w=
ay to solve this is discuss on this thread =0A> point by=0A>>>>>  =C2=A0poi=
nt which features should be excluded and the reasons behind =0A> that.=0A>>=
>>>  =C2=A0Then, when we have an agreement, I invite you to try to create =
=0A> a=0A>>>>>  =C2=A0resource handler that implement such features and the=
n compare =0A> it with=0A>>>>>  =C2=A0the proposed implementation with the =
same features. In that =0A> way we=0A>>>>>  =C2=A0have a fair comparison an=
d finally the community will benefit =0A> of such=0A>>>>>  =C2=A0effort to =
make things better.=0A>>>>> =0A>>>>>  =C2=A0regards,=0A>>>>> =0A>>>>>  =C2=
=A0Leonardo Uribe=0A>>>>> =0A>>>>>  =C2=A02011/10/27 Mark Struberg <struber=
g@yahoo.de>:=0A>>>>>>  =C2=A0=C2=A0=C2=A0 Hi folks!=0A>>>>>> =0A>>>>>>  =C2=
=A0=C2=A0I'm just comparing the original proposal of the =0A> resource=0A>>=
>  handler from=0A>>>>>  =C2=A0Jakob (which works fine)=0A>>>>>> =0A>>>>>> =
=0A>>>>> =0A>>> =0A> http://code.google.com/a/apache-extras.org/p/relative-=
resource-handler/source/checkout=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0and what w=
e do have now in =0A> myfaces-commons-resource-handler=0A>>>>>> =0A>>>>>> =
=0A>>>>> =0A>>> =0A> https://svn.apache.org/repos/asf/myfaces/commons/trunk=
/myfaces-commons-resourcehandler=0A>>>>>  =C2=A0(has problems with multiple=
 servlets - fixed that itmt)=0A>>>>>> =0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0and =
to be honest - I'm freaking out a bit!=0A>>>>>>  =C2=A0=C2=A0Blowing up the=
 code (with almost the same functionality) =0A> to 10=0A>>>  times the=0A>>=
>>>  =C2=A0amount of code and copying tons of code from our other =0A> proj=
ects over=0A>>>  cannot be=0A>>>>>  =C2=A0the right solution. Really, pleas=
e be honest and just compare =0A> the=0A>>>  functionality=0A>>>>>> =0A>>>>=
>>  =C2=A0=C2=A0original config parsing: 110 LOC, working well (java6 =0A> =
specific)=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0new version: 20 classes with ~180=
0 LOC!=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0And all that just to support java5? =
I cannot believe =0A> that! Even if=0A>>>  I need=0A>>>>>  =C2=A0to hack al=
l this myself (without any JAX parser or other =0A> utility), I=0A>>>  don'=
t=0A>>>>>  =C2=A0need more than 200 LOC!=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0->=
 if there is no really good explanation then lets =0A> throw the=0A>>>  cra=
p away.=0A>>>>>> =0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0next stop:=0A>>>>>> =0A>>=
>>>> =0A>>>>>>  =C2=A0=C2=A0package =0A> org.apache.myfaces.commons.resourc=
ehandler.resource;=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0original: 3 classes, ~10=
00 LOC, working=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0myfaces-commons-resource-ha=
ndler: 13 classes, ~ 2400 LOC=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0containing lo=
ts of functionality which we NEVER will =0A> need!=0A>>>>>> =0A>>>>>>  =C2=
=A0=C2=A0But at least this code is undocumented (almost no single =0A> java=
doc)=0A>>>  and=0A>>>>>  =C2=A0contains no unit tests </sarcasm>=0A>>>>>> =
=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0I'm really in the mood to rollback this pr=
oject and =0A> start if=0A>>>  all over=0A>>>>>  =C2=A0again...=0A>>>>>> =
=0A>>>>>> =0A>>>>>>  =C2=A0=C2=A0Really, please, the projects intention was=
 to REPLACE the=0A>>>  overloaded crap=0A>>>>>  =C2=A0we have in the JFS sp=
ec as resource handler with a LIGHT and =0A> powerful=0A>>>>>  =C2=A0altern=
ative. Thus this shall not get bloated and filled with =0A> crap=0A>>>  cop=
ied all=0A>>>>>  =C2=A0over the place.=0A>>>>>> =0A>>>>>> =0A>>>>>>  =C2=A0=
=C2=A0LieGrue,=0A>>>>>>  =C2=A0=C2=A0strub=0A>>>>>> =0A>>>>>> =0A>>>>> =0A>=
>>> =0A>>> =0A>> =0A>