On 2/28/13 10:33 AM, Kabir Khan wrote:
Perhaps the pull request job should be set up to use the security
manager, and the master-ignore job to not use a security manager
Sounds good. Everything goes through param-pull, so make it the most
My assumption is it would be a rare thing to introduce a bug that passes
with a security manager but fails without.
(or the other way round).
Less good. I occasionally skip master-ignore and just merge something
once it's passed param-pull, if I know the param-pull test ran against
latest master. I roll the dice that the teamcity Windows tests of
master-ignore wouldn't have found a problem. :) But I wouldn't want to
roll the dice on both security manager and Windows.
That way pretty much everything should be tested both ways before
Then the question is what to do with the master job which runs every time something is
merged into master. Perhaps we need another job, running once a day, which runs with the
opposite security manager config from the master job?
+1. I'd say the regular master job runs with the security manager.
Again, make the more common test the more stringent one.
On 28 Feb 2013, at 15:52, David M. Lloyd wrote:
> The AS codebase now supports running under a security manager. Well,
> sort of. There are a few places where we need privileged blocks and/or
> permission checks, but you can boot up AS under a security manager today
> if you want. Just follow these steps:
> 1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
> Well, I guess there's just the one step. Anyway I've noticed that the
> impact on startup time is not as bad as I had expected, which is good.
> So the question is: Should we set up a security manager-enabled test
> run? How should it work?
> - DML
> jboss-as7-dev mailing list
Prinicipal Software Engineer
JBoss by Red Hat
jboss-as7-dev mailing list
Principal Software Engineer
JBoss by Red Hat