[javaee-spec users] [jsr342-experts] Re: Logs. Should we finally do something ?
- From: Werner Keil <werner.keil@...>
- To: jsr342-experts@...
- Subject: [javaee-spec users] [jsr342-experts] Re: Logs. Should we finally do something ?
- Date: Wed, 12 Sep 2012 11:57:01 +0200
- List-id: <jsr342-experts.javaee-spec.java.net>
I partly agree, as there are a lot more Cloud and DevOps tools out there that are not written in Java. Most of them use Ruby/Rails or Python, maybe you see others here and there, but at least the Chef/Puppet or compatible fraction does not care a lot about Java, even if the app server it's used to provision might be running it.
An extremely important aspect of logging in such environment is to define where files are logged. Unfortunately without a transparent, easy to understand way on how to control that, we see on a day to day basis, that our local Cloud "partner" in India or elsewhere misses a file or option in Production, and then you have most apps (e.g. running Play! where Log4J is used and controlled rather easily) log into the right place like /mytenant/logging/ but wrongly configured servers as well as 3rd party components (depending on which Java logging framework they actually use) log to either /mytenant/domains/domain1/logs/ or /opt/oracle/logs/ as well as for the projects delivered on JBoss either
/mytenant/domains/domain1/default/log/ or /opt/jboss/jbossasversionX/server/default/log.
Similar with Tomcat, where Log4J is mostly used. Odd btw. that Apache, Doug Lea and Accenture ignored the ballot for JSR 47 back in 2001:
Considering, Accenture could be dealing with similar issues these days in many Outsourcing projects, that seems a bit strange, but maybe they were never so involved. Having Doug and Apache not vote at a time when the issues that drove them out of the EC later almost simultanously were not so imminent is of course a bit worrying.
WebSphere does seem to extent JUL type loggers, at least telling from articles and forum entries like this one:
Glassfish also uses it, but with several places for properties files:
For both EE developers and admins (DevOps) this certainly adds complication, even if you try to script or automate any of these files.
If a very small thin JSR on top of existing solutions found enough demand, it probably should be closest to SLF4J:
The main advantage is for application and platform developers having a common logging API to use. Solutions like SLF4J do not solve the underlying configuration for you, so please differentiate between
here if you wish
Putting my developer hat on I would certainly love to see a common API without having to worry that much about the underlying logging solution or configuration.
With the ops hat, a more transparent configuration would be an advantage, but if you have a binding layer in the first place, at least the components using that have a better choice if they want multiple properties files, a single XML file, maybe soon some JSON format instead of XML or a combination of all these
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
* Eclipse Day Krakow: September 13 2012, Krakow, Poland. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Eclipse STEM, UOMo and Hudson"
* Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera. Werner Keil, JCP Executive Committee, JSR-321 EG Member will present "Trusted Computing API for Java™"
* Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven and Mylyn"
* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil, JCP Executive Committee Member will present "Standards for the Future of Java Embedded", "Eclipse UOMo, STEM, and JSRs e.g. 331 or JCP.next"
* DevoXX: November 13 2012, Antwerp, Belgium. Werner Keil, JCP EC Member and Agorava Committer, will present "Java Social JSR, it's alive"
> After watching this discussion from the silent corner I might add some
> more thoughts here.
> Beside the fact that I completely second every single line Antonio has
> written, I can only stress that
> I face logging issues with every single project I see.
> On top of that comes the product integration. GlassFish completely
> relies on JUL. Adding alternatives
> forces you to tweak things. WLS offers both JUL and log4j and on-top
> it's proprietary framework.
> Only two examples show how easy it is to develop _platform neutral_
> here and how big the needed
> changes are if you are moving app-servers. If not in the code you end
> up tweaking the infrastructure.
> And on top .. let's take a look at newly scoped EE 8. What common
> cloud-focused logging use-cases do you expect to come up?
> - Different logging frameworks per application?
> - Different log-files per application? One for the app? one for the
> server? One for security incidents? One for .... whatever?
> - Logfiles per instance? per application? per stakeholder view
> (deployer, ops, developer)?
> - If we think about PaaS we should have at least a decent support for
> web-based control panels and give the needed granularity separate
> logging possibilities.
> - Applications tend to have their logfiles. Ops is using Nagios or
> syslog-ng ... should we simply define handlers for each and let
> take care of the rest based on JUL or would it be better to have a
> more isolated approach from the bottom up?
> I know that I am mixing things a bit here. Changing Java Logging isn't
> the same than adding PaaS logging features. We might try too much
> And this EG might not even be the right one to argue about different
> approaches. But someone hast to start this discussion, right?
> @Bill: May I ask about your idea about Logging with PaaS in EE 8? Do
> you have anything special in mind?
As described in my previous message, I would expect the PaaS provider
to decide how log messages are stored, where they're stored, how they're
viewed, etc. I wouldn't expect to standardize this in Java EE.
If applications want to manage their own log files with their own log
messages, without any help from the app server / PaaS provider, then
using a third party logging framework that's independent of java.util.logging
is probably the best approach.
But I'm interested in hearing requirements from Java EE application developers.