On 11/4/2014 6:52 AM, Bill Burke wrote:
On 11/4/2014 5:54 AM, Stan Silvert wrote:
> On 11/4/2014 2:51 AM, Stian Thorgersen wrote:
>> Ok, we'll not include this in Beta1.
>> I'd like to see a solution to deploying providers that:
>> * Can be scripted
>> * Makes life easy for developers
> I assume you mean provider developers? We haven't taken anything away
> from them, so it's at least no harder. They will be able to either use
> exploded mode or run a script.
>> * Can also be done while server is not running (I'm confused to why the
overlays has to be uploaded through a CLI, and can't just be copied to a directory and
manually added to standalone.xml)
> That's a long, long story. Originally, I wanted to have a directory
> for overlays and make it work sort of like a deployment scanner.
> Unfortunately, I found that is impossible for overlays without some
> substantial changes to WildFly. Overlays can't use a deployment scanner
> of any kind.
Why do we need overlays again?
It's for overlaying keycloak-server.json and
adding provider jars and
theme jars. This is especially nice in production where you can just
upload your changes without hacking/rebuilding the WAR.
For developers, you can still just edit the keycloak-server.json that
lives in standalone/configuration.
> Deployments and overlays are never manually added to standalone.xml.
> That's just the way WildFly works. You either upload with a tool like
> CLI or web console, or (if standalone) you let a deployment scanner find
> it. For domain mode, only uploading is allowed.
Requiring a CLI is so Webspherish...Surprised Jason et. al. thought that
was a good idea.
Strangely enough, they thought it was a great idea. Originally,
not going to have a deployment scanner at all. But developers
Deployment scanners do have their problems, which is why they came up
with those weird marker files like *.dodeploy, *.isdeploying,