Spring Actuator Like Endpoints

[Vivek Raman]

Hello Folks,

Just wondering if we can have endpoints like Spring-Boot does for the following

1. UP : That returns status of application

2. Health : CPU Util, JVM

3. Env: Environment dump

4. logfile

5. metrics

6. shutdown

More on this at: 

http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html

[Sebastian Łaskawiec]

I like the idea. Those endpoints (especially health check) are often used by Container Orchestration engines (like Kubernetes).

[Werner Keil]

Some of the Spring-neutral ones look reasonable.
Maybe something like "beans" also would make sense related to CDI.

As for "Health", "Monitoring" etc. I guess either go with built-in apps like JConsole https://docs.oracle.com/javase/tutorial/jmx/overview/javavm.html or maybe Mission Control: http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html

Beside that, Parfait https://github.com/performancecopilot/parfait offers plenty of monitoring for the JVM, even a Spring module is available;-)
And it's compatible with Performance Co-Pilot (pcp.io) which is very widely used (e.g. Netflix even contributed nice real-time visualization Vector) I just used PCP to monitor a Jenkins cluster and it's used quite a lot, not only on Red Hat Linux.

Sounds like a good idea, and worth trying to standardize some (especially the most basic ones)

Werner

[Antonio Goncalves]

Reminds me JMX 2.0 (RIP JSR 255 https://jcp.org/en/jsr/detail?id=255). One of its goal was to add HTTP invocation on MBeans. 

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a93dcb91-99b6-4e2b-8b12-4056cffdc531%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Werner Keil]

Given its complete lack of progress (this JSR hasn't even filed a single JIRA item or anything else;-O) Java EE Management 2.0 (RIP JSR 373 https://jcp.org/en/jsr/detail?id=373) is the most likely candidate to follow it to the grave;-|

Werner

[Arjan Tijms]

Hi,

On Tuesday, July 12, 2016 at 7:19:31 PM UTC+2, Werner Keil wrote:

Given its complete lack of progress (this JSR hasn't even filed a single JIRA item or anything else;-O) Java EE Management 2.0 (RIP JSR 373 https://jcp.org/en/jsr/detail?id=373) is the most likely candidate to follow it to the grave;-|

Wouldn't it be an idea to "just" continue with JSR 373? Is anything holding that back?

Kind regards,

Arjan Tijms

[Werner Keil]

The EC or Spec Lead Oracle will decide on that. Given the significant lack of any activity compared to pretty much every other JSR (take 375 where thanks to EG members like yourself an RI and other deliverables exist;-) I could not blame either of them shutting it down. Either by withdrawal like for 351 or by failing a Renewal Ballot.

Every JSR that's subject to Renewal Ballot will be able to argument why it should continue, but without any activity (Patrick and others just mentioned checking that for the sake of transparency in the future;-) JIRA ticket, mailing list or forum post it will have a hard time doing so.

For JSR 375 regardless of whether a proposed talk was accepted by JavaOne (have not heard any feedback yet, Tamaya was accepted, seems there are some "Early Bird" approvals?) or not, if enough EG members of 375 come to JavaOne and Oracle shall make decisions and announcements then about Java EE 8, unless it decides to withdraw 375 I would be in favor of doing everything we can to publish an EDR 1 before the end of September or at least October (Renewal Ballot 2 would be due no later than the end of November if nothing else happens) 

There are no strict requirements to how big it should be, but Soteria, the underlying API and "some" Spec Document in Asciidoc sound more than sufficient. 

Oracle/Alex have to file it but we can all work on it to help him ;-)

Kind Regards,

Werner 

[Arjan Tijms]

On Wednesday, July 13, 2016 at 7:57:31 PM UTC+2, Werner Keil wrote:

The EC or Spec Lead Oracle will decide on that. Given the significant lack of any activity compared to pretty much every other JSR (take 375 where thanks to EG members like yourself an RI and other deliverables exist;-) I could not blame either of them shutting it down. Either by withdrawal like for 351 or by failing a Renewal Ballot.

What I don't understand though, if I look at the JSR (https://www.jcp.org/en/jsr/detail?id=370) then I see quite a number of names that are non-Oracle. Why don't they "just" continue, like e.g. Christian does for MVC? For MVC too Santiago is not active and neither is Manfred, but Christian doesn't wait for them and just continues.

Kind regards,

Arjan Tijms

[Werner Keil]

Well not everybody is as active as Ivar, yourself and a few others might be;-)

There are a few though mentioned even here on the site who rarely contribute. They may be in an EG or around here for "political" or PR reasons, but they either don't have time or interest to really drive things forward. Maybe JSR 373 just got too many "representational figures" instead of "makers" who try to get things done?;-O

Kind Regards,
Werner

[Werner Keil]

Did someone have a closer look at Apache Brooklyn: https://brooklyn.apache.org/learnmore/features/index.html
It looks very impressive. Hinted it to Tamaya earlier, but since then Brooklyn also left the Apache Incubator.

Werner

[Ivan St. Ivanov]

Hi everybody,

In the last few months I've been working on bringing the Spring actuator functionality (or at least part of it) to Java EE using MicroProfile technologies (CDI, JAX-RS and JSON-P). Here's the project:

https://github.com/ivannov/javaee-actuator

It consists of two subprojects: the actual actuator jar that provides the endpoints and an empty web application that showcases how you can attach and use the actuator.

The number of endpoints is way smaller than those in Spring Boot, but at least I tried to keep the syntax of the responses the same.

I've run it on TomEE. I also wanted to run the showcase app on WildFly (not Swarm though), but I couldn't find a way to expose its JMX metrics via RMI. Unfortunately I couldn't find the time to try it on Liberty Profile and Payara.

There are also Arquillian client tests, which are showing green bar on the WildFly managed container.

You can find more details about the whole thing in the README file. I will be happy to get any feedback (in terms of pull requests or issues) and also to contribute this project to the MicroProfile organization. It's licensed under Apache Version 2.0.

Cheers,

Ivan

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.

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

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7f086ad6-454a-4274-929e-037ce9093a90%40googlegroups.com.

[Werner Keil]

Hi,

Thanks, looks quite interesting in more than one way. On one hand I have a JSON-P 1.1 talk at JavaOne and plan to demonstrate real life use cases of JSON-P (1.0 or newer where applicable, 1.1 is still in EDR stage, so things may change;-) including those available here.

On the other hand I recently helped PCP Parfait (https://github.com/performancecopilot/parfait) integrate JSR 363 and for certain metrics, both Parfait/PCP and JSR 363 could be handy to offer better user experience, e.g. when you want to show certain metrics like available heap or disk space in a human readable form (like "df -h" http://www.tecmint.com/how-to-check-disk-space-in-linux/)

JSR 363 allows to convert anywhere from YOTTA to YOCTO out of the box, see http://unitsofmeasurement.github.io/.

Cheers,
Werner