Ho Etienne,

The least you have to do is to change the method signatures to pass a
GUID or some other unique key down from the web layer to subsequent
layers.
This way, you can associate different log outputs for the same request
- by logging and searching for the unique key.
Of course you will still need to do a lot of work while analysing the
logs as the lines will be spread across different log files in
different machines ( if you chose to distribute it) and you will need
to do a find/grep across files to create a complete flow.

I would love to see a good implementation for the same - If anyone
finds one.

Pranshu

If you pass some sort of object from the top of the stack to the bottom, then
each layer can use only the data from that object which it needs, and will be
unaware of (and thus decoupled from) the other data which it doesn't need.

Such an object might contain a complete description of the job -- thus
replacing all other parameters to the invocation methods at each layer.  Or it
might only contain some sort of description of the job intended primarily for
logging purposes.

BTW, it's a mistake, IMO, to think of logging as "not a real business
requirement".  Try removing the logging and see what happens to the business
;-)

   -- chris

Have you looked at log4j's NDC/MDC (Nested/Mapped Diagnostic Context)?
When each request is handled by one thread, this is probably the way to
go (it's probably implemented using ThreadLocal). The business layer can
add the user ID to the NDC/MDC and when the web service layer logs a
message, the user ID is available to be added to the message, i.e. you
can add the (entire) NDC or specific MDC elements to the conversion
pattern in your log4j configuration (%x / %X{userId} respectively).

etienno@gmail.com skrev:

(Please forgive if this is double-posted; I posted this yesterday but
it didn't show up; think I've,  "Destructively reconfigured," my poor
newsreader now ...)

I don't know of any Agreed-Upon way of doing this, but when dealing
with web-accessed systems (as you seem to be) I usually pass one object
to all major parts of the system: an encapsulation of the access
itself, as shallow an object as possible than can distinguish this
access from all others.

This is just a higher abstraction than passing a UserId everywhere, but
I think the abstraction is not at odds a web-accessed system: surely,
the system does nothing without being accessed (ignoring
timer-expirations, though these, too, could be abstracted to a system
access), and so it won't be a pollution of your layers to see some form
of access. This access could hold a log that loads the access-specific
data (sure as user ID) as header to the real logger to which it
delegates, all encapsulated away from the layers that see the access
itself.

I think this is better than an artificial mapping between
layer-specific entities and an underlying user ID (or access itself);
certainly using ThreadIds as keys sound like bring concurrency into
your session-identification scheme, which will imply impacts on session
identities when you concurrency model changes: don't do that.

As a distant, distant example (as this program is much smaller than
yours, and hence much, "Closer," to the access, so the
access-encapsulation is much fatter then you need) see the
ServletAccess class in the following link, and note that its interface
- AccessTechnology, which identifies a specific system access - is also
shared with the NormalAccess which encapsulates Swing button accesses
of the same system but started as a stand-alone, not a servlet; in
other words, the core of your system doesn't have to depend on any
particular technology used to make the access, but it does depend on
being accessed somehow.
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html