Date: Wed, 12 Sep 2012 11:57:01 +0200
Bill/all,
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:
http://jcp.org/en/jsr/results?id=527 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:
https://wiki.base22.com/display/btg/Logging+through+WebSphere+Portal+from+Java+and+JSPs
Glassfish also uses it, but with several places for properties files:
http://docs.oracle.com/cd/E18930_01/html/821-2416/abluk.html#gkkit
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:
http://www.slf4j.org/manual.html#binding
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
- Dev
- Ops
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[?]
Kind Regards,
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * 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 > > vendors > > 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 > > here. > > 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? > > No. > > 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. > > >
(image/gif attachment: 329.gif)