Question

Log4Net in the new version?

Thanks for your work.

Answer 1

This is fairly high on our todo list, but I can't tell you when we'll get to it.

- Hans (EDT)

Answer 2

This is fairly high on our todo list, but I can't tell you when we'll get to it.

- Hans (EDT)

Hi Hans,

This post was appox a year ago and log4net is still notably absent. Do you have any update on when this will be an option in edtFTPnet?

thanks

Answer 3

I'm afraid log4net support has slipped somewhat in priority, mainly since almost nobody seems to want it. I agree it would be nice, but we have an enormous todo list and not enough "doers", so I can't really see us getting to it any time soon.

However, if you, or anyone else reading this, would like to add log4net support themselves, we would be more than happy to work with them and to add their code to edtFTPnet when it is working.

All the code will go into EnterpriseDT.Util.Debug.Logger. It would be completely trivial if it were not for one important fact - the code must run if log4net is not available. Keeping this in mind, there are three main things that need to be done:

1. Add a property called something like "UseLog4netIfAvailable".
2. Use reflection to detect if log4net is available (probably in the constructor). If it is available then store references to the appropriate log4net object(s) and method(s) for use in the actual logging.
3. Change Logger.OurLog(Level,string,Exception) so that it will call the appropriate log4net method if UseLog4netIfAvailable is true and log4net was determined to be available in the constructor.

If this is not clear, or you would like any additional information, please reply to this post.

- Hans (EnterpriseDT)

Answer 4

Hi Hans,

I'm not sure what you mean by l4n being "available" - presumably you would ship it with any version of edtftppro that supports it?
As a "quick" win, how about this:
log everything to l4n and to your normal logger.
If l4n is activated then the output goes there
If your own logger is activated, then all output goes there.

Not particularly a pretty solution, but it should mean that all existing loggers will continue to log as normal, and new apps can choose to write to the l4n log OR the (now) "legacy" log.

Just a thought....

Answer 5

All of our DLLs are "stand-alone" in the sense that they work on their own and are independent of any third-party DLLs. This has saved us a lot of grief over the years, so we don't want to break this principle when implementing log4net support. So unless we actually compile the log4net source-code into our code-base, then we'll end up with an external dependency.

However compiling log4net into our code-base (which is no problem legally as it is under the Apache license) just gives us a better logger than what we have now - but will cause problems interacting with any other instances of log4net.

The best option as far as we can see is to do as Hans described above. As there is obviously some demand for it we will try to push it higher in the agenda.

Answer 6

In the clear light of day, another option springs to mind, which would hopefully be better all round.
Sure, I use l4n myself right now, but who's to say I will in the future? What if I want to write to the .NET trace output, or to some home grown logger?

How about this: You expose virtual methods - either one per logging type, or just one, which takes an additional param of the log level.
By default, these write to the standard edtftp log, whatever that may be.
But I can override them to write to capture the log events and write to log4net or any other logger I choose to implement.

Okay, this means that:
a) logging has to be configured for edtftp AND for my logger separately and
b) all your logging has to be rewritten (potentially, depends on how it is written now) to use these virtual functions.

At least this means that everyone can use the logger of their choice - not everyone will like l4n if you go for that anyway.

thoughts?

Answer 7

Along that line, how about if we add an event to Logger called something like LoggingMessage, which gets triggered every time a new message is logged (regardless of our log settings)? The event-args would have the text and the logging-level of that message. To direct logging to log4net, you would then simply handle the LoggingMessage event and in the handler you would call the appropriate log4net logging method.

- Hans (EnterpriseDT)

Answer 8

That would help yes.

I thought of that earlier but rejected it on the basis that I would then be logging twice - once in the edtftp log, once in my <whatever> log.
I see that it would be easier for you to do this though than to implement the virtual members :)

If you were to go this route then it may be worth considering:
a) a switch such as ""RaiseLogEventsOnly" or similar so that the log event is raised, when you "log" something the event is raised but YOU don't actually log it
or preferably
b) raise the log event and let it return a value to indicate if it "handled" the logging - in a similar way for example to the ObjectDataSource's OnDeleted event - the event args have an ExceptionHandled property so that if there was an exception, and your OnDeleted handler deals with it, you set this value to true and the ObjectDataSource no longer feels the need to throw the exception.

So your OnLogging event would have a LogHandled (or similar) property of the event args and if this is true then you don't bother doing your actuall internal logging.

What do you think?

Answer 9

We are thinking of passing all log events on to the event handler irrespective of our Logger's settings. So all you would need to do is set our log level to Off and we wouldn't do any logging at all.

That way there doesn't need to be any interaction, and there is no confusion about which logger's configuration applies. We won't get emails saying "my log4net configuration says it should be logging and it isn't" because of conflicting levels in our logger and log4net.

Would that accomplish what you are after?

So all that is then required is a log4net event handler.

Answer 10

That sounds pretty cool and the gang yes - the only problem I see is from a performance perspective because you will be calling my event for every potential log (ie log level of All) and I have to then test, certainly with log4net, if debug is enabled, if info is enabled, if warn is enabled etc, one per log level available in my logger of choice.
Maybe it wouldn't have much impact so is a non issue but it would seem "preferable" to only raise the event if you have to.

Put it this way: anything is better than nothing, so whatever you decide to implement is an improvement, but personally I would prefer that the event is only raised if the appropriate logging level is reached.

thanks