Leo, NO, please read again:
1. Small key size used to store views into session vs go back to the
old way.
Take a safe approach. Adding just the hashCode doesn't make it more
safe. Either the full viewId or get rid of it completely if not needed.
2. use the hashCode of the viewId
Mark Struberg created MYFACES-3642:
--
Summary: enable console output for checkstyle
Key: MYFACES-3642
URL: https://issues.apache.org/jira/browse/MYFACES-3642
Project: MyFaces Core
Issue
[
https://issues.apache.org/jira/browse/MYFACES-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-3642.
Resolution: Fixed
fixed in myfaces parent 15
enable console output for
Mark Struberg created MYFACES-3643:
--
Summary: upgrade myfaces parent to apache-parent 12
Key: MYFACES-3643
URL: https://issues.apache.org/jira/browse/MYFACES-3643
Project: MyFaces Core
[
https://issues.apache.org/jira/browse/MYFACES-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-3643.
Resolution: Fixed
fixed in myfaces-parent 15
upgrade myfaces parent to
Mark Struberg created MYFACES-3644:
--
Summary: cleanup ViewState handling
Key: MYFACES-3644
URL: https://issues.apache.org/jira/browse/MYFACES-3644
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-3638.
Resolution: Fixed
NPE in ServerSideStateCacheImpl
---
On Thu, Nov 15, 2012 at 12:37 AM, Mark Struberg strub...@yahoo.de wrote:
1. Small key size used to store views into session vs go back to the old way.
Take a safe approach. Adding just the hashCode doesn't make it more safe.
Either the full viewId or get rid of it completely if not needed.
On Wed, Nov 14, 2012 at 8:17 PM, Leonardo Uribe lu4...@gmail.com wrote:
Note that myfaces code already uses an strict checkstyle policy.
But maybe the policy needs improving. checkstyle reviews, but not
proves, good style. And it is only as good as the rules it was
given.
I'm currently reviewing all this area. It seems that we have quite some stuff
to improve.
a.) just a gut feeling yet, but my tummy tells me that we have to review our
key generator/storage strategies. Too complicated or too badly documented. At
least they are not self describing.
b.)
Mark Struberg created MYFACES-3645:
--
Summary: review/refactor/document ViewState handling
Key: MYFACES-3645
URL: https://issues.apache.org/jira/browse/MYFACES-3645
Project: MyFaces Core
On Thu, Nov 15, 2012 at 10:28 AM, Mark Struberg strub...@yahoo.de wrote:
b.) candidate 1: CounterKeyFactory. If we like to prevent reboot clashes then
we might add another int which contains a random value. Think about having a
Server with a single page right now. Click on it a few times,
You are completely right.
* If the session gets passivated and restored on server restart, we will still
get the next number - no collision
* if the session gets moved to another node it usually gets rewritten - no
collision
* if the session doesn't get passivated on server reboot we will get
I now refactored the classes into an own viewstate package, moved out the inner
classes and added a bit JavaDocs.
I think this gives a much better overview about the complexity of this area.
This is always the first step towards improving something.
LieGrue,
strub
- Original Message
another one:
All that stuff has nothing to do with the RenderKit and should go into
org.apache.myfaces.application.viewstate.
wdyt?
Also the following classes are related and should imo get moved to this new
package:
* StateCache
* StateCacheFactory
* StateManagerImpl
LieGrue,
strub
[
https://issues.apache.org/jira/browse/MYFACES-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498102#comment-13498102
]
Mark Struberg commented on MYFACES-3645:
quite some configuration gets resolved
Hi
MS And now for your 'turning around my words'
MS 1. Go back to the old way, just one class.
MS NO definitely not, see my answer 3
MS 2. The viewId is not important -- get rid of it.
MS NO, FIRST check if it is important, then either get rid or fix it.
MS 3. Split ServerSideStateCacheImpl
Leo, it seems you are the only one with understanding my answer so far.
You are just searching for lame excuses that you can revert the code. As you
did very often already with other committers. And you already pissed off quite
a few people that way. So just stop it and start working as
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
I'm currently reviewing all this area. It seems that we have quite some stuff
to improve.
a.) just a gut feeling yet, but my tummy tells me that we have to review our
key generator/storage strategies. Too complicated or too badly documented.
gnn
Leo, it seems you are the only one with understanding my answer so far.
should have been
'the only one with having troubles understanding my answer so far.'
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: MyFaces Development dev@myfaces.apache.org
I did further reviews:
Currently the CounterKeyFactory needs some random to be unique (according to
Leo) and the RandomKeyFactory needs a counter to be unique.
Does that ring a bell? That stuff is completely useless!
Foolks wake up, let's provide ONE factory which is waterproof. That
Btw, I still do not see where the trick for storing a separate state list for
each browser tab is hidden.
That was the goal of all the refactoring initially. Where is that done?
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: MyFaces Development
We have 2 StateManager implementations. Guess the following classes can now get
deleted?
* JspStateManagerImpl
* MyfacesStateManager
or alternate question: the HtmlResponseStateManager extends
MyfacesResponseStateManager.
If we keep that pattern, why does the StateManagerImpl which seems to
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Leo, it seems you are 'the only one with having troubles understanding my
answer so far.'
Yes, I want to understand and I have troubles understanding your
answers. I don't care if I'm the only one in the world who can't
understand. Please explain
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
We have 2 StateManager implementations. Guess the following classes can now
get deleted?
* JspStateManagerImpl
* MyfacesStateManager
or alternate question: the HtmlResponseStateManager extends
MyfacesResponseStateManager.
If we keep that
Mark Struberg created MYFACES-3646:
--
Summary: remove unused src/main/old from core-impl
Key: MYFACES-3646
URL: https://issues.apache.org/jira/browse/MYFACES-3646
Project: MyFaces Core
Issue
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
I did further reviews:
Currently the CounterKeyFactory needs some random to be unique (according to
Leo) and the RandomKeyFactory needs a counter to be unique.
Does that ring a bell? That stuff is completely useless!
A random generator does
We currently have the discussion about how we use the ProjectStage. Do we like
to use it excessively for all kind of tweaks or only where it is needed to
enable caching for production.
The reason for this vote is that we had some usage of
if(ProjectStage.Production) which caused a bug in
Hi!
How many state key algorithms do we really need? Since all the state keys are
encrypted later on anyway, this has NOTHING to do with security (just to
prevent off-topic discussions)!
[ ] We need exactly one good which is well performing and ensures that no
collision can happen.
[ ] We
oki, great. Let's get rid of it. It just makes it harder to read the code and
do maintenance.
I gonna creat a JIRA for it and remove it.
LieGrue,
strub
- Original Message -
From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Development dev@myfaces.apache.org; Mark Struberg
Mark Struberg created MYFACES-3647:
--
Summary: remove JspStateManagerImpl and other unused stuff in this
area
Key: MYFACES-3647
URL: https://issues.apache.org/jira/browse/MYFACES-3647
Project:
[
https://issues.apache.org/jira/browse/MYFACES-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-3646.
Resolution: Fixed
Fix Version/s: 2.1.10
remove unused src/main/old from
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Btw, I still do not see where the trick for storing a separate state list for
each browser tab is hidden.
That was the goal of all the refactoring initially. Where is that done?
Mark, months ago we created 2.1.x-client-window branch:
what does that 'cache'?
Imo exactly nothing. This is not a 'cache'. A cache stores information it gets
somewhere so it doesn't need to be resolved again. But those 2 classes do not
cache anything. They 'manage' state, but they do not 'cache' state.
I rather to back to the old names.
+1 for #1
(messages e.g. in case of command components outside of a form and
refreshing caches should be enough for project-stage development)
regards,
gerhard
2012/11/15 Mark Struberg strub...@yahoo.de
We currently have the discussion about how we use the ProjectStage. Do we
like to use it
StateCache is defined as generic StateCacheK,V but the implementations do
some hardcoded upcast:
public Object restoreSerializedView(FacesContext facesContext,
String viewId, Object viewState)
{
Object[] state = (Object[]) viewState;
That's just vodoo. Either the
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
what does that 'cache'?
Imo exactly nothing. This is not a 'cache'. A cache stores information it
gets somewhere so it doesn't need to be resolved again. But those 2 classes
do not cache anything. They 'manage' state, but they do not 'cache'
+1 for keeping it pluggable and providing optional implementations if there
are real-world use-cases for them.
regards,
gerhard
2012/11/15 Mark Struberg strub...@yahoo.de
Hi!
How many state key algorithms do we really need? Since all the state keys
are encrypted later on anyway, this has
Leo, I'm ok with a revert. But not to your version but to the original
JspStateManagerImpl!
Really, this currently feels so overcomplicated without giving much benefit. It
would have been perfectly enough to remove the viewId String and replace it
with a XORShift random value if you don't
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Leo, I'm ok with a revert. But not to your version but to the original
JspStateManagerImpl!
Really, this currently feels so overcomplicated without giving much benefit.
It would have been perfectly enough to remove the viewId String and
2012/11/15 Mark Struberg strub...@yahoo.de:
StateCache is defined as generic StateCacheK,V but the implementations do
some hardcoded upcast:
public Object restoreSerializedView(FacesContext facesContext,
String viewId, Object viewState)
{
Object[] state =
Leo, the stuff which currently got changed is nothing more than just your code.
I only refactored it into an own package and moved the inner classes to
toplevel to show up the complexity of the solution. There was no code change
_yet_ other than the viewId. We can change back the viewId to the
what's the need for such an abstraction?
It just makes dealing with that stuff harder and slower.
We know exactly what format we get and store.
LieGrue,
strub
- Original Message -
From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Development dev@myfaces.apache.org; Mark Struberg
Btw, the implementation shares state via the context map using
RendererUtils.SEQUENCE_PARAM all over the place.
Please check the usage of RendererUtils.SEQUENCE_PARAM!
Again: I think you splitted this up way too fine grained and now you need a way
to hand over information via bypassing your own
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Leo, the stuff which currently got changed is nothing more than just your
code. I only refactored it into an own package and moved the inner classes to
toplevel to show up the complexity of the solution. There was no code change
_yet_ other
You did more than that. You removed the following classes:
IntIntSerializedViewKey
IntByteArraySerializedViewKey
ReferenceSerializedViewKey
Those have been almost 1:1 clones of other classes. Go check SerializedViewKey,
it contains all the merged functionality. Without any performance
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
You did more than that. You removed the following classes:
IntIntSerializedViewKey
IntByteArraySerializedViewKey
ReferenceSerializedViewKey
Those have been almost 1:1 clones of other classes. Go check
SerializedViewKey, it contains all the
Leo, it would be great if you reflect a bit.
I have checked the code. I know what SerializedViewKey does.
good! no other arguments? Well, then all is fine it seems.
it is YOU the one who are reverting code done by other people
The only code I ever reverted in MyFaces was your revert of my
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Leo, it would be great if you reflect a bit.
I have checked the code. I know what SerializedViewKey does.
good! no other arguments? Well, then all is fine it seems.
it is YOU the one who are reverting code done by other people
The only code
But you reverted the changes I did months ago. Didn't you? oh yes, you
refactor it and get rid what you don't like.
That is OSS Leo. We take what we find and improve it. This is not a revert -
this is evolution!
There is no such thing like 'my code' in the ASF.
That's unfair. I don't
Grant, there is no change. Compare the versions. If we take back the hashCode
then it's really only moving inner classes to own java files and remove
duplicate code. Those tons of classes haven't been written by me, they have ALL
been in the code already - just hidden as 1000++ LOC of inner
As an observer to this argument and someone whose clients depend on
the stability of the code base, such a refactoring so close to
release seems like a bad idea. Why not do this after the release?
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Nov 15, 2012, at 6:36 PM,
Kito, there was no single word inside the PMC that the release will be next
week. I just again scanned our internal mailboxes to verify that. Leo is just
adding another messy argument which is not funded.
Of course there will be a release soon, but there was no agreed date yet.
And again:
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
But you reverted the changes I did months ago. Didn't you? oh yes, you
refactor it and get rid what you don't like.
That is OSS Leo. We take what we find and improve it. This is not a revert -
this is evolution!
There is no such thing like
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
Kito, there was no single word inside the PMC that the release will be next
week. I just again scanned our internal mailboxes to verify that. Leo is just
adding another messy argument which is not funded.
Of course there will be a release soon,
The usual release cycle is 2 to 3 months. The next expected release is
early/mid November and not next week. If you are too stressed I can take over
doing the release.
Let's make a deal, let me do it myself. I just take a snapshot of your
changes,
revert, and apply only the refactoring
On Thu, Nov 15, 2012 at 6:54 PM, Kito Mann kito.m...@virtua.com wrote:
As an observer to this argument and someone whose clients depend on
the stability of the code base, such a refactoring so close to
release seems like a bad idea. Why not do this after the release?
Releases are just
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
The usual release cycle is 2 to 3 months. The next expected release is
early/mid November and not next week. If you are too stressed I can take over
doing the release.
Today is 15 of November, I plan start release one week, if there is a
Hi
I'll proceed with the necessary changes now. I hope to get it done tomorrow.
regards,
Leonardo
2012/11/15 Leonardo Uribe lu4...@gmail.com:
Hi
2012/11/15 Mark Struberg strub...@yahoo.de:
The usual release cycle is 2 to 3 months. The next expected release is
early/mid November and not
On Thu, Nov 15, 2012 at 7:41 PM, Mark Struberg strub...@yahoo.de wrote:
Btw you should either copy over Tom and Manfreds @author from the
JspViewStateManager or remove your own @author from the copied class as it is
still 80% the old code.
I am fairly certain we did away with @author tags
[
https://issues.apache.org/jira/browse/MYFACES-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498535#comment-13498535
]
Leonardo Uribe commented on MYFACES-3647:
-
deferred to 2.2
The JSF-2.0 spec came out in early 2009. There is a clarification/bugfix
release 2.1 of the spec available since over 2 years now and we actively
maintain MyFaces-2.1.x
Thus I like to suggest moving MyFaces-2.0.x into maintenance mode.
It's purely crazy that we backport any change from 2.1.x
[
https://issues.apache.org/jira/browse/MYFACES-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498656#comment-13498656
]
Mark Struberg edited comment on MYFACES-3647 at 11/16/12 7:31 AM:
[
https://issues.apache.org/jira/browse/MYFACES-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498656#comment-13498656
]
Mark Struberg commented on MYFACES-3647:
no, deferred to 2.1.11 or 2.2 depending
what is this commit for? there is no JIRA in it and it has nothing to do with
the release rollback.
- Original Message -
From: lu4...@apache.org lu4...@apache.org
To: comm...@myfaces.apache.org
Cc:
Sent: Friday, November 16, 2012 4:37 AM
Subject: svn commit: r1410190 - in
there seems to be a UTF character in the JavaScript you committed ('Â'). This
might be broken on a few browsers.
Or is this only a commit mail artifact? (which I don't believe)
- Original Message -
From: lu4...@apache.org lu4...@apache.org
To: comm...@myfaces.apache.org
Cc:
+1
LieGrue,
strub
PS: vote is open for 72h with lazy consensus (as always if nothing else stated)
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: My Faces Development dev@myfaces.apache.org
Cc:
Sent: Friday, November 16, 2012 8:25 AM
Subject: [VOTE] switching
67 matches
Mail list logo
