This could be done if the constructor argument is a Spring Resource[0] instead of a
string. It doesn’t help with multi-tenant support but it’s still an improvement.
[0]
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<
On Sep 28, 2015, at 5:04 PM, Andrzej Goławski
<andipansa(a)gmail.com> wrote:
Hi
Why not do it via contructor:
public AdapterDeploymentContextBean(String configFile){
.....
}
and in BasicKeycloakWebSecurityConfigurationAdapter add:
@Value("${keycloak.configFile:WEB-INF/keycloak.json}")
private String keycloakConfigFile;
@Bean
protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
return new AdapterDeploymentContextBean(keycloakConfigFile);
}
Best Regards,
Andrzej
2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo(a)smartling.com
<mailto:srossillo@smartling.com>>:
Based on the other feedback and the Spring way of providing as many configuration options
as possible, I think we should refactor AdapterDeploymentContextBean.
However, I rather like the way Spring that divides behavior up into an interface and
multiple implementations. I think we should:
1. Refactor the current AdapterDeploymentContextBean to be an interface and maybe rename
it AdapterDeploymentContextFactory.
2. Split the current implementation into:
a. ClasspathAdapterDeploymentContextFactory > loads from class path
b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
c. JndiAdapterDeploymentContextFactory > load from JNDI
3. The above implementations should extend AbtractAdapterDeploymentContextFactory with
something like:
protected loadKeycloakDeployment(Resource resource) {
return KeycloakDeploymentBuilder.build(resource.getInputStream());
}
That would allow anyone to provide a custom AdapterDeploymentContextFactory to load the
keycloak.json from “anywhere."
What do you think? Since we’re refactoring, I’d also like to take into account design
multi-tentant support. I think this approach is flexible enough to add that in the
future.
If we agree this is a good approach you want to take a stab at it Thomas or should I?
Best,
Scott
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
<
https://app.sigstr.com/uc/55e5d41c6533390d03580000>
<
http://www.sigstr.com/>
> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com
<mailto:thomas.raehalme@aitiofinland.com>> wrote:
>
> Hi!
>
> We have written a custom subclass of
org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable custom
location for keycloak.json. The use of custom location is optional and defaults to the
standard /WEB-INF/keycloak.json.
>
> Our use case is that for developers we have a default keycloak.json included in the
application. In production, however, we override the default by using a file that is
external to the application. The location of the file is specified in JNDI settings and
injected to our subclass with the help of Spring.
>
> What do you think would such an extension to AdapterDeploymentContextBean be of
general use? I'd be happy to merge our subclass to AdapterDeploymentContextBean and
submit a pull request.
>
> Best regards,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>