On 9/11/14, 12:20 PM, Stan Silvert wrote:
On 9/10/2014 5:24 PM, Brian Stansberry wrote:
> On 9/10/14, 1:47 PM, Stan Silvert wrote:
>> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed
>> as a WAR. We can use the copy-artifacts mechanism to simply copy the
>> WAR into the deployments directory. But that doesn't work for a domain
>> where you want to have the WAR pre-loaded into the content repository.
>> Furthermore, it's probably not the best way to integrate this for
>> standalone either.
>> What would be a better option?
> See the "A Mixed Approach" section at
> The two comments at the bottom of that page are also relevant to that
> part of the wiki.
Awesome. That actually solves several potential problems. Thanks Brian.
The drawback I mentioned there is these deployments appear in the
resource tree alongside the regular user deployments. That's not ideal,
because things can happen like the user undeploying or removing the
deployment, plus it just mixes things that are somewhat separate.
We've briefly discussed in the past the idea of having a
"system-deployment" tree that looks just like the "deployment" tree
except the registration of the handlers for the "add", "remove"
"undeploy" ops would have a flag added that marks them as private, so
they don't show up in the public API. They can still be invoked
internally by subsystem though.
The change to that "fibo" example in the wiki would be minimal.
This would impact the console's "Runtime" tab, as it's another tree of
runtime data to present. Also, these deployments wouldn't appear in the
Content Repository tab, which in general is good, although there may be
some subtle UX effects.
It would also change the location in the tree at which these things
appear from EAP 6.x to EAP 7.x, but I don't think that's a big deal.
What do folks think about pursuing this? Mazz, your opinion would be useful.
Senior Principal Software Engineer
JBoss by Red Hat