Bug in External Rest API Example?

[David Steelman]

I have been working through the "External Rest API Example" for Hippo 7.9 at

https://www.onehippo.org/library/concepts/integration/external-rest-api/introduction.html?view=a00938e1-715f-497f-a5c7-bdc0b367adf1

My Rest client class is being configured by a ClientComponentManager class as described in

https://www.onehippo.org/library/concepts/integration/external-rest-api/client-configuration.html?view=cbfcafaa-762b-4949-a3f0-3b602893c591

The issue I have is that on startup, the parameters in the Rest client class are not being configured from the values in the repository -- they are still set to the default values set up in the class. The repository values are not used until the resource bundle document is edited and published in the repository.

My expectation is that the Rest client parameters will be configured from the values in the repository at start, overriding whatever default values are in the Java class.

Am I correct in believing that the example code for the ClientComponentManager class is incomplete, and does not initialize the Rest client parameters on Hippo startup? If so, any pointers on how initializing the parameters from the repository on Hippo startup can be accomplished?

Thanks,

David

[marijan milicevic]

Hi,

looking at the client config example, 

you should call initialize() method yourself, probably after componentManager is initialized (so within setComponentManager). 

I think calling it within init() method might not be possible because componentManager might not be initialized yet.

cheers

marijan

David

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[David Steelman]

Marijan,

I tried adding a call to "initialize" on the "setComponentManager" method of the ClientComponentManager class.

Unfortunately, it looks like the "setComponentManager" is called before the Rest client is constructed by Spring, so I get an exception:

[INFO] [talledLocalContainer] 24.06.2016 07:58:28 WARN  [org.springframework.context.support.AbstractApplicationContext.refresh():486] Exception encountered during context initialization - cancelling refresh attempt
[INFO] [talledLocalContainer] org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.example.rest.client.ClientComponentConfigurationManager#0' defined in file [/apps/git/public-hippo/public-common/target/classes/META-INF/hst-assembly/overrides/client-component-configuration-listener.xml]: Initialization of bean failed; nested exception is org.hippoecm.hst.core.container.ModuleNotFoundException: No Addon Module is found.
[INFO] [talledLocalContainer]     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
[INFO] [talledLocalContainer]     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
...
[INFO] [talledLocalContainer] Caused by: org.hippoecm.hst.core.container.ModuleNotFoundException: No Addon Module is found.
[INFO] [talledLocalContainer]     at org.hippoecm.hst.site.container.SpringComponentManager.getComponent(SpringComponentManager.java:267)
[INFO] [talledLocalContainer]     at org.example.rest.client.ClientComponentConfigurationManager.initialize(ClientComponentConfigurationManager.java:56)
[INFO] [talledLocalContainer]     at org.example.rest.client.ClientComponentConfigurationManager.setComponentManager(ClientComponentConfigurationManagerjava:26)
[INFO] [talledLocalContainer]     at org.hippoecm.hst.site.container.DefaultComponentManagerApplicationContext.postProcessBeforeInitialization(DefaultComponentManagerApplicationContext.java:121)

...

Any suggestions would be appreciated.

Thanks,

David

[marijan milicevic]

Hi,

On Fri, Jun 24, 2016 at 2:08 PM, David Steelman <dsteel...@gmail.com> wrote:

Marijan,

I tried adding a call to "initialize" on the "setComponentManager" method of the ClientComponentManager class.

Unfortunately, it looks like the "setComponentManager" is called before the Rest client is constructed by Spring, so I get an exception:

[INFO] [talledLocalContainer] 24.06.2016 07:58:28 WARN  [org.springframework.context.support.AbstractApplicationContext.refresh():486] Exception encountered during context initialization - cancelling refresh attempt
[INFO] [talledLocalContainer] org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.example.rest.client.ClientComponentConfigurationManager#0' defined in file [/apps/git/public-hippo/public-common/target/classes/META-INF/hst-assembly/overrides/client-component-configuration-listener.xml]: Initialization of bean failed; nested exception is org.hippoecm.hst.core.container.ModuleNotFoundException: No Addon Module is found.
[INFO] [talledLocalContainer]     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
[INFO] [talledLocalContainer]     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
...
[INFO] [talledLocalContainer] Caused by: org.hippoecm.hst.core.container.ModuleNotFoundException: No Addon Module is found.
[INFO] [talledLocalContainer]     at org.hippoecm.hst.site.container.SpringComponentManager.getComponent(SpringComponentManager.java:267)
[INFO] [talledLocalContainer]     at org.example.rest.client.ClientComponentConfigurationManager.initialize(ClientComponentConfigurationManager.java:56)
[INFO] [talledLocalContainer]     at org.example.rest.client.ClientComponentConfigurationManager.setComponentManager(ClientComponentConfigurationManagerjava:26)
[INFO] [talledLocalContainer]     at org.hippoecm.hst.site.container.DefaultComponentManagerApplicationContext.postProcessBeforeInitialization(DefaultComponentManagerApplicationContext.java:121)

...

Any suggestions would be appreciated.

I have to say I don't know much about component manager lifecycle (e.g. the moment it is initialized).

This is getting a bit tricky because of inter/cross app dependencies..

The easiest, but maybe not so elegant solution, could be just  polling of module availability, something like:

final Timer timer = new Timer();

    public void timedInit() {

        timer.scheduleAtFixedRate(new TimerTask() {

            @Override

            public void run() {

                try {

                    initialize();

                    timer.cancel();

                } catch (ModuleNotFoundException ignore) {

                   

                }

            }

        }, 0, 1000);

    }

so, instead of calling initialize() method directly you would call timedInit() method

cheers

marijan

[David Steelman]

Marijan,

I was hoping for a more elegant solution than polling, but that will work for the moment.

I tweaked your code a little bit, and ended up with:

  private final Timer timer = new Timer();

  /**
   * Initializes client configuration from database by polling until client is
   * configured.
   */
  public void timedInit() {
    int initialDelayInMillis = 120000; // Two minutes
    int pollRateInMillis = 10000; // 10 seconds

    timer.scheduleAtFixedRate(new TimerTask() {
      @Override
      public void run() {
        try {
          initialize();
          timer.cancel();

        } catch (ModuleNotFoundException ignoreMNFE) {
          log.trace("Exception while polling", ignoreMNFE);
        }
      }
    }, initialDelayInMillis, pollRateInMillis);
  }

I added an initial delay because some exceptions were getting output to the log from downstream components if the initial tries weren't successful.

I put the call to "timedInit" to the "init" method.

Would it be possible to update the documentation at https://www.onehippo.org/library/concepts/integration/external-rest-api/client-configuration.html with either this solution or a more elegant one?

Thanks,

David

[Woonsan Ko]

Hi David,

The error message, "... No Addon Module is found", literally indicates that you didn't include an HST Addon Module [1].

Probably it occurred in the following lines:

        GoGreenClient client = componentManager.getComponent(GoGreenClient.class.getName(), GoGreenClient.class

                .getPackage().getName());

The code is invoked in #initialize() <- #handleEvent(), so it has nothing to do with container component manager or module context initialization order at all, IMO.

In your specific example, I think you should add the specific addon module example described in the "Move Tested Code to Project" tutorial section [2].

Did you follow it by adding site/src/main/resources/META-INF/hst-assembly/addon/module.xml and others?

Regards,

Woonsan

[1] https://www.onehippo.org/library/concepts/hst-spring/hst-addon-module-support.html

[2] https://www.onehippo.org/library/concepts/integration/external-rest-api/cxf-client.html

[David Steelman]

Woonsan,

I did add site/src/main/resources/META-INF/hst-assembly/addon/module.xml and site/src/main/resources/META-INF/hst-assembly/addon/org/example/rest/client/SpringComponentManager-ignite.xml files as indicated in [2].

