Configuring the logger

[Pieter Botha]

Good day,

I'm currently busy setting up the logs with the main idea being separate logs for separate entities (one log per channel, one log per transaction manager etc). I believe the main idea is then to create multiple loggers (00_logger.xml 01_logger.xml ...) each with a unique name?

Example of 00_logger.xml:

<logger name="myIncomingChannel" class="org.jpos.q2.qbean.LoggerAdaptor">

  <log-listener class="org.jpos.util.ProtectedLogListener" />

  <log-listener class="org.jpos.util.SimpleLogListener" />

Example of 10_channel.xml:

<server name="incoming-server" class="org.jpos.q2.iso.QServer" logger="myIncomingChannel">

   <property name="debug" value="true" />

Can anyone please confirm if this understanding is correct?

Thanks,

  Pieter

[Victor Salaman]

Hi:

You are correct, that's how you'd specify different loggers. Nonetheless, unless you really have to do it, I would not recommend this approach as you'll end up with many log files which then you'll have to correlate when searching for answers. If you have a busy system and you write your code correctly (!!!), you can consider separating the generic log from the transaction manager log and use the transaction manager log as the primary source of answers, and the generic log for ancillary information.

/V

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
 
 

[Chhil]

Question :

I have traffic from 2 incoming networks A and B and traffic going to host C. How do I set up loggers so that I have 2 log files for traffic from A to C and B to C?

I need to change the logger at runtime based on some criteria so that the mux/channel at C logs to appropriate log files.

Just experimenting with getting away from a single log file ;)

-chhil

[Alejandro Revilla]

At the channel level, you can't easily have that combination, you can have 3 loggers (for 'A', 'B' and 'C'), but you can't easily group the traffic for 'A<->C' and 'B<->C' together.

On the TransactionManager level, you can do that, if you configure two different transaction managers, (one for 'AB' communications and the other one for 'AC').

But read Victor comments, do you really need that? It's probably easier to use a log aggregator/querying tool (such as Splunk), or you could even pick the initial work done in the jPOS LuceneLogger (that one was pretty fast!) and use some tagging.

--
@apr

[chhil]

Hi Alejandro,
Thanks for the feedback.
I was just experimenting and ran into difficulty in channel level switching of log files. Since I have a TM per network it was straightforward.
Will look at the lucene one and see whats it does.
Currently dont have plans to split the loggers, just wanted to make sure I understood how it works and wasnt missing something obvious:)

-chhil

[Pieter Botha]

Thanks guys. I'm splitting the logs in order to make tracing a transaction easier. I'll sure be using Splunk as it integrates easily and with a bit of python one can make it interpret ISO elements.

Pieter

[chhil]

Hello,

I have a switch that receives requests from multiple networks and sends all these messages to possible multiple networks.

Currently using the single log file approach.

The 00_logger.xml has the logadaptor defined and uses the protected and rotate log listeners.

The problem I am running into is I need to protect/wipe various data elements based on the network (ones I receive messages or send messages to).
The logger is system wide so it protect/wipe messages seem to be system wide and not per interface.

I believe if I split the logs per interface (which I dont want to do) will allow me to configure a protected log listener per interface having its field to protect or wipe.

Any tips on how to go about doing this for a single log file?

-chhil

[chhil]

Hello,

Here is the approach I am taking.

Making changes to the framework to support packagers to define an isofield with an additional optional parameter called display which can take int params that map to wipe , protect and default to normal existing behavior.
I have made some progress where the use of 

<isofield

      id="2"

      length="19"

      name="PAN - PRIMARY ACCOUNT NUMBER"

      pad="false"

      class="org.jpos.iso.IFA_LLNUM"

      display="1"/> 

I have made some progress and the need for something like this in the logger is not required.

<log-listener class="org.jpos.util.ProtectedLogListener">

    <property name="protect" value="2 14 23 35 63 126" />

    <property name="wipe"    value="45 52 55 61" />

  </log-listener>

So the packager itself dictates which fields need to be wiped/protected and there is no one universal decision maker (needed especially when you have multiple interfacs that you receive messages from or send messages to multiple hosts.

Running into some issues (messages to host are not getting respecting the contract, response respect the display attribute, strangely the request from acquireres and response to acquirers are obeying the contract) but I think I should be able to get around it :)

If there are better options , please let me know.

-chhil

[Andrés Alcarraz]

Hello chill, this is what I would do in your case.

I would make a new LogListener extending ProtectedLogListener that protects the messages given the channel name or realm for example. Ence you can define in that LogListener a table from channel/server name to protecting settings. I guess this should be easy to implement and even the ProtectedLogListener could be modified to support this kind of configuration.

I don't know if I was sufficiently clear so I apologise  if that's not the case.

Andrés

El 25/10/12 15:13, chhil escribió:

--

[chhil]

Hi Andrés ,

Thanks for the suggestion. Yes its very clear.

This sounds doable, but I am leaning to the above as it removes any additional configuration of the listener or the protection of data in the context using ProtectDebugInfo.

-chhil 

[Alejandro Revilla]

Good idea Andres, as always!

In addition to the channel, you could use the packager associated with the ISOMsg. If the packager is Configurable, a special ProtectedLogListener implementation could pick the fields to protect and those to wipe from the m.getPackager().getConfiguration() instead of its own Configuration.

The Configurable interface doesn't give you access to the configuration object, but you can extend say GenericPackager and add a Configuration getConfiguration() method.

--
@apr

[chhil]

Hmmm 2 votes for the approach :)

I managed to get the addition of attribute to the ISOField in the xml packager. I knd of like this for the following reasons:

1.You dont need additional ProtectedLogListener to modify the log.

2. You dont need a ProtectDebugInfo to protect the same messages in the context.

The ISOMsg's dump takes care of protecting the data.

Alejandro, I will create a pull request (later), you can take a peek and see if its worth adding this. I personally like this approach:)

-chhil