Greetings all.
I'm very much interested in getting client profile support going for
log4net. I'd be happy to do the work and submit a patch, but only if
it's going to receive serious attention.
Feel free to read some of the background in this issue:
https://issues.apache.org/jira/browse/LOG4NET-174
To start, I'd like to propose that a mechanism is selected for client
profile support. Here are the possibilities that I've come up with so
far.
1. Stay in one assembly, but reference any System.Web components
through reflection. This has the disadvantage of potentially being
slower and making that portion of the code more complicated.
2. Split into two assemblies, and have the log4net assembly trigger
the loading of the second assembly at runtime if certain configuration
directives are present. For example, if log4net sees asp* in the
configuration, it would load the log4net.Server.dll assembly at that
time only. This has the disadvantage that users could forget to
include the assembly since it's not a compile time dependency.
3. Split into two assemblies and have a different initialization call
in the log4net.Server assembly. This would provide direct compile
time dependencies and would make it clear what was required. However,
it would mean that there are two ways to initialize the core library
depending on the desired usage.
4. Not having investigated it, I assume there are also extension
points for integrating the asp.net portions using some sort of
run-time configuration. Assuming such a mechanism exists, the
disadvantage would be the increase in configuration complexity to use
the component.
More ideas? Preferences? To be honest, I'm in a bit of a hurry since
I'd like to propose to a similar client profile split in NHibernate
and I'd like to see it in for the upcoming 3.0 release. :) Without
the log4net changes, which NHibernate is dependent upon, it will be
more difficult to make it happen.
I appreciate any assistance in getting this important issue moving.
Regards,
Patrick Earl
