what does MyConfigurationFactory look like?
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Information Security
(269) 923-5278 // douglas_e_wegsch...@whirlpool.com
"A wrong note played hesitatingly is a wrong note. A wrong note played with
conviction is interpretation."
On Fri, Jun 10, 2016 at 3:30 A
On Mon, Mar 7, 2016 at 11:19 AM, Nicholas Duane wrote:
> I guess we could write our own application which takes stdin and writes to
> files and this could do the rolling file work. I would think something
> like that might already exist in linux.
>
> Thanks,
> Nick
>
take a look at the rotatelo
is something like jni4net an interim solution? Use log4j2 as is, just
expose the logging methods to .Net? All the guts would still be log4j2.
Yes, a little icky and clunky (and possibly not even viable), but just
throwing it out there
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
(269
> No I meant my thing might need to run on older platforms. E.g. I might
> want to run it on shell hosts or general cheap places, or interest other
> people in running it.
>
yes, if you are constrained to running on a JDK 5 platform, then finding a
suitable version of slf4j is one way to get it do
>
>
> Of course I can do that but not if my logging library requires greater.
> Right? Or should I (be able to) write against slf4j and then run on older
> systems by binding to an older version of Log4j?.
>
Write Java 5 style code, usel log4j2 2.4, compile it with Java 7, run it on
Java 7. You ca
> So you are saying that you would simply add a log4j1 to log4j2 bridge
> right. And those libraries that use the old version then automatically use
> the bridge. And everything runs agains the new version then regardless.
>
yep. they designed it to do that, and it works as advertised. I used to
b
>
>
> I must say though:
>
> "We are so happy with the quality and stability of Log4j 2, we are
> convinced it is a fantastic replacement for Log4j 1."
>
> That's clearly a lie. You wouldn't say these things if you were really
> happy and really convinced it'd be a replacement. That is make believe
which is the reason that projects aren't 'complying'?
- v2 is not better than v1
- the upgrade path and bridge jars mean the upgrading is really not
necessary.
I suspect it's the 2nd: why put a bunch of work into reworking all the
logging in my library (and forcing my users to change the
two possibilities offhand: either continue to use the 1.2 API (which can be
bridged to 2.x), or switch to logging to slf4j (which can be bridged to
about anything).
I'm sure that there are more possibilities.
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
(269) 923-5278 // douglas_e_wegsch
yes, it's a trap. You can be the great liberator and write the code
necessary to go the other way :-)
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
(269) 923-5278 // douglas_e_wegsch...@whirlpool.com
"A wrong note played hesitatingly is a wrong note. A wrong note played with
conviction is
10 matches
Mail list logo
