Hello Simon,
Simon Kitching wrote:
Would you both mind explaining what benefits you see in a new JCL
implementation that cannot be obtained via java.util.logging?
this is possible already today with x4juli, it does have a JCL native
implementation.
I'm no fan of the j.u.l design, but it
Environment: Systems supporting JRE version 1.3 and above.
Reporter: Boris Unckel
Fix For: 2.0
There were some related discussions on the dev mailing list about a possible
JCL 2.0.0.
I have created a first draft version of JCL in SLF4J (http://www.slf4j.org/)
flavour
[
https://issues.apache.org/jira/browse/LOGGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Unckel updated LOGGING-112:
-
Attachment: jcl-2.0.0.zip
The complete project including POMs and sources.
Use mvn clean
Hello,
I have seen the recent discussions on JCL 2.0.0 and a version without
autodiscovery.
Someone stated to stop any further development (with good reasons
behind) but I am
thinking different.
Please have a look at the (working) code:
https://issues.apache.org/jira/browse/LOGGING-112
It
Hello,
I have tested on Windows Vista RC1 with
a) Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.1)
Gecko/20061204 Firefox/2.0.0.1
b) Internet Explorer 7.0.5600.16384
Both with default settings for fonts and CSS.
Phil Steitz wrote:
http://people.apache.org/~dennisl/commons-lang3/
Hello,
another test with Opera 9.10 Build 8679 under Windows Vista RC1.
Default settings for fonts and CSS.
Phil Steitz wrote:
http://people.apache.org/~dennisl/commons-lang3/
puts the nav bar in the right place flush left, but shows a big black box
between the Jakarta and Lang logos on the
Hi,
Dennis Lundberg wrote:
OK, I think I've got it this time. As it turned out I had put in my
stylesheet rules in a different place than they should be, so I ended
up having contradicting rules for the same selector. The conflicts
have been solved and the rules have been moved to the
Hi,
Dennis Lundberg wrote:
Boris Unckel wrote:
http://people.apache.org/~dennisl/commons-lang5/
I have tested with:
- Firefox 2.0.0.1 on Windows Vista RC1 (my personal reference)
- looks fine
- Internet Explorer 7 on Windows Vista RC1
-- looks fine, except headings (Commons Lang
Hi,
yet another issue.
Dennis Lundberg wrote:
OK, I think I've got it this time. As it turned out I had put in my
stylesheet rules in a different place than they should be, so I ended
up having contradicting rules for the same selector. The conflicts
have been solved and the rules have been
[
http://issues.apache.org/jira/browse/LOGGING-109?page=comments#action_12435543
]
Boris Unckel commented on LOGGING-109:
--
Hi,
have a look at
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons
Hello,
I just wanted to have a look at the structure and the design of commons
configuration. Most time I just
use eclipse, create a new project and download head from svn.
This time it was hard:
13 dependent libraries to get src and tests compile clean. I know I just
could use maven
Hello Jörg,
Joerg Hohwiller wrote:
But in the end, JCL will continue to improve as will SLF4J I expect, and
people can choose as they wish - until j.u.logging knocks both libs into
the dustbin of history.
I do not think that JUL will knock out JCL or SLF4J[1]. JCL is much too
spreaded.
Hello,
Simon Kitching wrote:
If I were writing a 1.4+ library or app, I'd just use java.util.logging
directly.
Which reminds me: is the JULI implementation of the java.util.logging
API (used in tomcat) available as an independent library? If not, maybe
it is worth extracting it as a project of
Hello,
there were some questions for different components in the style is xyz
compatible with JDK 1.x in the last weeks.
I know that commons-logging did several tests and put some mentionable
work on JDK 1.2 compatibility.
This information seems important to me, there should be one distinct
Congratulations - great! After endless needed quality checks, a final
optimal release.
Hopefully many users will try and migrate to it.
Regards
Boris
--- Ursprüngliche Nachricht ---
Von: robert burrell donkin [EMAIL PROTECTED]
The Jakarta Commons team are pleased to announced that Apache
Hello Brian,
at the bottom of EACH mail of this list can you read how to unsubscribe:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Additionally this on the page where you might
Good Morning,
How Can I Use Commons-Logging In WebSphere 5.1?
I'm using WebSphere 5.1. Commons-Logging doesn't seem to recognize my
commons-logging.properties file. Help!
Set EAR classloader mode as PARENT_LAST and WAR classloader policy as
Application
This is a bad solution in my opinion:
Good Morning,
Dennis Lundberg wrote:
I haven't used java.util.logging so I might be way off here. How about
having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this
is possible, but it could be a nice path forward if, as someone else
suggested, j.u.l will be *the* logging API 5
Good Morning,
Von: robert burrell donkin [EMAIL PROTECTED]
it should work equally well with the adapters jar removed. (this is the
behaviour on WAS6.)
the testcase EAR and WAR without any commons-logging.jar should have been in
the last mail's result zip.
It is a question of the use case:
Hello,
Von: Emmanuel Bourg [EMAIL PROTECTED]
I just wanted to mention this solution if Log had to remain an
interface, but I won't support it. I prefer to turn Log into an abstract
class.
To turn Log into an abstract class means that no native implementation will
ever be possible. It would
Von: Emmanuel Bourg [EMAIL PROTECTED]
Boris Unckel wrote:
To turn Log into an abstract class means that no native implementation
will
ever be possible. It would definitly mean that you will need an wrapper
class. Currently there is just x4juli supporting native JCL support
Good evening,
I have done an additional test.
Von: Simon Kitching [EMAIL PROTECTED]
Boris, would you please replace commons-logging-1.1-RC5.jar with
commons-logging-adapters-1.1-RC5.jar in your webapp and retest?
Yes, it does work. I did not setup a system property and everything was
fine.
Hi,
robert burrell donkin wrote:
JCL 1.1 is incompatible with WAS. this appears to be an existing
standing issue http://www.javablog.com/2005/12/28/1135813600066.html. i
haven't managed to with work out why this is case (as yet).
I have read the article and the PDF. They recommend to change
Hello,
Simon Kitching wrote:
== LogFactory as factory for Log instances
Currently, JCL uses a LogFactory to create Log instances:
Log log = LogFactory.getLog(fff);
By contrast, Log4j has the factory method on the Log class:
Logger log = Logger.getLog(fff);
Having one less class is a
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-devm=113625138015434w=2).
Good Morning,
Torsten Curdt wrote:
...and frankly speaking - it will also help marketing wise. JCL1
has a bit of a bad reputation. JCL2 could help to leave this behind.
JCL 1.0x has a bit of a bad reputation: Some developers/admins
(profession) or people who have developer and/or admin jobs
Hello Robert,
robert burrell donkin wrote:
the java 2 model causes issues with J2ME, embedded applications and some
containers which be found on clients and the failure of very many
container and framework vendors to create applications that adhere to
this specification causes the majority of
Hello Karthik,
Karthik Kumar wrote:
Robert said J2ME.
J2ME has issues with classloading? :o
J2ME is not my domain, I have never written any app or API for it. I
just have read container
and I do not know if there is something over a J2ME Virtual Machine(VM)
that can be compared
to a J2SE VM
Good Morning,
Simon Kitching wrote:
At some point I think it would be a good idea to post a notice to the
tomcat dev list, as the subscribers there are likely to (a) care about
JCL, and (b) have some interesting apps to test it with.
Maybe jboss would also be good to contact, as they have had
Hello,
robert burrell donkin [EMAIL PROTECTED]
i've uploaded RC1 to http://people.apache.org/~rdonkin/commons-logging/.
please check and test the release candidate and report any mistakes or
problems.
Just to minor things:
- docs/api is empty, can be removed (docs/apidocs contains javadoc)
Good evening,
Since you are working on the JCL page:
Is there a chance to get an x4juli link on the JCL page (somewhere) to
http://www.x4juli.org as native JCL implementation
for JDK Logging Users?
Obviously it is not a Apache project but it is released under Apache
license. There should be a
Good Morning,
Simon Kitching wrote:
Thanks for your offer Boris, your offer to spend time on JCL is
appreciated. However I would personally prefer not to make these
suggested changes. The code is reasonably ok now, and this just doesn't
gain us anything that I can see.
If you would like to
Good Morning,
jar jarfile=${build.home}/${core.jar.name}
basedir=${build.home}/classes
manifest=${build.home}/conf/MANIFEST.MF
include name=org/apache/commons/logging/** /
include name=META-INF/LICENSE.txt/
include name=META-INF/NOTICE.txt/
Do you know if there's anything extra needed?
Well, it just claims, that 1.1 is still compatible to 1.0 regarding API
and spec. Cannot say, if this is really true, you're the expert here :)
Possibly a clirr report against JCL-1.0 will tell. Otherwise it looks
good. You
might add an
On Fri, 2006-01-20 at 10:40 +0100, Boris Unckel wrote:
Just as suggestion:
There are some commons-logging compile dependencies. The manifest allows
proprietary entries. It would be nice to have names and versions for
dependet jars in the jar.
There aren't actually any *mandatory
Hello,
is there interest that I spend some time to provide cleanup on the source
files? (Patch will be provided by file)
Learned from the last patch I saw doing right (but too many) things is not
usefull for the reviewer of a patch.
Cleanup means:
- Removing trailing white space
- Change method
Hello,
Simon Kitching wrote:
NB: I'm hoping to knock JCL1.1 into releasable state over the coming
weekend and hold a vote on creating the first RC.
Please check to put the patch in bug 38174 into RC. Even if you decide
against the logic in the new doLog methods, it would be nice to have
the
Hello Simon,
please change
/jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF
to correct 1.1RC for the RC distribution.
Currently it states a 1.0.5 version.
Regards
Boris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Hello Robert,
robert burrell donkin wrote:
i'm going through the patches (by hand) now.
i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere
Hello Simon,
NB: I'm hoping to knock JCL1.1 into releasable state over the coming
weekend and hold a vote on creating the first RC.
Please check to put the patch in bug 38174 into RC. Even if you decide
against the logic in the new doLog methods, it would be nice to have the
other cleanup
Hello,
I have found a few points when I started to submit a patch.
First I started with the JDK14Logger. The patch is ready, but
the whole system should rely on the same behaviour, so I started
to look at the other wrapper classes.
AvalonLogger, LogKitLogger, Jdk13LumberjackLogger, and SimpleLog
Hello,
in the JDK14Logger is the following code for logging to the underlying JDK
Logger:
log(Level.FINE, String.valueOf(message), null);
message is an java.lang.Object
(the Level differs from each mapping, irrelevant for my point)
What happens here is a null safe operation (OK):
Hi Joerg,
this is an absolutely normal behaviour. It does not depend
on the operating system, but more on system speed.
Your CPU has enough power to calculate n-thousand additions
in one milli second.
It is not predictable, since it depends on the machine in use.
I have found this in an other
Hi,
I would say that an efficient filtering is a part of the answer. For
those using Mozilla or Thunderbird I wrote a web page generating the
rules to filter the commons mails. If anyone knows how to turn this into
a Thunderbird extension that would be great. Similar instructions for
Hello,
IMHO you're better off implementing such a functionality for a
specific logger implementation and enable it in that configuration.
Thoughts?
- Jörg
Jörg, thanks for your feedback. I know that it is just a wrapper. That's
an advantage in my opinion. Because the
Hello,
I can not see all your guyz problems. I replaced Priority with Level and
removed
the isAsignableFrom section and everyting works and compiles fine. Even
the
TRACE is defined in Level and Priority so there is not even reflection
magic
required.
Am I missing something??? Maybe I should get
Hello,
Level.Trace was introduced in 1.2.12
http://logging.apache.org/log4j/docs/api/org/apache/log4j/Level.html#TRACE
You are right. Thanks!
And 1.2.12 is released. As soon as it is in the ibiblio, I will update the
version in project.xml
Only a little confusing that Log4J13Logger is
Hello
Hi there,
it seems that log4j from version 1.3 supports the loglevel Trace.
As suggested by Bugzilla #34437 this new loglevel should be used by
commons-logging. It seems that therefore the new class Log4J13Logger was
invented.
Level.Trace was introduced in 1.2.12
Branching this discussion off, as I realize my
previous post forked a thread.
Could be (although my gut instinct says otherwise).
Any BEA/Websphere/Geronimo/YourFavoriteAppServer
experts out there know of support for child-first
loading for EJBs?
WebSphere 5 has Option to
*Application
Hello Remy,
As a personal note, I find this proposal completely out of place after
years of FUDing and dissing commons-logging in general, and anything
not log4j in particular.
This is not the intention of Yoav. To quote the discussion[1] as summary.
This Get rid of the we vs them and create a
50 matches
Mail list logo
