dcsimg
Retrieving context from a shared lib
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   andrea_marini
Posted On:   Friday, October 19, 2007 05:45 AM

Hi there. The bare question: may a Tomcat sharedlib retrieve the invoking context? In my case the shared lib has no direct access to HttpServletRequest objects. The real case: I've a shared lib being used by multiple webapplications to access datasources and I'd like monitoring the datasource per webapplication usage. Moreover, I'd rather leave the actual library api unmodified, but I need determining at runtime the invoking application. I've found no direct way to retrive those informations and a few workaround/kludges proved unsuccessful too. I've tried instantiating a File in the lib, in order to elaborate the getAbsolutePath() result, but the file was "created" in   More>>

Hi there.


The bare question: may a Tomcat sharedlib retrieve the invoking context? In my case the shared lib has no direct access to HttpServletRequest objects.


The real case: I've a shared lib being used by multiple webapplications to access datasources and I'd like monitoring the datasource per webapplication usage.


Moreover, I'd rather leave the actual library api unmodified, but I need determining at runtime the invoking application.


I've found no direct way to retrive those informations and a few workaround/kludges proved unsuccessful too.
I've tried instantiating a File in the lib, in order to elaborate the getAbsolutePath() result, but the file was "created" in the $TOMCAT_HOME/bin/ , so no context information was available.

Accessing the ClassLoader was unsuccessfull too.



Any further hint will be utterly appreciated

Thanks in advance.

   <<Less

Re: Retrieving context from a shared lib

Posted By:   Christopher_Koenigsberg  
Posted On:   Saturday, October 20, 2007 07:15 PM

Maybe this is a chance to consider a "proxy" (isn't that one of the original GOF design patterns?) ...... you could inject a "proxy" that implements the same interface, does its logging on the side, and then invokes the original api.



So the client/invoking applications call your proxy class's methods, and it does some internal monitoring or whatever, before turning around and actually calling the library api's 'real' implementation classes.



And you add an explicit argument, to the method calls in the proxy's interface, to make it easy for you to track and identify the caller.


About | Sitemap | Contact