Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Shared Libraries & Logging

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

We're starting to build applications on Tomcat and J2EE (WebSphere) and are at a stage where we see a couple of directions to go and would appreciate some advice from more experienced hands as regarding whether we are on the right track / are missing any clever / better approaches to this aspect of our work.

The issue concerns shared libraries and logging. In our ideal world we'd like to have complete traceability of our application in terms of logging. Meaning that we can at least point to the application responsible - no matter what log activity is generated. We realise that when we start to use libraries that are shared amongst many applications we are going to run into some restrictions.

Concerning 3rd party libraries we realise our hands are pretty much tied. We can log up to the point where we make a call to the 3rd party library but from thereon we're at the mercy of whatever mechanism that library provides. Worst case we will have to stitch log files together.

We are however going to write our own shared libraries. For example to interact with databases and to check security permissions. In this case we do have the means to influence how a library behaves. So when such a library is called it should be able to provide some application context against any logs it generates, for example the application name. This is the point where we're not quite sure of the best way forward.

We have considered two scenarios so far:

1. The application tells the library about the application context

In this case either every method call has the application context on it, or some class instance within the library is given the context to remember.

2. The library discovers for itself what application is using it

We see a couple of ways of achieving this:

(a) The library picks up a properties file which contains relevant information (e.g. an application name to log against). This information would be static in nature, I.e. it wouldn't include session information like a user ID. We are assuming the library would need to be placed within the application itself as each application would have a different properties file, resulting in a copy of a library for each application.

(b) The library somehow discovers information from the application context in which it is running. We're not sure how this would be achieved (even if it is possible), nor are we sure whether this would need the library to sit within the application itself or in an area accessible to all applications for it to work. We have managed to perform JNDI lookups from java projects linked to our application, so a library is at least able to pick up something of the application context in which it is running. Application parameters can be stored in web.xml � but again we're not sure how our libraries would access these.

Any advice would be very welcome.
Thanks,
Mark.
 
Marshal
Posts: 67430
173
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"m a k", please check your private messages for an important administrative matter.
 
Bear Bibeault
Marshal
Posts: 67430
173
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How do Log4J or Jakarta Commons Logging not fit your needs?
 
M Kilby
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We're looking into a logging framework - going to look at log4j first and resort to 1.4 logging if we fail to get it going.

Where we'd like some opinions is what to do when our library code logs its activity - we'd like it to log to the same framework as the app code. I.e. the library code may be used on several applications (e.g. updating / reading objects, say).

The library could simply log under a class name - but this would make it harder to trace the activity an application generated.

Question applies equally outside the context of J2EE / WebSphere I guess - but that's what we're using for the moment.

Regards.
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ideally in such scenarios, some parameter which is common and unique for the entire flow would be available, or should be made available either by passing around or by making it commonly accessible to the entire flow.
Once this is done, the above parameter has to be logged in all logs generated by the entire flow, thus making it possible to trace a given flow.

For E.g:
A customer-id, request-id, order-number, etc can be used, which is available accross the flow.
Logging frameworks like LOG4J allows for customization of the format of the output logs. The log output can be customized to include this common attribute in a very easily identifiable and readable way.
Like for E.g: the log format can be something like this:
<date> <time> <identifier> <log message>
31-07-2998 12:21:01 12345 adsfa dfaf asdfasfasdfadsfasdf
 
The only cure for that is hours of television radiation. And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic