I see your point, but I have to agree with Bill that it's not what a user expects. We
should let DUPs push/pop the specified domain in an attachment.
Sent from my iPhone
On Mar 12, 2014, at 2:40 PM, Anil Saldhana
<Anil.Saldhana(a)redhat.com> wrote:
It is subjective about assuming reasonable defaults.
In the case of EARs, historically, we used the security domain
at the EAR level for all the containing web,ejbs that were missing
explicit security domains.
A security domain is an abstract concept to define boundaries for
authentication, authorization, mapping,audit etc.
So a web app may use different security domain compared to an EJB
application.
In the case of web archives containing EJB applications, the options are:
a) Make the EJB define the security domain explicitly to be the one used
by the web app.
b) Make the EJB inherit the security domain used by the web app if missing.
c) Make the EJB default to "other" if a security domain is missing.
If we go with c) like it is now, a developer can test his application
and see that his EJB application is not working
as he intends. Then he can either opt for a) or leave it as c)
The danger with option b) is if someone put the war in production and
the EJB application does not 'fail fast'.
But if people on this list feel that b) is the better usable solution,
then we should go for it.
> On 03/12/2014 08:16 AM, Bill Burke wrote:
> I noticed that if you define a WAR's security domain and then define an
> EJB within WEB-INF/classes, that EJB's default security domain is
> "other" and not the WAR's security domain.
>
> Don't you think it would be more user friendly and intuitive for nested
> components' security domain to be inherited from their parent container
> rather than defaulting to "other"?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev