Yes, turns out that postback was the simplest way and it populates the
sensors very nicely.

I do have a suggestion for the VanillaJavaApp.    It is possible to set up
more than one instance of such an entity of this type within an
application, which is great for my use case, but as far as I can tell, they
cannot all be shut down without a trick.   I need to run 16-20 instances of
VanillaJava apps from a single Brooklyn application instance.

It turns out that if a Brooklyn App launches more than one VanillaJavaApp.
there is still only one PID file which is generated -- containing only one
of the pids.  So when shutting down, only one of the Java child processes
can be killed from the Brooklyn CLI or UI.  I tricked the system by having
each of the child Vanilla apps periodically check for the existence of the
PID file.   When it is no longer there (because one of the Java apps has
been killed),  each of the other apps just initiates its own exit.   Did
that make sense?

My solution:   Add an attribute to the VanillaApp  to allow one to specify
its own PID filename, or another way to shut down its app, perhaps via JMX

Peter

On Wed, Mar 13, 2019 at 1:03 PM Geoff Macartney <[email protected]>
wrote:

> Hey Peter,
>
> Ah cool, so you are actually posting *to* Brooklyn from the app itself? If
> you have the flexibility to do that, that's great. Glad it's working out.
>
> Do let us know any thoughts you have about your experience with Brooklyn,
> usability, usefulness etc. All feedback is welcome!
>
> Best,
> Geoff
>
>
>
>
> On Tue, 12 Mar 2019 at 23:36 Peter Abramowitsch <[email protected]>
> wrote:
>
> > Thanks Geoff,
> > About ten minutes after I posted,I  realized I could just use the
> Brooklyn
> > REST API.  I just needed to launch the java app with a system property
> > containing the composed URLbase and credentials to post back with.   It
> > works great and is much easier than JMX.
> >
> > On Mon, Mar 11, 2019, 2:56 PM Geoff Macartney <[email protected]
> >
> > wrote:
> >
> > > Hi Peter
> > >
> > > I'd say an MBean is a reasonable way to expose that sort of thing to
> > > Brooklyn (or any management/orchestration tool) for a Java app.  I
> guess
> > > there would be other ways of doing it without JMX but they might be
> more
> > > ad-hoc, while this is just the sort of thing JMX is for.
> > >
> > > Since you're already thinking about using (extending) VanillaJavaApp in
> > > Brooklyn to manage your app,  you could look into adding sensors for
> > > whatever MBeans you want to expose from your app using JmxFeed. There
> is
> > > some documentation for this at [1]. You could also use the code for
> > > TomcatServerImpl [2] as a reference, as it uses JmxFeeds.
> > >
> > > Just my 2ยข. It's not something I've done myself I'm afraid, so I don't
> > have
> > > any better example I can point you to.
> > >
> > > Geoff
> > >
> > > [1]
> > >
> https://brooklyn.apache.org/v/latest/blueprints/java/feeds.html#jmx-feed
> > > [2]
> > >
> > >
> >
> https://github.com/apache/brooklyn-library/blob/master/software/webapp/src/main/java/org/apache/brooklyn/entity/webapp/tomcat/TomcatServerImpl.java
> > >
> > >
> > > On Mon, 11 Mar 2019 at 00:21 Peter Abramowitsch <
> [email protected]
> > >
> > > wrote:
> > >
> > > > I'm interested in adding some custom sensing in my app.  Using the
> > > > VanillaJavaApp Entity,  let's say I would like my application whose
> > main
> > > > class is set in the blueprint to send back a dynamic "records
> processed
> > > > count" and have it appear in amongst the other sensors on Brooklyn's
> > web
> > > > UI.
> > > >
> > > > My Java app is not a webserver,  just a long-running process.  Is the
> > > > correct approach to create an MBean as part of my app and connect it
> > back
> > > > to Brooklyn's server?   I'm not sure how to put all the pieces
> > > together...
> > > > or if there's a better way.  Can it be done without extending
> Brooklyn
> > > > itself?
> > > >
> > > > Peter
> > > >
> > >
> >
>

Reply via email to