I believe the example has an error in which the GoGreenClient is never initialized with the values from the repository at start up. I do not see any way for the "initialize" method in the ClientComponentConfigurationManager class to be called other than through the "handleEvent" method. The "handleEvent" method will only call "initialized" on a very specific publish event. If I am mistaken about this, please let me know.

The error message, "... No Addon Module is found" occurs when I tried adding a call to "initialize" in the "setComponentManager" or "init" methods of the ClientComponentConfigurationManager class (in an attempt to have it initialize the GoGreeClient at startup). I added some System.out.printlns to the methods, as well as created no-argument constructors to see the order in which they are called. In my Hippo 7.9 implementation, the constructor, "setComponentManager" and "init" methods of the ClientComponentConfigurationManager class are all called before the constructor of the GoGreenClient class is called.

At the moment, the timed update mentioned by Marijan seems to be the only way to accomplish initializing the GoGreenClient from the repository at startup. A thought from one of my co-workers -- is there any way that Spring can notify ClientComponentConfigurationManager that the GoGreenClient has been created, and then perform the initialization?

Thanks,

David

[Woonsan Ko]

Hi David,

I haven't tried the example myself, but I'd like to point out something on how it should be done:

- HST initializes its own ComponentManager (creating an ApplicationContext) first.

- And, it scans all the HST Addon Modules and initialize each of those, giving the HST ComponentManager's ApplicationContext to them as a parent ApplicationContext.

- This way, an HST Addon Module application context can make a reference to the beans of parent applicationContext.

- In the parent applicationContext bean configurations, you cannot make a reference to the beans in the child applicationContext (of HST Addon Modules).

