And yes of course you are right :) You can replace String with the Resource
and be able to get keycloak.json from classpath, file or http via spring
properties file (or yml)
Best Regards,
Andrzej
2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo(a)smartling.com>:
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]
http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springf...
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
[image: Latest News + Events]
<
https://app.sigstr.com/uc/55e5d41c6533390d03580000>
[image: Powered by Sigstr] <
http://www.sigstr.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>:
>
> 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
>
> [image: Latest News + Events]
> <
https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <
http://www.sigstr.com/>
>
> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <
> thomas.raehalme(a)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
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>