-
1. Re: Define security domain inside ear/war
ybxiang.china Aug 5, 2013 12:34 AM (in response to arjant)Sugguestion is Removed.
...
Sorry, I misunderstand you.
-
2. Re: Define security domain inside ear/war
sfcoy Aug 4, 2013 11:49 PM (in response to arjant)Arjan t wrote:
...
The war or ear that I have must be fully self-sufficient and should be able to be deployed to a generic JBoss AS 7.x server without any dependency on its standalone.xml.
...
Why? It is best practice to externalise configuration, and standalone.xml and friends is the place to do this.
Typically, I would deliver the (enviroment independent) deployable artifacts together with a CLI script that configures the environment.
-
3. Re: Define security domain inside ear/war
arjant Aug 5, 2013 9:40 AM (in response to sfcoy)Stephen Coy wrote:
Why? It is best practice to externalise configuration, and standalone.xml and friends is the place to do this.
I don't agree with that. It's highly dependent on the situation if that is a best practice or not. Thinking that externalizing things is unconditionally a best practice is the major reason that data sources, JMS queues, mail sessions and what have you were administrative objects only in older versions of Java EE. This thinking has been damaging to Java EE, and the EG finally acknowledged that (in Java EE 7 these all can be defined from within the archive as well).
For devops teams that develop an in house application that only runs an internal servers, and where these servers run one app and one app only, mandatory externalizing is not a best practice. For certain cloud deployment scenarios, for people learning about Java EE and for Java EE examples and tutorials it's also not a best practice. Plus, you can't know what people exactly use the security domain for. It might well be completely and utterly local to an application, making no sense whatsoever to have it installed and/or configured at a central place (this was the same argument for having JMS queues defined locally).
It's a bit like EJB's mandatory business interfaces (since interfaces are a best practice, aren't they?). However forcing interfaces was not a best practice as there are situations where they simply don't make sense.
In this case I'm working on a kind of TCK where a number of war archives are deployed to different servers (JBoss, GlassFish, Geronimo, etc) and there subjected to integration tests. I don't really need a security domain, but it's needed to work around a JASPIC issue where the EJB interceptor thinks it needs one.
Anyway, letting the discussion whether it's a bad practice or not rest for a second, do you think (or know) if what I asked is possible in JBoss AS 7.x?
-
4. Re: Define security domain inside ear/war
ybxiang.china Aug 5, 2013 10:56 AM (in response to arjant)1 of 1 people found this helpfuldo you think (or know) if what I asked is possible in JBoss AS 7.x?
~~~~~~~~~ As far as I know, I think it is impossible. Maybe I am wrong.
-
5. Re: Define security domain inside ear/war
arjant Aug 5, 2013 11:11 AM (in response to ybxiang.china)xiang yingbing wrote:
~~~~~~~~~ As far as I know, I think it is impossible. Maybe I am wrong.
Would be a shame really. I'll try to dig a little through the JBoss source later to see if there's indeed no option. Thanks anyway!