[wildfly-dev] System deployments? WAS: Creating a Keycloak Feature Pack

Brian Stansberry brian.stansberry at redhat.com
Thu Sep 11 14:31:09 EDT 2014


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
>> https://developer.jboss.org/docs/DOC-25627
>>
>> The two comments at the bottom of that page are also relevant to that
>> part of the wiki.
>>
>> Cheers,
>>
> Awesome.  That actually solves several potential problems.  Thanks Brian.
>

You're welcome.

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" "deploy" 
"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.

Cheers,

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list