hi shane,
@#tryLogin:
ok - since we can provide a simplified handling for important use-cases -
i'm ok with it.
@#login:
matt answered it already (it even works with jsf 1.2)
@#hasRole (overloaded)
agreed - i also don't like that one. if we keep #tryLogin, we should use
the same naming
[
https://issues.apache.org/jira/browse/DELTASPIKE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-88:
---
Description:
this approach allows to keep the api simple and methods which are
Hi Pete!
fluent api is fine for me.
The reason why the context control is so fine granular is that you don't have
any well defined extension points in an SE app. Thus the application must
perform those steps itself.
Imagine a Swing App.
A Request could be a user interaction.
A
I think there are a few key things to keep in mind for our security
solution:
1. Accurate, intuitive documentation with a clear path to get started.
2. Technically correct implementation that allows for things like custom
password encryption strategies.
3. Consistent API/SPI package
Aha, so this is mixing bootstrap and context lifecycle management? If so, I
would prefer we keep these as two separate APIs. I can make a proposal for a
context lifecycle management api based on what we have in Weld.
On 15 Feb 2012, at 17:17, Mark Struberg wrote:
Hi Pete!
fluent api is
