yes, our cartridge will still function like that
I think what we can do for Karel, is have the realm.json file, for UPS so
he and team can import it into running keycloak.
Our cartridge will stay as is, at least that's my (current) understanding
On Thu, Oct 23, 2014 at 4:07 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
If we go for this let's make sure we have default values.
A lot of people might create an OpenShift App just using the online
interface and not clone it locally (and thus not modify the config files)
On Thu, Oct 23, 2014 at 2:06 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
>
> On Thu, Oct 23, 2014 at 1:51 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>>
>>
>> On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
>>
>>> Hi All,
>>>
>>> I'd like to know your opinion on following changes to UnifiedPush
>>> Server. They are both focused on improving customization process for the
>>> cartridge.
>>>
>>> Just in short, current update process now:
>>> 1/ Clone official git repository of cartridge
>>> 2/ Extract wars and do the modifications or build ones
>>> 3/ Package wars
>>> 4/ Push cartridge to your own repository
>>> 5/ Create cartridge from your own repository
>>>
>>> Whereas, I'm proposing:
>>> 1/ Create cartridge from official repository
>>> 2/ Clone git repository for gear created by Openshift (by default if rhc
>>> is used)
>>> 3/ Modify some files there we expose for user modification
>>> 4/ Push back to make changes live
>>>
>>> What particular configuration elements I'm interested to have
>>> externalized?
>>>
>>> 1/ Ability to load keycloak.json from external location
>>>
>>> => This allows user to create cartridge and modify it prior the first
>>> access. This allows users to configure it to be consumable by other
>>> services automatically, e.g. they can add developer users, roles, etc.
>>>
>>
>> hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj
>> have an idea here
>>
>
> we could have our real in a JSON file, so that it is easy/easier to
> import it into an existing KC server, to run UPS against that
>
>
>>
>>
>>
>>>
>>> 2/ Externalize GCM/APNs locations
>>>
>>> => Now, URLs are hardcoded in GCM/APNs JARs.
>>
>>
>> yes, they are considered stable APIs :)
>>
>> We are not going to 'externalize' these URLs
>>
>>
>>> If they would be loaded
>>> from external location (defaults can still be hardcoded), this allows
>>> user to easily check business logic that queries data in UPS and not
>>> sending any messages. Also allows to put proxy in between UPS and
>>> APNs/GCMs.
>>>
>>> Both these will significantly reduce QE overhead. However, I believe
>>> they are valuable for other as well.
>>>
>>> Feedback and tomatoes (I prefer plum ones) are welcomed.
>>>
>>> Thanks,
>>>
>>> Karel
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog:
http://matthiaswessendorf.wordpress.com/
>> sessions:
http://www.slideshare.net/mwessendorf
>> twitter:
http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog:
http://matthiaswessendorf.wordpress.com/
> sessions:
http://www.slideshare.net/mwessendorf
> twitter:
http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev