Hello Maciej,
first I think this should go to the users list, dev is for log4j development
itself.
Original-Nachricht
Datum: Wed, 13 Sep 2006 10:27:52 +0200
Von: Maciej Gawinecki <[EMAIL PROTECTED]>
An: log4j-dev@logging.apache.org
Betreff: static logger and instances with names
Hello Lyall,
Pearce, Lyall wrote:
I am unsure if this is more a user or developer question, I will lean
towards developer unless told otherwise.
log4j1.3-alpha8 has a nice class TimeBasedRollingPolicy
(http://logging.apache.org/log4j/docs/api-1.3/org/apache/log4j/rolling/T
imeBasedRollingPolic
Good evening,
David J. M. Karlsen wrote:
Some of the vendors are behind - WebSphere v6 (latest available) is at
JDK1.3.
I really don't see any reason to make the l4j 1.4 target - if it does
- we'll have some problems - and probably leave l4j for good.
WebSphere v5.0 was at JDK 1.3
WebSphere
Hello,
Endre Stølsvik wrote:
What is there in 1.4?! Unless you do heavy concurrent I/O, I haven't seen
anything that Java 1.4 supplies that isn't just "plain java"?
to get this all together:
There are a few dimensions for/against a special JDK Version:
1a) User base argumentation: How many peop
Good Morning,
Jacob Kjome wrote:
For those not willing or able to move past JDK1.3, it seems like
they'd also be unlikely to keep up with the latest versions of
supporting libraries such as Log4j.
+1 !!!
Since the 1.2.xx branch will always be there and still works just
fine, I
Jess Holle wrote:
I'm sure I'm in the minority here, but 1.2.13 seems fine for "legacy"
versions of Java, i.e. everything prior to Java 5.
I'd be fine with requiring Java 5 for log4j 1.3 and using the best
concurrency, etc, utilities it has to offer.
Does Java5 have this market share? For tech
Mark Womack wrote:
What base JDK version do we want to support for log4j 1.3? > JDK 1.2?
> JDK 1.3?
+1 for version >= JDK 1.3
with javac set to source 1.3 and target 1.3
Reasons:
- JDK 1.2 legacy(!) users have log4j 1.2.13, stable, extensible
- slow adoption of new JDKs is already fulfilled,
Hello,
I know crossposting is not not wanted usually, but the case legitimates.
The original thread on commons-dev discusses design of JCL2.0 for
archticture and API,
there were already some discussions about log4j 2.0 (i.E.
http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
M
Hello Elias,
>Scott Stark is trying two approaches. One is to fix the synchronization
>code used in log4j 1.2.12 in JBoss through a patch, which may break user
>appenders. The other is to create log4j-style appenders and DOM
>configuration support for the JDK logging framework. You can read mor
Good Morning,
after reading the thread I checked my mailing list account:
[EMAIL PROTECTED] :-)
Strategy and branding are very important, even bad products can be selled
with good marketing (no examples - no flames...) And one aspect of a very
good product is a good strategy, a strong name/brand.
> > JUL was probably never designed to be a front end but rather as the
> Yup.
JUL is neither open to be a front end, neither is the backend open
for other ways to use it without a wrapper.
> > Maybe we should consider an independent project acting as a facade for
> > the existing alogging APIs. C
Good Morning,
maybe this is a different approach to allow custom (propietary) logger
development for special cases and interfaces and use at the same time log4j
quality, infrastructure and concepts:
1) creating a class abstract org.apache.log4j.AbstractLogger:
-containing (protected) methods for
Hello,
I apologize for not reading the archives before I posted idea and code.
Now I know better and next time I will do a research before
posting heavily discussed[1] (and not wanted) stuff.
Second thing I learned is to open a bugzilla and refer to it.
I did not want to waste your time.
Regards
Hello,
tonight I wrote the first implementation of an Logger. To get an quick
example I used the JDK14Logger, due to its internal
I18N feature. One migtht think I am a JDK14 Logging fan, that is not right.
In my company there are two logging adaptors,
which are quite bad and older than my presence
gging takes
places
* through concerete implemetations of the ULogger interface. This
version is
* modified for I18N and Default JDK MessageFormater
*
* @author Ceki Gülcü, Boris Unckel
* @see java.text.MessageFormat
*/
public interface ULogger {
/**
* Is the logger instance enable
Hello,
the new methods to allow an object to be inserted in an message is a very
good extension to the existing methods.
I want to send a few suggestions/requirements and hope that you comment on
them:
1) There is the capability to insert 1 or 2 objects in an message.
I think to insert 1 object i
Hello,
as developer engaged in an J2EE project I am always interested in Logging
Services and a heavy user of first Log4j and later Commons Logging with
Log4j.
During inspecting the new Log4j 1.3.0alpha Release I recognized a JDK
Wrapper and a new Factory Concept (org.apache.ugli**).
The idea to
17 matches
Mail list logo