- If you add beans in hst-assembly/overrides/*.xml, it means you add custom beans directly to the top parent HST ComponentManager's applicationContext, so the bean definitions cannot make a reference to a bean defined in HST Addon Modules either.

- If a bean implements ComponentManagerAware, the bean is invoked on #setComponentManager() in any level.

Anyway, I guess that's why the example was not initialized with #initialize() method in the first place. If #initialize() is invoked by "init-method" (bean initialization phase), then it can never work because there's no HST Addon Module initialized yet, so it can never get a reference from an HST Addon Module.

That's why it implemented 'kind of' lazy loading in #handleEvent(), assuming when handling an event, it expects all the child HST Addon Modules were initialized, which makes sense.

Therefore, I would like to suggest:

- Keep the 'lazy-loading' technique. But maybe you can implement a new method (#getXXX()) which is solely responsible to retrieve a bean from the HST Addon Module if not referenced yet instead of the confusing method name, #initialize(), with another method, #init().

- Please do not try to get a reference in non-lazy-loading way. e.g. getting a reference in earlier bean init phase through a method defined as init-method.

HTH,

Woonsan

--

w....@onehippo.com     www.onehippo.com
Boston - 745 Atlantic Ave, 8th Floor, Boston MA 02111
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466

[David Steelman]

Woonsan,

There is one additional wrinkle. In order for the ClientComponentManager to retrieve the values from the repository, the repository has to be started. Which doesn't happen until later in the whole process.

Is there an event that gets published when the repository is "ready" for queries, that the ClientComponentManager could listen for? Through a Google search, I found https://www.onehippo.org/7_8/library/concepts/web-application/registering-an-eventlistener-in-your-clientcomponentmanager.html. There does not appear to be a v7.9 or later version of that page, so I don't know if this is still a valid approach.

Thanks,

David

[Woonsan Ko]

Hi David,

We used to have an option (check.repositories.running = true in hst-config.properties) to have HST Container initialization wait for the underlying repository really responding, but unfortunately the option was disabled since Hippo 10.2. [1] We forgot its goodness at the moment.

Please feel free to create an HSTTWO issue for an improvement.

As a workaround, I would try the following at the moment:

- You can add another bean which has an init method (supposed to be invoked through "init-method" while applicationContext being loaded) which is checking the repository status until you get a valid jcr session from the javax.jcr.Repository bean (ID: "javax.jcr.Repository" as well) with looping and thread sleep.

- You can add the bean reference to your real working bean as a property just to make it dependent on repository checking bean.

- Then, probably spring framework initialize in the intended order. So, when second bean is initialized, you will be able to get really responding repository.

Regards,

Woonsan

[1] https://issues.onehippo.com/browse/HSTTWO-3395

[marijan milicevic]

On Mon, Jun 27, 2016 at 9:49 PM, Woonsan Ko <w....@onehippo.com> wrote:

Hi David,

We used to have an option (check.repositories.running = true in hst-config.properties) to have HST Container initialization wait for the underlying repository really responding, but unfortunately the option was disabled since Hippo 10.2. [1] We forgot its goodness at the moment.

Please feel free to create an HSTTWO issue for an improvement.

As a workaround, I would try the following at the moment:

- You can add another bean which has an init method (supposed to be invoked through "init-method" while applicationContext being loaded) which is checking the repository status until you get a valid jcr session from the javax.jcr.Repository bean (ID: "javax.jcr.Repository" as well) with looping and thread sleep.

I believe you get the session within init method, so, I don't think anything else is necessary, no?

cheers

marijan

[David Steelman]

Marijan/Woonsan,

I have added HSTTWO-3724 to Jira, regarding restoring the "check.repositories.running" property.

Since I am using v7.9, would the recommendation be for me to use "check.repositories.running"? We are planning to move to v10 eventually, but hopefully HSTTWO-3724 will be fixed by then?

I will look into Woonsan's suggestion regarding the second bean, in the meantime.

Should I add an additional Jira issue regarding fixing the REST example in the "Integrate with an External REST API" section of the documention? Is HSTTWO the portal to use?

Thanks,

David

[Ard Schrijvers]

Hey David, Woonsan, Marijan et al,

no replies in-line as I think there is a bit of confusion.

The ClientComponentManager has been deprecated in 7.9. Instead, the
HST core org.hippoecm.hst.site.container.SpringComponentManager should
just be used. In the documentation at [1] it is documented to add the
custom spring config to
'site/src/main/resources/META-INF/hst-assembly/overrides/client-component-configuration-listener.xml'
: This way it gets added to the core SpringComponentManager

Wrt 'check.repositories.running' property: This one was still
supported in the 7.9. It has been removed in 3.2 (CMS 10.2) because it
didn't work any more for quite some time (technical reason : since the
jvm enabled users were added). *But* instead of fixing the
'check.repositories.running' it seemed to me to make more sense to
abandon the feature: It seems to me a bad pattern that the HST Spring
component manager creation should be halted and then in some
background thread polling to the repository would be done, and if it
became available, continue starting the Spring component manager.
Imho, the Spring component manager should not be halted on a
repository to become available. None of the *very* many HST Spring
beans we use require a repository to be running during initialization,
but *many* of them use a repository connection : It is just lazy. As
long as the repository is not up, for example the initialization of
the bean fails, and the initialization of the bean is triggered by an
http request.

So, that being said, I see the ClientComponentConfigurationManager
example in [1] isn't clear (at all). It assumes a lazy initialization.
In the init and destroy method (spring bean creation), only
HippoServiceRegistry.registerService is invoked which works when the
repository is not yet up. However, it is not clear when the
#initialize() method is invoked or *who* should do this. That is just
wrong in the example.

The way it would all work (without ever having to wait for the
repository to start) is to add a reference to
ClientComponentConfigurationManager in the GoGreenClient : When the
GoGreenClient is used (probably triggered by a request), it triggers
always ClientComponentConfigurationManager#initialize() : This
#initialize() should return directly if
ClientComponentConfigurationManager is already initialized and *no
event arrived after initialization*. Otherwise, initialize the
GoGreenClient

I hope it is all clear. The biggest issue is the documentation in [1]
being unclear and incomplete. I personally by far prefer that Spring
component manager creation should not be halted by a repository that
is not yet available.

HTH,

If you agree with my reasoning, I'd prefer to close [2] as won't fix.
If we really want something like [2] again, we also should invert the
logic by not having the Spring component manager have some background
thread for polling but a mechanism where a repository that comes up
informs the spring component mngr instead (don't call us, we call
you). However this is part of a much bigger story (in which area we
quite certainly will start working quite soon, but not for the
specific purpose of spring bean creation that requires repository to
be up)

Regards Ard

[1] https://www.onehippo.org/7_9/library/concepts/integration/external-rest-api/client-configuration.html
[2] https://issues.onehippo.com/browse/HSTTWO-3724

On Thu, Jun 23, 2016 at 7:05 PM, David Steelman <dsteel...@gmail.com> wrote:

> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at https://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--

Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466

www.onehippo.com

[David Steelman]

Ard, Woonsan, Marijan, et al.,

I am okay with closing HSTTWO-3724, as long as some alternative solution is found.

The one thing I'm not clear on how to implement is "add a reference to ClientComponentConfigurationManager in the GoGreenClient". Would this be done via Spring? In my testing, the GoGreenClient instance is created after the ClientComponentConfigurationManager instance is created and initialized, so it doesn't seem as simple as having the ClientComponentConfigurationManager instance call a setter method on the GoGreenClient instance. Any sample code would be appreciated.

Thanks,

David

[Ard Schrijvers]

Hey David,

On Tue, Jun 28, 2016 at 8:41 PM, David Steelman <dsteel...@gmail.com> wrote:
> Ard, Woonsan, Marijan, et al.,
>
> I am okay with closing HSTTWO-3724, as long as some alternative solution is
> found.
>
> The one thing I'm not clear on how to implement is "add a reference to
> ClientComponentConfigurationManager in the GoGreenClient". Would this be
> done via Spring? In my testing, the GoGreenClient instance is created after
> the ClientComponentConfigurationManager instance is created and initialized,
> so it doesn't seem as simple as having the
> ClientComponentConfigurationManager instance call a setter method on the
> GoGreenClient instance. Any sample code would be appreciated.

because ClientComponentConfigurationManager bean is not referenced by
GoGreenClient the order in which they are created is not specific.
However Spring takes care of the order if you use a reference. Thus
just adding a setter in the GoGreenClient and add the
ClientComponentConfigurationManager bean ref in the spring bean
definition where the GoGreenClient is created does the job.

You could also alter the GoGreenClient to also have the listener
implemented in the GoGreenClient. If you like the separation of
concerns better, you can use the ClientComponentConfigurationManager.
Note that in the ClientComponentConfigurationManager I consider it
also kind of hackish that this is used:

GoGreenClient client =
componentManager.getComponent(GoGreenClient.class.getName(),
GoGreenClient.class
.getPackage().getName());

Instead of such a hard coded lookup, the GoGreenClient should be
injected in the ClientComponentConfigurationManager by a setter.

Either way, hope this gets you going. Imho the example of the
ClientComponentConfigurationManager is not very good.

Regards Ard

[David Steelman]

Ard, Woonsan, Marijan, et al.,

I was able to modify my Spring configuration to use setter injection to supply the ClientComponentConfigurationManager reference to the GoGreenClient.

Here's a summary of the changes that I made:

1) Added a "configManager" instance variable and getConfigManager/setConfigManager methods on GoGreenClient. Modified the "getTopTenProducts()" method to call the "initialize" method on the ClientComponentConfigurationManager instance. Note: The "getTopTenProducts" method should probably be synchronized (or have a synchronized block) so multiple requests don't try to retrieve objects from the web service. I don't know if there is a better way to handle that.

2) Modified the "hst-assembly/overrides/client-component-configuration-listener.xml" file, adding an "id" attribute for the ClientComponentConfigurationManager bean. This enables the GoGreenClient Spring configuration file to reference it.

3) Modified the "hst-assembly/addon/org/example/rest/client/SpringComponentManager-ignite.xml" file, adding a "property" field to the "GoGreenClient" bean to set the configManager.

4) In the "ClientComponentConfigurationManager" class, modified the "initialized" method to check whether the "initialized" boolean instance variable was true (returning in that case), otherwise ran the rest of the method and set the "initialized" boolean to true. Note: Made the method synchronized, in case multiple near-simultaneous requests were being made.

It would be great if the Hippo documentation could be updated with an improved version. Is there a particular Jira portal I should add an issue to?

Thanks for the help,

David

[Ard Schrijvers]

Hey David,

Thank you for your feedback and great to hear you have it working now.
I'll ask our doctator if he can improve that documentation part.
Apologies for the confusion, it is always hard to make sure that
documentation doesn't rot (just like old code tends to do...it ages
like milk instead of wine)

Regards Ard

[Niels van Kampenhout]

On Wed, Jun 29, 2016 at 10:57 AM, David Steelman <dsteel...@gmail.com> wrote:

Ard, Woonsan, Marijan, et al.,

I was able to modify my Spring configuration to use setter injection to supply the ClientComponentConfigurationManager reference to the GoGreenClient.

Here's a summary of the changes that I made:

1) Added a "configManager" instance variable and getConfigManager/setConfigManager methods on GoGreenClient. Modified the "getTopTenProducts()" method to call the "initialize" method on the ClientComponentConfigurationManager instance. Note: The "getTopTenProducts" method should probably be synchronized (or have a synchronized block) so multiple requests don't try to retrieve objects from the web service. I don't know if there is a better way to handle that.

2) Modified the "hst-assembly/overrides/client-component-configuration-listener.xml" file, adding an "id" attribute for the ClientComponentConfigurationManager bean. This enables the GoGreenClient Spring configuration file to reference it.

3) Modified the "hst-assembly/addon/org/example/rest/client/SpringComponentManager-ignite.xml" file, adding a "property" field to the "GoGreenClient" bean to set the configManager.

4) In the "ClientComponentConfigurationManager" class, modified the "initialized" method to check whether the "initialized" boolean instance variable was true (returning in that case), otherwise ran the rest of the method and set the "initialized" boolean to true. Note: Made the method synchronized, in case multiple near-simultaneous requests were being made.

It would be great if the Hippo documentation could be updated with an improved version. Is there a particular Jira portal I should add an issue to?

Hi David,

Thanks for your this! The Jira project for our product documentation is not public but I created a ticket to review, update and improve this documentation based on your feedback. I'll try to pick this up after the Hippo CMS 11 release.

Regards,

Niels

[David Steelman]

Niels, et al.,

Thanks -- there was one more change I had to make. In the "ClientComponentConfigurationManager" class, I had to reset the "initialized" boolean flag to "false" in the "handleEvent", right before the call to "initialize".

Thanks for the help,

David

[Ard Schrijvers]

Hey David,

On Thu, Jun 30, 2016 at 2:02 PM, David Steelman <dsteel...@gmail.com> wrote:
> Niels, et al.,
>
> Thanks -- there was one more change I had to make. In the
> "ClientComponentConfigurationManager" class, I had to reset the
> "initialized" boolean flag to "false" in the "handleEvent", right before the
> call to "initialize".

Apologies to come with another thing, but I also dislike very much in
the example that it is based on HippoWorkflowEvent handling....for
several reasons. How it should be done is a simple plain jcr event
listener that listens to events on and below
"/content/documents/administration/configuration/rest-client-configuration"
only. Now there is a WorkflowEvent listener used that listens to
*every* workflow event. That is just....well...it just is misusing the
WorkflowEvent for the wrong purpose. Another thing people need to
realize is that in a clustered setup, WorkflowEvent are by *default*
local to the JVM that triggered the workflow. Obviously, you'll need
to reload the GoGreenClient in every cluster node when a change is
done in "/content/documents/administration/configuration/rest-client-configuration"....so
then you'd require (perhaps only for this feature) to use persisted
workflow events so they get broadcasted throughout the entire cluster.
For these reasons, it is much more natural to use a plain jcr event
listener since these are cluster wide by nature of Jackrabbit (the
repository).....
And while I am busy, I consider using a ResourceBundle to store
connection information also an anti-pattern: Instead of some dedicated
project specific document type use a random available document type
that can hold key-value information.

I consider the entire example of the
ClientComponentConfigurationManager convoluted

Regards Ard

[Niels van Kampenhout]

On Wed, Jun 29, 2016 at 2:31 PM, Niels van Kampenhout <n.vanka...@onehippo.com> wrote:

On Wed, Jun 29, 2016 at 10:57 AM, David Steelman <dsteel...@gmail.com> wrote:

Ard, Woonsan, Marijan, et al.,

I was able to modify my Spring configuration to use setter injection to supply the ClientComponentConfigurationManager reference to the GoGreenClient.

Here's a summary of the changes that I made:

1) Added a "configManager" instance variable and getConfigManager/setConfigManager methods on GoGreenClient. Modified the "getTopTenProducts()" method to call the "initialize" method on the ClientComponentConfigurationManager instance. Note: The "getTopTenProducts" method should probably be synchronized (or have a synchronized block) so multiple requests don't try to retrieve objects from the web service. I don't know if there is a better way to handle that.

2) Modified the "hst-assembly/overrides/client-component-configuration-listener.xml" file, adding an "id" attribute for the ClientComponentConfigurationManager bean. This enables the GoGreenClient Spring configuration file to reference it.

3) Modified the "hst-assembly/addon/org/example/rest/client/SpringComponentManager-ignite.xml" file, adding a "property" field to the "GoGreenClient" bean to set the configManager.

4) In the "ClientComponentConfigurationManager" class, modified the "initialized" method to check whether the "initialized" boolean instance variable was true (returning in that case), otherwise ran the rest of the method and set the "initialized" boolean to true. Note: Made the method synchronized, in case multiple near-simultaneous requests were being made.

It would be great if the Hippo documentation could be updated with an improved version. Is there a particular Jira portal I should add an issue to?

Hi David,

Thanks for your this! The Jira project for our product documentation is not public but I created a ticket to review, update and improve this documentation based on your feedback. I'll try to pick this up after the Hippo CMS 11 release.

Follow-up:

The example has been reworked by William and Ard and the documentation pages have been updated and put back online:

https://www.onehippo.org/library/concepts/integration/external-rest-api/introduction.html

Thanks,

Niels

 

Regards,

Niels

 

>> > To post to this group, send email to hippo-community@googlegroups.com

>> > RSS:
>> >
>> > https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Hippo Community" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an

>> > email to hippo-community+unsubscribe@googlegroups.com.

>> > Visit this group at https://groups.google.com/group/hippo-community.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
>> Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
>> states of America.
>>
>> US +1 877 414 4776 (toll free)
>> Europe +31(0)20 522 4466
>> www.onehippo.com
>>
>> --
>> Hippo Community Group: The place for all discussions and announcements
>> about Hippo CMS (and HST, repository etc. etc.)
>>

>> To post to this group, send email to hippo-community@googlegroups.com

>> RSS:
>> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Hippo Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to hippo-community+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/hippo-community.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>

> To post to this group, send email to hippo-community@googlegroups.com

> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to hippo-community+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--
Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)

To post to this group, send email to hippo-community@googlegroups.com

RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 

To post to this group, send email to hippo-community@googlegroups.com

RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.