Hi Jacopo,
Thanks for the explanation about CryptoException, this was really not obvious
to me, nice piece of code BTW.
Then I think we should revert my change and document about the CryptoException
to clarify in case another RuntimeException is crossed.
Will you handle it Deepak?
Jacques
Hi Jacques,
the pattern/best practice you are describing is definitely a valid one,
thanks for your explanations.
However, in this specific case, re-throwing the RuntimeException would not
work because when the field is encrypted with the old algorithm (3-DES),
the new Shiro code will fail to decr
Hi Deepak,
The problem as I see it is that if a RuntimeException is thrown by the 1st version of doDecrypt() then maybe the 2nd version of doDecrypt() will do
so. Maybe I'm wrong here, I did not check each method body.
Actually I think it's more a theoretical issue than a real one because amon
How to manage initial inventory import in OFBiz migrated from the legacy
system?
How to manage initial inventory cost in accounting module?
Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com
Hello,
I noticed many occurrences where service response is not handled properly
and it leads to taking more time while debugging issues.
IMO, every service calling from java/groovy must handle errors by service
util methods such as *isError*, *reutrnError *etc. and similarly in case of
XML <*call
Hi Jacques,
I think we don't need to handle the RuntimeException, as doDecrypt fails to
decrypt then it will try with old pattern, I think this is for backward
compatibility.
Here is the comment from code
try using the old/bad hex encoding approach; this is another path the code
may take, ie if t
