[JAVASERVERFACES_SPEC_PUBLIC-342] Add a component for easy Form Based Login Created: 13/Mar/08  Updated: 01/Aug/14  Resolved: 24/Jan/14

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: driscoll Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 342
Status Whiteboard:

cat3 frame size_medium importance_medium


I'd like to do form based authentication within JSF.

From what I've read, I need to do one of three things:

1) Use somebody else's custom component.
2) Write my own custom component.
3) Do some convoluted stuff as described at:

Are there any other options?

If there are not, I'd like to propose that there should be: this isn't exactly
an edge case for IT developers, and JSF should offer, at a minimum, a component
which does this easily and seamlessly.

Comment by Ed Burns [ 16/Apr/08 ]

Do you imagine this component needs any mods to the servlet spec we should file
against them?

Comment by driscoll [ 16/Apr/08 ]

Actually, no.

I'm working on a custom component already, and it should work without any
modifications. While we could just make it available via a third party library,
this seems a common enough task for any Java EE based application that it should
be a core component. Of course, that's a judgment call, and up for debate.

There would seem to be three different ways to go in designing such a component

  • a simple component that would be styled via CSS, a more complex component
    with, say, facets that would be more straightforward to style, and a fully
    featured, rather complex component like the one included in the Woodstock library.

My current, personal preference is for a very simple component, useful for
prototyping or even production with a robust CSS file - leaving the more complex
options to a third-party library.

Comment by Ed Burns [ 09/Sep/08 ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by Ed Burns [ 04/Mar/10 ]


Comment by Ed Burns [ 22/Mar/10 ]


Comment by rogerk [ 17/Jun/10 ]


Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 31/Jan/11 ]

I think this really belongs in a JSR for standard jsf UI components.

Comment by kellerapps [ 18/Apr/11 ]

primefaces, etc. replace all the JSF UI components anyway. These libraries don't work well together visually or functionally but at least they leverage the JSF foundation. It would be so nice if programmers could cherry-pick from the different libraries. That won't happen wo/ the JSF community rallying around a look-and-feel standard like Nimbus.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Thu Apr 27 02:31:24 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.