Re: Modular Build
On 09/04/2010, at 1:26 PM, Curt Arnold wrote: On Apr 7, 2010, at 10:36 PM, Gary Gregory wrote: Clearly, since Chainsaw V2 is the current version, it seems odd to deliver the code for Chainsaw V1. This should be deprecated in a point release, 1.3 or 2.0, not in a 1.2.x maintenance release though. You could never say with certainty that there is some app out there that depended on same fragment of Chainsaw or LF5 code to be present. The Eclipse statement of compatibility phrases this as API Usage Assumption: Every aspect of the API matters to some Client. I agree we can't yank anything out of log4j.jar in a 1.2.x release. However, I don't think that anything would prevent us from offering an alternative lighter jar (or jars) as part of a 1.2.x release. The easiest would be to strip out Chainsaw 1 and LF5 out from the jar, maybe log4j-no-gui.jar? I think it should be the reverse, have a log4j-with-gui. Yes, there may be someone out there dependent on the older API, but I think we can be fairly confident that this is a minority, so flipping it so that the majority get the benefits. Paul - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Can't yank it from log4j.jar without potentially breaking some app that actually uses it, but could mark it as deprecated and suggest checking the jmx companion. the alternative is to start yanking things out of log4j into a 'legacy' jar. People that wish to upgrade log4j jars, need perhaps drop in this extra one for compatibility. newer versions of whatever can then go into other companion libraries. Paul
Re: [PROPOSAL] Implementing the SLF4J API directly
On 09/12/2008, at 2:27 AM, saimen54 wrote: Jacob Kjome wrote: http://logging.apache.org/log4j/companions/component/index.html http://logging.apache.org/log4j/companions/extras/index.html http://logging.apache.org/log4j/companions/receivers/index.html http://logging.apache.org/log4j/companions/zeroconf/index.html And is there any chance that component, receivers and zeroconf get jar'ed in this decade? touché! :) Once Curt is back on track and we can discuss a release plan for 1.2.16 (personally I vote for 'stop release now'), we can then move to these, but yes, your point is well made, this has been a long time in coming. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
If logger implements org.slf4j.Logger, then one can write
String name = Scott;
logger.debug(Hello Scott);
logger.debug(Hello {}, name);
Both log statements will print as Hello Scott. However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug(Hello, new Object[]{new Integer(37), aMap, aList});
First off, I've come back from some leave, and prior to that was
extremely overloaded at work, so my attention to detail on this thread
is limited.
Am I correct in distilling that the crux of the _driver_ to do this is
to support the above, and only that feature? This is 'nice' but really
not that high a priority I would have thought.. Given the vast
majority of people are on Java5+ platforms, a source and binary
compatible way is to introduce a simple 'log4j-java5plus' extension
jar that has something like this:
public class LogUtils {
..
public static void debug(Logger log, String message, Object...
args) {
if (!log.isDebugEnabled()) {
return;
}
log.debug(getFormattedMessage(message, args));
}
..
private static String getFormattedMessage(String message,
Object... args) {
String formattedMessage = message;
if (args != null args.length 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, Hello %s, your age is %d, name, age);
Now, that bypasses slf4j completely, and maintains source binary
compatibly, and can easily be migrated to. My point is not to suggest
log4j introduce the above, or to dissuade from considering slf4j
integration more generally, but if the above feature is it... it
really doesn't seem like a massive driver that breaks binary
compatibility and possibly alienate a whole bunch of people (which it
could, and that could badly tarnish the log4j 'brand' as it were).
So I'm not in favour of rushing any decision at all.
Paul
Duplicate class in log4j-extras
We have found there's a duplicate class in log4j and log4j-extras. I've upgraded our local environment to a 1.2.16 snapshot with the extras, and low and behold a Bamboo run failed a test (I got the chicken.. grrr :) ). We have a test that iterates over the jar's in the classpath looking for duplicate entries because it's a sure sign of a mismatch of jar versions and hilarity can ensure later on so it's best to spot this early. Paul-Smiths-Computer:lib paulsmith$ unzip -l log4j-1.2.16.20080912.jar | fgrep Unrecogn 286 09-10-08 11:06 org/apache/log4j/xml/ UnrecognizedElementHandler.class Paul-Smiths-Computer:lib paulsmith$ unzip -l apache-log4j- extras-1.0.20080912.jar| fgrep Unrecogn 286 06-27-08 08:24 org/apache/log4j/xml/ UnrecognizedElementHandler.class Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans to release org.apache.log4j.servlet?
On 04/09/2008, at 12:33 AM, Jukka Zitting wrote: Hi, I found a bunch of classes in org.apache.log4j.servlet under log4j-sandbox and I'd like to use them to replace our custom Log4J configuration code in Apache Jackrabbit. It does sound like a good candidate for log4j-extras which we do plan to release. I'd support a move, the code in the servlet package looks stable and reports such as yourself showing it's usefulness will add weight to the move. Are there any plans for releasing that code in near future? Is there anything I can do to help? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven test phase oddity
I went and finally revisited a patch I proposed about a million years
ago to enable testing of the JMSAppender class using ActiveMQ (Bug
38153).
See my patch below [1]. However when I run the tests locally I'm
getting a compile error:
...
prepare:
[available] DEPRECATED - available used to override an existing
property.
[available] Build file should not reuse the same property name for
different values.
build:
[javac] Compiling 2 source files to /workspace/log4j/tests/classes
/workspace/log4j/tests/src/java/org/apache/log4j/jms/
JMSAppenderTest.java:19: package javax.jms does not exist
import javax.jms.Connection;
We appear to run the tests via an antrun call within Maven, is that
right? Just curious of the rationale there, why we couldn't just make
it a standard maven test phase. Maybe there's a complication I'm not
aware of, it's just not something I've had to deal with before, so I'm
a bit confused on how to proceed. Normally for testing under Maven
I've just added dependencies under the test scope and been on my way.
help appreciated.
cheers,
Paul
[1] current patch
Property changes on: .
___
Modified: svn:ignore
- goEnv*
dist
build.properties
target
surefire*
cobertura.ser
.classpath
.project
.settings
log4j.i*
+ goEnv*
dist
build.properties
target
surefire*
cobertura.ser
.classpath
.project
.settings
log4j.i*
activemq-data
Index: tests/src/java/org/apache/log4j/jms/JMSAppenderTest.java
===
--- tests/src/java/org/apache/log4j/jms/JMSAppenderTest.java (revision
0)
+++ tests/src/java/org/apache/log4j/jms/JMSAppenderTest.java (revision
0)
@@ -0,0 +1,100 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed
with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License,
Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.log4j.jms;
+
+import javax.jms.Connection;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.Session;
+import javax.jms.Topic;
+
+import junit.framework.TestCase;
+
+import org.apache.activemq.ActiveMQConnectionFactory;
+import org.apache.activemq.jndi.ActiveMQInitialContextFactory;
+import org.apache.log4j.Level;
+import org.apache.log4j.Logger;
+import org.apache.log4j.net.JMSAppender;
+
+public class JMSAppenderTest extends TestCase {
+
+public void testJMSAppender() {
+ActiveMQConnectionFactory factory = new
ActiveMQConnectionFactory(vm://localhost);
+Connection conn = null;
+try {
+conn = factory.createConnection();
+conn.start();
+
+
Logger.getLogger(org.apache.activemq).setLevel(Level.OFF);
+JMSAppender appender = new JMSAppender();
+
appender
.setInitialContextFactoryName
(ActiveMQInitialContextFactory.class.getName());
+appender.setProviderURL(vm://localhost);
+
appender.setTopicConnectionFactoryBindingName(TopicConnectionFactory);
+appender.setTopicBindingName(dynamicTopics/
jmsappendertest);
+appender.activateOptions();
+
+Logger.getRootLogger().addAppender(appender);
+
+Session session = conn.createSession(false,
Session.AUTO_ACKNOWLEDGE);
+Topic topic = session.createTopic(jmsappendertest);
+MessageConsumer consumer = session.createConsumer(topic);
+TopicConsumer topicConsumer = new TopicConsumer(consumer);
+Thread thread = new Thread(topicConsumer);
+
+
+thread.start();
+
+Logger.getRootLogger().info(Hello World);
+
+thread.join();
+assertTrue(Should have received a message,
topicConsumer.receivedMessage);
+} catch (Exception e) {
+e.printStackTrace();
+fail(Error during test);
+} finally {
+if (conn != null) {
+try {
+conn.stop();
+conn.close();
+} catch (Exception e) {
+e.printStackTrace();
+fail(Error on close/stop);
+}
+}
+}
+
+}
+
+private static class TopicConsumer implements Runnable {
+private boolean
Re: log4j 1.2.16 release plan
On 13/08/2008, at 19:27, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Curt Arnold skrev den 13-08-2008 07:16: I've thinking it is likely that we may run into problems with the geronimo artifacts on earlier JVM's. May have to hack the pom.xml and rebuild to get compatible bytecode. The geronimo artifacts are only used for building, not running. Shouldn't that be ok? Yeah I don't know why linking against the geronimo jars would make any difference? I'll have a look at your issues. -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.2.16 release plan
On 13/08/2008, at 3:16 PM, Curt Arnold wrote: I'd like to address the following bugs and then get an RC1 for log4j 1.2.16 out For consideration: https://issues.apache.org/bugzilla/show_bug.cgi?id=43282 (OSGI packaging info - seems trivial.. ?) https://issues.apache.org/bugzilla/show_bug.cgi?id=40246 (deregister for HierarchyMBean - just need to validate the patch) I'm pretty stuck on the SocketHubReceiver keeps adding duplicates bug, so I might pause that and revisist 40246 to confirm the deregister works, I think I'll just build a test harness class locally to verify. Paul
Re: log4j 1.2.16 release plan
The recent release build environment is a JDK 1.4 javac targeting JDK 1.1 bytecode. If the Geronimo jars contain JDK 1.5 bytecode, they won't work with JDK 1.4 compilers. Not sure, but I suspect that might be the case. Compilers in later JDKs don't support generating JDK 1.1 bytecode. Ah yes, that might be the case. I thought you meant if you actually got to generate the log4j artifact jar, it would not be compatible out in the wild, but you're saying it may be difficult to even compile against it with the 1.1 restrictions. At some point we have to let 1.1 go, it's more that 7 years old. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r682879 - in /logging/log4j/trunk: build.properties.sample build.xml pom.xml src/changes/changes.xml src/main/java/org/apache/log4j/jmx/Agent.java
I really really really dislike this change.
Errors are not designed for use by programs but by the jvm itself.
I prefer if this change was reverted and the use of a wrapping
runtimeexception instead.
On 06/08/2008, at 5:16, [EMAIL PROTECTED] wrote:
Author: carnold
Date: Tue Aug 5 12:16:07 2008
New Revision: 682879
URL: http://svn.apache.org/viewvc?rev=682879view=rev
Log:
Bug 45485: Agent.java is sole dependency on jmxtools.jar with Java 5+
Modified:
logging/log4j/trunk/build.properties.sample
logging/log4j/trunk/build.xml
logging/log4j/trunk/pom.xml
logging/log4j/trunk/src/changes/changes.xml
logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/Agent.java
Modified: logging/log4j/trunk/build.properties.sample
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/build.properties.sample?rev=682879r1=682878r2=682879view=diff
===
===
===
=
--- logging/log4j/trunk/build.properties.sample (original)
+++ logging/log4j/trunk/build.properties.sample Tue Aug 5 12:16:07
2008
@@ -49,7 +49,6 @@
# Required to build the org.apache.log4j.jmx package.
jmx.home.dir=${lib.home.dir}/jmx-1_2_1-bin
jmx.jar=${jmx.home.dir}/lib/jmxri.jar
-jmx-extra.jar=${jmx.home.dir}/lib/jmxtools.jar
jndi.jar=${lib.home.dir}/jndi-1_2_1/lib/jndi.jar
# Required to run Checkstyle. Available from http://checkstyle.sf.net
Modified: logging/log4j/trunk/build.xml
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/build.xml?rev=682879r1=682878r2=682879view=diff
===
===
===
=
--- logging/log4j/trunk/build.xml (original)
+++ logging/log4j/trunk/build.xml Tue Aug 5 12:16:07 2008
@@ -32,7 +32,6 @@
property name=javamail.jar location=${m2_repo}/javax/mail/mail/
1.4/mail-1.4.jar/
property name=jms.jar location=${m2_repo}/javax/jms/jms/1.1/
jms-1.1.jar/
property name=jmx.jar location=${m2_repo}/com/sun/jmx/jmxri/
1.2.1/jmxri-1.2.1.jar/
- property name=jmx-extra.jar location=${m2_repo}/com/sun/jdmk/
jmxtools/1.2.1/jmxtools-1.2.1.jar/
!-- Read the system environment variables and stores them in
properties, --
@@ -120,7 +119,6 @@
pathelement location=${jaxp.jaxp.jar}/
pathelement location=${jms.jar}/
pathelement location=${jmx.jar}/
-pathelement location=${jmx-extra.jar}/
pathelement location=${jndi.jar}/
pathelement location=${javaee-api.jar}/
/path
@@ -169,7 +167,6 @@
available
classname=com.sun.jdmk.comm.HtmlAdaptorServer
classpath
pathelement location=${jmx.jar}/
-pathelement location=${jmx-extra.jar}/
pathelement location=${javaee-api.jar}/
/classpath
/available
Modified: logging/log4j/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/pom.xml?rev=682879r1=682878r2=682879view=diff
===
===
===
=
--- logging/log4j/trunk/pom.xml (original)
+++ logging/log4j/trunk/pom.xml Tue Aug 5 12:16:07 2008
@@ -407,12 +407,6 @@
optionaltrue/optional
/dependency
dependency
- groupIdcom.sun.jdmk/groupId
- artifactIdjmxtools/artifactId
- version1.2.1/version
- optionaltrue/optional
-/dependency
-dependency
groupIdcom.sun.jmx/groupId
artifactIdjmxri/artifactId
version1.2.1/version
Modified: logging/log4j/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/src/changes/changes.xml?rev=682879r1=682878r2=682879view=diff
===
===
===
=
--- logging/log4j/trunk/src/changes/changes.xml (original)
+++ logging/log4j/trunk/src/changes/changes.xml Tue Aug 5 12:16:07
2008
@@ -37,8 +37,10 @@
action action=fix issue=43304Make javamail, jmx, jms
dependencies optional in pom.xml./action
action action=add issue=43874SocketHubAppender should
expose actual port in use to extending classes./action
action action=add issue=44551SocketHubAppender in the
1.2.16 does not support a scroll back buffer or application
property/action
- action action=add issue=41156Give log4j threads
reasonable names/action
+ action action=add issue=41156Give log4j threads
reasonable names./action
action action=fix issue=44888LocationInfo can report
wrong caller when other class names contain logger class name as
substring./action
+ action action=fix issue=45426ErrorHandlerTestCase is
not run and does not pass./action
+ action action=fix issue=45485Agent.java is sole
dependency on jmxtools.jar with Java 5+./action
/release
release version=1.2.15 date=2007-08-24
description=SyslogAppender enhancements, NTEventLogAppender and
Maven build.
Modified: logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/
Agent.java
URL:
sort-of-back-in-action
laptop being repaired, but have dusted off my old trusty PowerBook G4 which still magically works like a charm after 4 years, so I have mail and web, and can use Eclipse although it's vastly slower than the intel-based macs under Eclipse (I'd compare the G4 to the MacBook Pro as a Toyota Prius as to an Porsche 911) I have an absolute ocean of unread mail. I can simply not see working my way through all the bugzilla items in the short term, if there was any that one thought I should comment on I'd appreciate a personal prod, otherwise I'll try to work through the '1.2.16' blocking/proposed list to add my comments (I think generally the # blocking issues seems a lot higher than I would have thought we'd be aiming for for 1.2.16, but I haven't reviewed them all yet). On a related note, I notice that there is movement to use JIRA for log4j2 (yay!). I know it's a personal view of many to keep things 'free', but honestly I find fighting with Bugzilla an absolute PITA, and I'd really just like to focus on what we do best; coding, so I'll bring up the usual chestnut for discussion of migrating log4j 1.2 - JIRA and dust off my asbestos suit once again. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sort-of-back-in-action
I've been on vacation for a week and the backlog of changes to Bugzilla is daunting. There already was a bug for the log4j 1.2.16 release (bug 43313) and somehow it and the newly introduced one (Bug 45527) need to be reconciled. I haven't reviewed the new bug and my opinion of blocking bugs and Thorbjørn Ravn Andersen's may differ greatly.-- I'm guessing Thorbjørn is just setting up a 'starting point' for consideration and we'll cull/add as needed, but I guess Thorbjørn probably should tell us what he's thinking ? *nudge* :) cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plain log4j trunk - mvn install fails
I have had no problems mvn installing log4j (I've needed to do so a lot because Pinpoint and some other log4j-* projects link against the current SNAPSHOT). mvn dependency:tree will show you all the dependencies and transitive dependencies. Paul On 04/08/2008, at 7:00 AM, Thorbjørn Ravn Andersen wrote: Hi. I am trying to figure out how to build the various subprojects of log4j, and just want to know if it is just my configuration or if Oro is required to run mvn install in log4j trunk? (I also disabled the NTEventAppenderTest in test/build.xml as this is under XP). Is log4j being built by Gump? -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Laptop dead
My MBP has died and I'm left with my iPhone until it's repaired. No dev for me for a few days at least! Doh! Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Receivers artifacts and Chainsaw
One of the last tasks to complete before a potential 'release' to the Webstart version of Chainsaw is building a custom Receiver artifact output that does not include the JMSReceiver DBReceiver, both of which require dependent jars that we obviously can't ship (because we don't know what provider they'll need). I plan to add a new output artifact in log4j-receivers that contains this, and have it with a classifier of 'chainsaw-receivers', and have it attached via buildhelper plugin so that it is pushed out as an artifact. A similar approach would be to produce an artifact just containing JMS+DB receivers. There would still be a 'non-classified' binary containing all Receivers as standard. That way Chainsaw can mark a dependency on it's relevant classifier. This would mean that both the Webstart and standalone versions of Chainsaw would require an end-user who wished to use JMSReceiver or DBReceiver could download the 'extras' pack of Receivers, and drop it into the plugins folder together with their provider jars. thoughts? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Receivers artifacts and Chainsaw
On 04/07/2008, at 8:54 AM, Scott Deboy wrote: +1 Not sure about the name chainsaw-receivers (they can be used outside Chainsaw). I'm all ears on suggestions! :) I think it blows too, but my brain is tired this morning. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Receivers artifacts and Chainsaw
On 04/07/2008, at 9:59 AM, Thorbjørn Ravn Andersen wrote: Paul Smith skrev den 04-07-2008 00:46: One of the last tasks to complete before a potential 'release' to the Webstart version of Chainsaw is building a custom Receiver artifact output that does not include the JMSReceiver DBReceiver, both of which require dependent jars that we obviously can't ship (because we don't know what provider they'll need). I plan to add a new output artifact in log4j-receivers that contains this, and have it with a classifier of 'chainsaw- receivers', and have it attached via buildhelper plugin so that it is pushed out as an artifact. A similar approach would be to produce an artifact just containing JMS+DB receivers. There would still be a 'non-classified' binary containing all Receivers as standard. That way Chainsaw can mark a dependency on it's relevant classifier. This would mean that both the Webstart and standalone versions of Chainsaw would require an end-user who wished to use JMSReceiver or DBReceiver could download the 'extras' pack of Receivers, and drop it into the plugins folder together with their provider jars. I think that there should be a core log4j which should cover those classes described in the printed manual, and that all the other stuff which has come up since then should go in one or more extras packages which may have a different release cycle than the core. But there is.. log4j-receivers is a separate maven module with an independent release cycle. There's also log4j-extras. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date build instructions for Apache chainsaw?
On 29/06/2008, at 9:55 PM, Oliver Frietsch wrote: junit.framework.AssertionFailedError: Exception in constructor: testMRUFileList (java.lang.Error: Unresolved compilation problem: Ok, I don't get this, it's saying it's a compile error. Can you please run this inside the Chainsaw project: mvn -Dmaven.test.skip=true clean compile and attach the full build output from the console? cheers, Paul
Re: Up-to-date build instructions for Apache chainsaw?
P.S.: The chainsaw shell script is not executable by default on Linux. I have no knowledge of maven scripts so far, but it might be just a small change to include this? The appassembler plugin for Maven does not provide that feature, which I believe is due to the fact that Java itself cannot set that flag, because not all O/S support the concept of executable. Only a very recent version of Java actually exposes an API to tell if something is executable or not, yet still there's no way to set it I believe. Details (the lacking of options) are here: Appassembler Paul
Re: Up-to-date build instructions for Apache chainsaw?
The junit error disappeared, yet two tests fail. Output attached in ZIP file... Maven stores the detailed failures in a target subfolder. In the output, it mentions: C:\Dokumente und Einstellungen\ThinkpadBenutzer\Eigene Dateien\Log4J Workspace\log4j-chainsaw-maven\target\surefire-reports containing the reports. Could you please look for the failing test class file report in this directory: Running org.apache.log4j.chainsaw.prefs.MRUFileListTest Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.08 sec FAILURE! Running org.apache.log4j.chainsaw.receivers.ReceiversHelperTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.01 sec FAILURE! Running org.apache.log4j.chainsaw.LogPanelPreferenceModelTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.01 sec FAILURE! (these ones) The files will show much more detail about what is failing. Afterwards, I ran Chainsaw with the .bat file, as stated in the build instructions. If you run with '-Dmaven.test.skip=true' it should not bother running these tests. Are you doing this? mvn -Dmaven.test.skip=true package For Chainsaw, and then you should be able to launch Chainsaw from: target/appassembler/bin/chainsaw (.bat if you're windows) That's an interesting point. Would it currently be possible to add a new Receiver to Chainsaw without recompiling it, using the binary on the web site? That would be enough for me. Not at this time, but it would not be difficult to modify Chainsaw to do this. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date build instructions for Apache chainsaw?
Anyway, I'm still not successful. The extras companion does not want to compile either. I attached the output. Is it possible that the junit package is missing?! I can't really believe that, as I guess that it is used by the other packages' tests, too. This is bizarre. On the command line, 'mvn clean package' works a treat. Inside Eclipse, I get magically the same error you have. I've just committed an import change to the affected class that fixes the issue for me in Eclipse, but doesn't really explain why it's working on the command line (I'm using the Maven Eclipse plugin, so it should be the same..). At any rate, the Assert import that was being used previously is odd. Try with an 'svn update;mvn install' on the extras and see if it works now. After this error, I was adventurous enough to try to build Chainsaw even without it. Surprisingly, it seems to compile, but afterwards, the tests - testKnownReceivers(org.apache.log4j.chainsaw.receivers. ReceiversHelperTest) and - testLogPanelPreferenceModelSerialization(org.apache.log4j.chainsaw. LogPanelPreferenceModelTest) fail. Umm, how exactly did you build/test this? Can you attach the full 'mvn package' output for the Chainsaw project ? As I'd like to add new receivers, the first error seems to render the system totally useless for me... Any ideas? So, you'd like to be able to add a new Receiver class via the Plugins? Or are you thinking of contributing a more general Receiver that could be used by others? At the moment, Chainsaw has it's own hard-coded registry of 'potential' Receivers that are known, and checks which ones can be loaded. Ideally we would replace that with the standard JAR service provider stuff so any custom Receivers could be placed in the Plugin directory and be dynamically discovered (sounding a lot like OSGI isn't it. Really starting to think about Chainsaw 3 now.) cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date build instructions for Apache chainsaw?
On 25/06/2008, at 7:30 PM, Oliver Frietsch wrote: Nothing changed. Total runtime is above one hour. Paul, thanks for this hint. I believed that the trunk actually contained the log4j 2.0 code (where is that?). I got log4j to compile. However, I had to grab the NTEventLogAppender.dll from the prebuilt log4j-1.2.15 to my Windows system directory to pass all unit tests. Can this hack be further improved? Ooh, that's something I haven't seen. Because I'm using a Mac I don't think it tries that. More on unit tests shortly. Now, while trying to build zeroconf, I'm already waiting several minutes to complete the Running org.apache.log4j.net.ZeroConfSocketHubAppenderTest step - it seems to do plain nothing, but the build process is waiting for it. I'll give it another hour, but I'm not very hopeful... CPU usage is low, and there is no network traffic either... I have seen this happen on some computers, and appears to relate to the local network. The test is sending out ZeroConf packets on the network and testing that the jmDNS properly gets notifications. I should probably add a default wait time to that test and give up after a reasonable amount of time. You can skip the running of unit tests for both log4j, and log4j- zeroconf by using: mvn -Dmaven.test.skip=true package Obviously it would be nice to have all the unit tests running locally, but I can say that for log4j-zeronconf they pass locally. When things are working ok locally that test takes about a second to complete. BTW, log4j 2.0 is only in experimental design phase, it has it's own branch at the moment. Once the design gains traction it'll more than likely move to trunk, with trunk-1.2 branch (again.. :) ). cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607389#action_12607389 ] Paul Smith commented on LOG4J2-9: - Just to clear up what I actually meant, I wasn't actually advocating the _use_ of Spring within log4j, but given how useful and popular Spring is, we should at least factor into the design something that is IoC friendly. for example, perhaps so 'spring-extras' companion that obey the Spring Lifecycle interface to startup/shutdown. The more difficult objective though for a logging framework is to then _support_ the container in it's startup routine by allowing useful logging. Bit of a chicken/egg problem there unless the log4j configuration can be done as early as possible. Anyway, I was just voicing that we should probably have a Spring-like container in mind during the configuration design. May even be worth reaching out into the, say, Spring community for further discussion (or bringing them into this one) log4j 2.0 should leverage existing (preferably ASF) configuration frameworks Key: LOG4J2-9 URL: https://issues.apache.org/jira/browse/LOG4J2-9 Project: Log4j 2 Issue Type: Wish Components: Configurators Reporter: Curt Arnold log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date build instructions for Apache chainsaw?
On 22/06/2008, at 7:44 PM, Oliver Frietsch wrote: Hello list, As there might be differences between 1.2.15 and 1.2.16, I then checked out the latest 1.2.15 tag from SVN that I could find (/ v1_2_15, there is no 1.2.16!), and tried to build that. This is the result: There is ono 1.2.16 tag as you mention, because 1.2.16 is not released, it is in fact held in trunk as a snapshot. So, the missing steps are: * get log4j trunk * mvn install (this will install log4j 1.2.16-SNAPSHOT locally) I believe that will resolve the zeroconf build problem and let you continue. I'll update the build info for Chainsaw, it's slipped out of sync. thanks for the pickup. The main reason for the lack of releases is to conform to a policy of only releasing voted on releases, and the fact that Chainsaw depends on -SNAPSHOT versions of some log4j sub modules of which we're (slowly) getting closer to release quality. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOG4J2-16) Provide support for SLF4J type Markers
[ https://issues.apache.org/jira/browse/LOG4J2-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607127#action_12607127 ] Paul Smith commented on LOG4J2-16: -- This concept should also include leverage of both dynamic markers (during configuration, or even runtime), and static compile-time markers (say, via Annotations). Provide support for SLF4J type Markers -- Key: LOG4J2-16 URL: https://issues.apache.org/jira/browse/LOG4J2-16 Project: Log4j 2 Issue Type: New Feature Components: Core Reporter: Ralph Goers We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. One feature was more granularity, especially around logging. We encourage entry and exit tracing, logging of input and output data, logging of elapsed time statistics and several other flavors if debug information. Turning all this on in production generates too much data. Our framework supported the concept of Log Type in addition to Log Level. When filtering there was a LogType array where each array element was the log level. The LogRecord contained the LogType and LogLevel so doing filtering was very fast. SLF4J supports Markers. These can essentially be used for the same purpose (assuming another Jira issue regarding filtering is implemented). Markers are much more flexible since they can be arbitrarily created. Loggers should then be able to filter on whether a marker is present in addition to the LogLevel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOG4J2-16) Provide support for SLF4J type Markers
[ https://issues.apache.org/jira/browse/LOG4J2-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607141#action_12607141 ] Paul Smith commented on LOG4J2-16: -- I like the terminology 'context' and how you mention it relates to things like MDC, and Thread etc. Provide support for SLF4J type Markers -- Key: LOG4J2-16 URL: https://issues.apache.org/jira/browse/LOG4J2-16 Project: Log4j 2 Issue Type: New Feature Components: Core Reporter: Ralph Goers We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. One feature was more granularity, especially around logging. We encourage entry and exit tracing, logging of input and output data, logging of elapsed time statistics and several other flavors if debug information. Turning all this on in production generates too much data. Our framework supported the concept of Log Type in addition to Log Level. When filtering there was a LogType array where each array element was the log level. The LogRecord contained the LogType and LogLevel so doing filtering was very fast. SLF4J supports Markers. These can essentially be used for the same purpose (assuming another Jira issue regarding filtering is implemented). Markers are much more flexible since they can be arbitrarily created. Loggers should then be able to filter on whether a marker is present in addition to the LogLevel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chainsaw webstart link no longer launching
Hi friendly and stretched infrastructure people's. Has the main Apache server that servers the logging.apache.org site (and all the others) been upgrade recently? We appear to have lost a mime type association with .jnlp that help launch Chainsaw. Could someone check the mime type settings to ensure that: application/x-java-jnlp-file appears? cheers, Paul Smith On 24/05/2008, at 5:41 AM, Scott Deboy wrote: The Chainsaw Web Start link no longer launches Chainsaw, it just displays the jnlp contents. http://logging.apache.org/log4j/docs/webstart/chainsaw/chainsawWebStart.jnlp I don’t think there’s anything we can do on our site, correct? Bring this up with infra? Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system. smime.p7s Description: S/MIME cryptographic signature
maven pom optional dependencies
Relating to: https://issues.apache.org/bugzilla/show_bug.cgi?id=43304 We have already marked the dependencies as optional, and I have confirmed with the maven-user list this is what we should do. there is a remaining suggested patch that improves white space layout and adds specific version #'s to plugins to ensure reproducible builds. I've applied this locally and reviewed it and it looks good. Certainly makes the pom easier to read, and will make subsequent diff's easier to grok. I'm planning on committing that unless there are objections. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
log4j-receivers and public build area
oddly: http://people.apache.org/builds/logging/repo/log4j/apache-log4j-receivers/ has a 1.0 and a did have a 1.0-snapshot area. I removed the snapshot area because I thought it was confusing things but then I realised that there is no actual 1.0 release just yet. I'm planning on nuking that 1.0 folder and then deploying a new 1.0- snapshot so that I can get Pinpoint to play a bit nicer. cheers, Paul smime.p7s Description: S/MIME cryptographic signature
Been offline for a while
Just returned to work after the birth of our first child (boy, William, everyone's healthy). Since just before Xmas I've moved house, had a decent car accident and had a baby, so I've been quite distracted. Apologies for disappearing! cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming log4j threads
On 12/12/2007, at 5:27 PM, Jacob Kjome wrote: Paul Smith wrote: cool, bug found. Now, any consensus on naming patterns? I'd plan to prefix all thread names with 'log4j-' and use a sensible suffice depending on the usage (make it aligned with the class name that launched it if that made logical sense). Unless there's no objections I'll try that approach... ? I'm sorry, but, unfortunately, I have no objections. I guess you'll have to come up with a different approach. Heh :-) hehee. that wasn't phrased well was it? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming log4j threads
cool, bug found. Now, any consensus on naming patterns? I'd plan to
prefix all thread names with 'log4j-' and use a sensible suffice
depending on the usage (make it aligned with the class name that
launched it if that made logical sense).
Unless there's no objections I'll try that approach... ?
Paul
On 12/12/2007, at 4:11 PM, Jacob Kjome wrote:
See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41156
Jake
Paul Smith wrote:
I'm certain there's a bugzilla ticket for this, but even if there
wasn't there should be, but we are the middle of cleaning up thread
names in our app to easily identify their uses, and ran into the
FileWatchdog.
Obviously a consistent pattern of thread names would be good across
log4j threads. Here's a straw-man for consideration:
protected
FileWatchdog(String filename) {
super(log4j-FileWatchdog);
Thoughts?
Paul I've been in a black hole for several weeks Smith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED] www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail in
error, please let us know by reply e-mail and delete or destroy this
mail and all copies. If you are not the intended recipient of this
message you must not disseminate, copy or take any action in reliance
on it. The sender takes no responsibility for the effect of this
message upon the recipient's computer system.
Naming log4j threads
I'm certain there's a bugzilla ticket for this, but even if there
wasn't there should be, but we are the middle of cleaning up thread
names in our app to easily identify their uses, and ran into the
FileWatchdog.
Obviously a consistent pattern of thread names would be good across
log4j threads. Here's a straw-man for consideration:
protected
FileWatchdog(String filename) {
super(log4j-FileWatchdog);
Thoughts?
Paul I've been in a black hole for several weeks Smith
Re: [PROPOSAL] SocketHubAppender change - allow auto port choice
On 07/11/2007, at 7:15 PM, Curt Arnold wrote:
On Nov 7, 2007, at 1:55 AM, Curt Arnold wrote:
Okay, I'm about ready to fall over, but I looked at zeroconf and
see your motivation for moving the binding onto the main thread so
you continue the set up in
ZeroConfSocketHubAppender.activateOptions. However instead of
changing the behavior, I'd be more inclined to make a few changes
to SocketHubAppender to make it more amenable to extension but keep
the old behavior. I'd suggest:
Moving ServerMonitor out to a separate public class.
Move the self-start in ServerMonitor to
SocketHubAppender.startServer.
Make SocketHubAppender.startServer protected and overload it in
ZeroConf.
Add a protected SocketHubAppender.stopServer and move the
ServerMonitor.stopMonitor code there.
I'd suggest that you not take code suggestions from me too seriously
this late at night. There is probably a cleaner way to be able to
provide a hook for the zeroconf registration code to run. Maybe
adding like adding
protected void socketBound(ServerSocket s) {
}
Ok, i'm a bit tired, so I ended up just going simple and pretty much
following Curt's idea, see below. Thoughts?
Index: src/main/java/org/apache/log4j/net/SocketHubAppender.java
===
--- src/main/java/org/apache/log4j/net/SocketHubAppender.java
(revision 592202)
+++ src/main/java/org/apache/log4j/net/SocketHubAppender.java (working
copy)
@@ -17,18 +17,18 @@
package org.apache.log4j.net;
-import java.util.Vector;
-import java.net.Socket;
-import java.net.ServerSocket;
-import java.net.SocketException;
-import java.io.ObjectOutputStream;
import java.io.IOException;
import java.io.InterruptedIOException;
+import java.io.ObjectOutputStream;
import java.net.InetAddress;
+import java.net.ServerSocket;
+import java.net.Socket;
+import java.net.SocketException;
+import java.util.Vector;
+import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.helpers.LogLog;
import org.apache.log4j.spi.LoggingEvent;
-import org.apache.log4j.AppenderSkeleton;
/**
Sends [EMAIL PROTECTED] LoggingEvent} objects to a set of remote log servers,
@@ -271,6 +271,19 @@
}
/**
+ * Once the [EMAIL PROTECTED] ServerSocket} is created and bound, this method
is called to notify the class the details
+ * of the address and port chosen. In the standard
SocketHubAppender case this will be the
+ * requested port, but if the port is specified as 0, then a random
port is chosen by the underlying OS.
+ * Child classes may be interested in the actual port chosen, and
this method may be overridden
+ * and used to gain the details of the actual socket being listened
on.
+ * @param address
+ * @param actualPortUsed
+ */
+ protected void socketBound(InetAddress address, int actualPortUsed) {
+
+ }
+
+ /**
This class is used internally to monitor a ServerSocket
and register new connections in a vector passed in the
constructor. */
@@ -280,6 +293,7 @@
private Vector oosList;
private boolean keepRunning;
private Thread monitorThread;
+private ServerSocket serverSocket;
/**
Create a thread and start the monitor. */
@@ -288,9 +302,15 @@
port = _port;
oosList = _oosList;
keepRunning = true;
+ try {
+serverSocket = new ServerSocket(port);
+ } catch (IOException e) {
+throw new RuntimeException(Failed to create a ServerSocket,
e);
+ }
monitorThread = new Thread(this);
monitorThread.setDaemon(true);
monitorThread.start();
+ socketBound(serverSocket.getInetAddress(),
serverSocket.getLocalPort());
}
/**
@@ -320,9 +340,8 @@
they connect to the socket. */
public
void run() {
- ServerSocket serverSocket = null;
+
try {
-serverSocket = new ServerSocket(port);
serverSocket.setSoTimeout(1000);
}
catch (Exception e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] SocketHubAppender change - allow auto port choice
That chunk seems just like the IDE at work moving things around.
Honestly, is that really that much of a deal? I agree a total
reformat of the class is not a good idea, but I don't see the need to
get too anal about something like that..
But I didn't see much benefit from hiding the rest of the
serverSocket from the extending class, so I first simplified the
code to:
@@ -323,6 +336,7 @@
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(port);
+socketBound(serverSocket);
serverSocket.setSoTimeout(1000);
}
catch (Exception e) {
which lets the extending class extract as much or little info out of
the class as possible. But once I did that, it seemed even more
simple to use a protected method to create the socket which is
easier to explain and lets the extending class do everything the
other approaches do and more.
Looking at the ServerSocket I didn't really see anything much of use
part from the address and port, but I guess it's just as easy to pass
the whole thing.
Thanks Curt for committing a change.
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] SocketHubAppender change - allow auto port choice
actually I've found a problem with the commit.
If ZeroconfSocketHubAppender class calls super.activateOptions() which
then creates the SocketServer, the actual creation of the ServerSocket
is done by another thread (see the SocketMonitor constructor), which
means the call back to the protected method to create the socket is
done via another thread.
This means that after super.activateOptions() call returns,
ZeroconfSocketHubAppender still doesn't know what the port is going to
be used (it's a timing thing).
I think the call to create the ServerSocket needs to be done in the
SocketMonitor constructor before the thread is started as I had
originally in my previous patch. Otherwise subclasses have to
implement a tricky wait mechanism to see what port is used before
fully activating themselves.
Can we please move that into the constructor?
Paul
On 16/11/2007, at 5:37 AM, Curt Arnold wrote:
On Nov 15, 2007, at 4:36 AM, Paul Smith wrote:
Ok, i'm a bit tired, so I ended up just going simple and pretty
much following Curt's idea, see below. Thoughts?
Index: src/main/java/org/apache/log4j/net/SocketHubAppender.java
===
--- src/main/java/org/apache/log4j/net/SocketHubAppender.java
(revision 592202)
+++ src/main/java/org/apache/log4j/net/SocketHubAppender.java
(working copy)
@@ -17,18 +17,18 @@
package org.apache.log4j.net;
-import java.util.Vector;
-import java.net.Socket;
-import java.net.ServerSocket;
-import java.net.SocketException;
-import java.io.ObjectOutputStream;
import java.io.IOException;
import java.io.InterruptedIOException;
+import java.io.ObjectOutputStream;
import java.net.InetAddress;
+import java.net.ServerSocket;
+import java.net.Socket;
+import java.net.SocketException;
+import java.util.Vector;
+import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.helpers.LogLog;
import org.apache.log4j.spi.LoggingEvent;
-import org.apache.log4j.AppenderSkeleton;
/**
Sends [EMAIL PROTECTED] LoggingEvent} objects to a set of remote log servers,
That chunk seems just like the IDE at work moving things around.
@@ -271,6 +271,19 @@
}
/**
+ * Once the [EMAIL PROTECTED] ServerSocket} is created and bound, this
method is called to notify the class the details
+ * of the address and port chosen. In the standard
SocketHubAppender case this will be the
+ * requested port, but if the port is specified as 0, then a
random port is chosen by the underlying OS.
+ * Child classes may be interested in the actual port chosen,
and this method may be overridden
+ * and used to gain the details of the actual socket being
listened on.
+ * @param address
+ * @param actualPortUsed
+ */
+ protected void socketBound(InetAddress address, int
actualPortUsed) {
+
+ }
+
+ /**
This class is used internally to monitor a ServerSocket
and register new connections in a vector passed in the
constructor. */
Will discuss later in message.
@@ -280,6 +293,7 @@
private Vector oosList;
private boolean keepRunning;
private Thread monitorThread;
+private ServerSocket serverSocket;
/**
Create a thread and start the monitor. */
@@ -288,9 +302,15 @@
port = _port;
oosList = _oosList;
keepRunning = true;
+ try {
+serverSocket = new ServerSocket(port);
+ } catch (IOException e) {
+throw new RuntimeException(Failed to create a
ServerSocket, e);
+ }
monitorThread = new Thread(this);
monitorThread.setDaemon(true);
monitorThread.start();
+ socketBound(serverSocket.getInetAddress(),
serverSocket.getLocalPort());
}
/**
@@ -320,9 +340,8 @@
they connect to the socket. */
public
void run() {
- ServerSocket serverSocket = null;
+
try {
-serverSocket = new ServerSocket(port);
serverSocket.setSoTimeout(1000);
}
catch (Exception e) {
This still moves behavior around a bit. I noticed that the inner
class is not defined as static, so it has access to all the methods
and members of its enclosing class, so you could keep the same
notification method, but minimize the changes to the SocketMonitor
by just calling socketBound after the existing socket creation code.
@@ -323,6 +336,7 @@
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(port);
+socketBound(serverSocket.getInetAddress(),
serverSocket.getLocalPort());
serverSocket.setSoTimeout(1000);
}
catch (Exception e) {
But I didn't see much benefit from hiding the rest of the
serverSocket from the extending class, so I first simplified the
code to:
@@ -323,6 +336,7 @@
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(port);
+socketBound(serverSocket);
serverSocket.setSoTimeout(1000);
}
catch (Exception e) {
which
Re: [PROPOSAL] SocketHubAppender change - allow auto port choice
On 07/11/2007, at 7:15 PM, Curt Arnold wrote:
On Nov 7, 2007, at 1:55 AM, Curt Arnold wrote:
Okay, I'm about ready to fall over, but I looked at zeroconf and
see your motivation for moving the binding onto the main thread so
you continue the set up in
ZeroConfSocketHubAppender.activateOptions. However instead of
changing the behavior, I'd be more inclined to make a few changes
to SocketHubAppender to make it more amenable to extension but keep
the old behavior. I'd suggest:
Moving ServerMonitor out to a separate public class.
Move the self-start in ServerMonitor to
SocketHubAppender.startServer.
Make SocketHubAppender.startServer protected and overload it in
ZeroConf.
Add a protected SocketHubAppender.stopServer and move the
ServerMonitor.stopMonitor code there.
I'd suggest that you not take code suggestions from me too seriously
this late at night. There is probably a cleaner way to be able to
provide a hook for the zeroconf registration code to run. Maybe
adding like adding
protected void socketBound(ServerSocket s) {
}
notification method to SocketHubAppender and then hook it at
ZeroConfSocketHubAppender to publish the address.
Before I forget (currently in the middle of quartely software release
week.. extremely overloaded, I'm not ignoring this..), yeah I agree
with this approach. I'd be tempted as part of the separation to
introduce a standard Java Listener interface and have socketBound and
socketAccept callbacks while where there.
I'm not exactly sure when I'll get to it though, this week is going to
be busy. May not be till Friday.
cheers,
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing code to log4j?
Patch against the current code-base attached to a bugzilla issue is a good start. You should prefix all the source code with the ASL 2.0 license and note in the issue that your are donating this to the ASF. After that it's a matter for us to review the patch. cheers, Paul On 07/11/2007, at 3:55 PM, Will Sargent wrote: Just a follow up and reminder, 'cos the wiki tells me I should not hesitate to insist if I don't get an answer... How do I contribute code? Who is the best person to talk to? Will. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: Contributing code to log4j?
On 07/11/2007, at 4:06 PM, Will Sargent wrote: Paul Smith wrote: Patch against the current code-base attached to a bugzilla issue is a good start. You should prefix all the source code with the ASL 2.0 license and note in the issue that your are donating this to the ASF. After that it's a matter for us to review the patch. Thanks. I assume I can create a bug myself and attach it. Current means trunk? We'd be pretty poor support if our users couldn't create a bug... :) go for it. current does == trunk, yes. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCON, board Report, release cycle, etc
I did push component, receivers, etc to release since I expected Chainsaw to be pushing for a release and they'd be done simultaneously. However, there has been no chainsaw commits since the log4j 1.2.15 release. I think we should at least get the temporary encoding fix on UTF-8's and we need address the tarball/ webstart/apache release process issue, but I don't know what other items are blocking a Chainsaw 2.0 release. Maybe we can talk about it here and then someone can log a bug report for the release and connect the blocking issues. I'm hoping to have a crack at the encoding issue today. I don't think there's anything else pressing other than the release process itself. I would assume that we'd do log4j 1.2.16, extras 1.1 and jul-log4j- bridge at the same time. Sounds good. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][RESULT] Publish log4j-1.2.15_rc6, extras-1.0_rc5 and staged website
On 30/08/2007, at 2:36 PM, Curt Arnold wrote: Vote called 2007-08-25 at 9:58 PM CDT, vote concluded 2007-08-29, 11:35 CDT. +1 from Curt Arnold, Scott Deboy, Paul Smith +0 from Jacob Kjome all PMC members, no other votes. Proceeding to place releases on distribution servers. Will update web site tomorrow after releases have had time to propagate to mirrors and will then send announcement. mvn band:play - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: latest log4j trunk mvn test failures
Hopefully fixed now. The test was picking up NDC content set on a previous test. Added setUp and tearDown methods that clear the NDC and MDC before and after the tests. Guess I only ran the test in isolation. All looks good now, thanks. I've been burnt by tests like these myself, no fun. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn clean install failing for extras
must be a Windows versus *nix problem, I just svn update; mvn clean install and it's all kosher on my laptop. Paul On 24/08/2007, at 8:09 AM, Scott Deboy wrote: The xsltLayout tests are failing - the first lines aren't matching - it looks like there is a line break as the first line of each of the filtered entries.. Failing tests: testAtom(xsltlayouttest) testAtomNS(xsltlayouttest) testBasic(xsltlayouttestcase) testLocaitonInfo(xsltlayouttestcase) testCDATA(xsltlayouttestcase) testNull(xsltlayouttestcase) testMDC(xsltlayouttestcase) testMDCEscaped(xsltlayouttestcase) Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: Chainsaw webstart (was Re: Receivers and customizing the artifact output)
There was a jar signing thread on [EMAIL PROTECTED] (http://mail- archives.apache.org/mod_mbox/incubator-general/200708.mbox/% [EMAIL PROTECTED]) already in progress about digitally signing jars. The initial post has linked to describe how the Eclipse Foundation digitally signs their jars. To do it right, it would appear to require a purchased code signing key from Thwate, Verisign or similar which would cost several hundred dollars a year and secured hardware and a process to ensure that the code signing key is only applied to legitimate code. The thread didn't seem to reach any conclusions, but just seemed to die out. Technically you do not need to purchase a code signing certificate. I already have a Thawte email certificate that allows me to sign code and it appears as signed by 'Paul Smith [EMAIL PROTECTED] (see [1]). On initial download it allows the users to choose whether to trust this certificate or not by displaying the details. It's never forced on the users. If the user chooses no, the download stops. This is what happens with Chainsaw via Webstart now. Whether this is acceptable to the ASF is entirely up for discussion. I personally don't see this signing mechanism any different than the PGP one; at the end of the day the user needs to decide if user Bob encoded in the KEYS is acceptable to them. The Web of Trust of the PGP is nice, but then so is the Thawte (and others) Certificate Authority chain. Thawte has it's own WOT too (see [2]), I consider them 2 different ways of doing the same thing. It is straight forward and free to gain a Thawte Freemail certificate, which only displays the email address in the certificate. To be able to add your personal name into the certificate requires at least 2 notaries to verify your identity. I went through this process about 18 months ago and managed to find 2 people verified by Thawte and registered notaries who performed this service for free (I bought them coffee for their troubles). I found this process pretty painless really, only Thawte's own website being a little weird to work through. I don't need to be the signer, it could be anyone from the PMC. I'm simply the one that's setup at the moment. Paul [1] http://www.thawte.com/secure-email/personal-email-certificates/ index.html?click=main-nav-products-email [2]http://www.google.com/search?q=thawte%20web%20of%20trust
Re: Receivers and customizing the artifact output
Could you refresh me on the technical issue that you are trying to work around? I looked in the archives and it didn't jump out at me. I tried googling the original thread I posted about this a while back, but honestly, I can't seem to find it. So, here goes. Some Receiver implementations (DB, JMS in particular) require specific implementation drivers to work. These Receivers do not work in _any_ distribution without having, say, the JTDS JDBC driver to connect to ones local SQL Server db using DBReceiver, or, say, the ActiveMQ jars available so as to use the JMSReceiver connected through an ActiveMQ JMS bus. Obviously we can't practically or legally bundle all known relevant driver JARs with Chainsaw. So, putting aside the Webstart distribution for a second, even a normal downloaded 'double-clickable' jar distribution simply will not work with DBReceiver and JMSReceiver. Period. One could get around this by forcing the user to place these driver/ implementation jars aside the Chainsaw distribution jars and fudge either the Manifest 'Main-class' parameters or any starting script to force inclusion of these JARs in the runtime Chainsaw classpath. That's a bit lame IMHO. Instead, Chainsaw is configured to use a custom Classloader (PluginClassLoader). Any jars found in ~/.chainsaw/plugins are loaded by this Classloader. The TCCL is set at startup. This does come with a caveat though. The JMSReceiver and DBReceiver etc cannot be loaded by the parent/standard classloader. This is because if the parent classloader loads the JMSReceiver class and during init it tries to find the implementation class (say, JDBC driver) it can't 'see' the class available in the child classloader. Therefore, for the PluginClassloader to work, the jar containing the JMSReceiver and DBReceiver need to sit along side their implementation jars inside the plugins directory. This allows both the Receiver class and it's helper driver class to be loaded by the same class loader. This is why I would like to have a customized Receiver distribution. One that allows a second artifact for the user to download and place in the plugins folder if they need DBReceiver or JMSReceiver functionality. It still seems to me that Webstart doesn't align well with the ASF release infrastructure. I don't see a way for us to leverage the ASF web of trust of GPG signatures to verify a signed jar and the current Webstart version of Chainsaw isn't served through the mirrorred distribution server and not archived. I also could not find a release vote in the archives. I'm fairly uncomfortable with what we have out there and would like to have a formal release. The Webstart distribution is signed. The user is prompted to accept a certificate with my name and email address visible (see previous reply on a different thread). This is IMHO no different from a PGP signed distribution. The user simply sees 'Bob Bar [EMAIL PROTECTED]' or whoever as the signer. The Webstart distribution becomes the 'latest stable, easily accessible release'. The other distributions can form the archive if needed. There is nothing preventing a single individual or organization repackaging a Chainsaw release for use with Webstart, but it seems problematic as an official release mechanism. Could we have a tool/ script in the tarball/zip release that allows an individual or organization to sign the jars with their signature to support private webstart deployments? So we would send up with a tarball and zip that would: The current Maven pom allows easy code signing by anyone, just setup an active profile with 4 properties that are required for code signing. (keystore, keystore password, key alias, and key password). a) Could be run double clicking on the chainsaw jar (where supported) or by java -jar apache-chainsaw-2.0.jar). b) Could be run on Mac OS/X platforms by clicking on Chainsaw.app c) Could be jarsigned by running some script and then copied to a web server for deployment. I think we should do all these AND: D) Webstart distribution I really think the Webstart distribution is important. I agree it needs to abide by the release voting mechanism, and we've been a bit independent here updating that. I'm happy to go through a formal release process, but I'm VERY passionate about retaining the Webstart distribution. I'd be very keen if all 3 of us active devs are setup to sign the Webstart distribution. It doesn't need to be me. Hoping this information helps. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Publish snapshots?
Do you think it's worth publishing some of the latest log4j-* snapshots to the snapshot repo? http://people.apache.org/repo/m2-snapshot-repository/ Paul
Receivers and customizing the artifact output
I had a crack at working out how to create 2 separate artifacts for the log4j-receivers module, 1 for the primary artifact (as current) and one a chainsaw-specific artifact that excludes the JMS, DB and VFS-based Receivers. This is needed for the Webstart version because of the difference in classloaders being used. I found this thread extremely useful and promising: http://www.mail-archive.com/[EMAIL PROTECTED]/msg68479.html Which looked like it would work a treat, but unfortunately I hit this issue with the maven-jar-plugin: http://jira.codehaus.org/browse/MJAR-30 Given the 2nd artifact is really 'everything but these ones excluded' without the exclude feature we're a bit stuffed. I may have to resort to an antrun plugin usage to get what we need. The build-helper plugin can still help us here (slight pun intended). Just thought I'd update everyone with where I'm at. cheers, Paul
Re: svn commit: r564112 - /logging/chainsaw/trunk/src/main/java/org/apache/log4j/chainsaw/vfs/VFSLogFilePatternReceiver.java
Yes. I'm not using maven at the moment (waiting until this release gets out). I'll try not to make changes that could break things! (eclipse's maven support was a bit too confusing for me). it's different, but it works great for me. Ping me on MSN one day and I'll help you through it. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JUL appender
yep, here: http://people.apache.org/builds/logging/log4j/1.2.15/ I've updated the site with your details. cheers, Paul On 09/07/2007, at 5:36 PM, Sagi Mann wrote: Hi Paul, I'll test the jar tomorrow. Is there a snapshot binary for log4j 1.2.15 as well? You may also add my email [EMAIL PROTECTED] in the web page, tnx. Thanks, Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 01:31 AM To: Log4J Developers List Subject: Re: JUL appender New snapshot setup here: jars: http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/ logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/ http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/ logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/apache-jul-log4j- bridge-1.0.0-20070708.221928-3.jar site: http://people.apache.org/~psmith/logging.apache.org/sandbox/jul- log4j-bridge/ I've added attribution to you in the changes.xml and list of contributors. Let me know if you'd rather have your name removed (or info update). cheers, Paul On 08/07/2007, at 4:49 PM, Sagi Mann wrote: Nice catch! Thanks for helping out with the investigation. Could you pls point me to the proper snapshot URL? Thanks, Sagi From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Friday, July 06, 2007 06:22 AM To: Log4J Developers List Subject: Re: JUL appender finally worked it out. mvn test runs do not run in isolated classloaders so a prior test case had added another JULAppender to the logger configuration, which was using a different level converter. I couldn't work out why TRACE was being mapped to INFO until I toStringed the appender on the doAppend loop. Looks much better. the jul bridge release will depend on a 1.2.15 and companion official release. Once they are officially signed off a vote can be taken to vote on the bridge being released. It would be nice if you could grab the latest snapshot build and confirm the behavior works to your satisfaction? The problem is that the people.apache.org site is down so I can't publish a new snapshot distro for testing: http://monitoring.apache.org/status/ cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
New snapshot setup here: jars: http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/ logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/ http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/ logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/apache-jul-log4j- bridge-1.0.0-20070708.221928-3.jar site: http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j- bridge/ I've added attribution to you in the changes.xml and list of contributors. Let me know if you'd rather have your name removed (or info update). cheers, Paul On 08/07/2007, at 4:49 PM, Sagi Mann wrote: Nice catch! Thanks for helping out with the investigation. Could you pls point me to the proper snapshot URL? Thanks, Sagi From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Friday, July 06, 2007 06:22 AM To: Log4J Developers List Subject: Re: JUL appender finally worked it out. mvn test runs do not run in isolated classloaders so a prior test case had added another JULAppender to the logger configuration, which was using a different level converter. I couldn't work out why TRACE was being mapped to INFO until I toStringed the appender on the doAppend loop. Looks much better. the jul bridge release will depend on a 1.2.15 and companion official release. Once they are officially signed off a vote can be taken to vote on the bridge being released. It would be nice if you could grab the latest snapshot build and confirm the behavior works to your satisfaction? The problem is that the people.apache.org site is down so I can't publish a new snapshot distro for testing: http://monitoring.apache.org/status/ cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
I have not had any success in tracking down why that test is failing. I'm currently suffering a bad cold and caught up in a very busy engineering schedule at work, so I'm not finding as much time to look further into this at the moment. On 05/07/2007, at 2:15 AM, Sagi Mann wrote: Hi Paul, Any success getting the unit test to run inside eclipse? I haven't had a chance to set up the env yet. What is the status of this code regarding the companion release? thanks, Sagi Mann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: Chainsaw harmonization, branding, etc.
I don't think we can redistribute activation.jar, jms-1.1.jar, jmxri-1.2.1.jar, jmxtools-1.2.1.jar and mail-1.4.jar which are currently included in the generated tarball and zip archive. They are in the assembly since they are referenced by log4j, but they can be suppressed. None of those should be shipped anyway. Chainsaw either does not use them, or need to be placed in the plugins directory alongside the driver-specific jar (in the case of the jms one). We'd also want to specifically exclude the VFS, DB and JMS Receivers from the distribution for the same reason, hence the need for some customized Receiver distribution for Chainsaw only. We might as well be consistent with a tarball distro, but I'm not sure that's what the users would want to use. For non-webstart operations I actually think letting the user use Maven to build the complete distribution including all dependencies is actually probably the most pain-free for a user. That would require Maven and a JDK where the current tarball can be launched with just a JRE and tar. yes true. I was originally thinking that there was more jars that need to be distributed than can normally be with an Apache distribution (LGPL etc). Given that the VFS and jmdns bits and bobs are now ASL compatible I think that has been removed. Now the Webstart and tarball distribution can contain the exactly the same elements. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw TODO's
On 30/06/2007, at 7:15 AM, Curt Arnold wrote: There is a splash screen that shows Chainsaw history. That should be integrated into src/changes/changes.xml. Is this is the Release Notes section you're referring to? Yes I think tracking the changes in changes.xml is probably best from now on. If there's a way to generate from this an html file that is 'injected' into the generate-sources phase of maven, then Chainsaw can ship with a HTML copy of that file. I placed an empty development roadmap in src/site/apt/roadmap.apt. thanks. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project logging-log4j-chainsaw (in module logging-chainsaw) failed
(), URLEncoder.encode (identifier) + .xml); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/LogPanel.java:2125: warning: [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated [javac] URLEncoder.encode(getIdentifier() + COLORS_EXTENSION)); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java:42: cannot find symbol [javac] symbol : class EnhancedPatternLayout [javac] location: class org.apache.log4j.chainsaw.layout.EventDetailLayout [javac] private EnhancedPatternLayout patternLayout = new EnhancedPatternLayout(); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/messages/MessageCenter.java:77: warning: [deprecation] org.apache.log4j.TTCCLayout in org.apache.log4j has been deprecated [javac] private Layout layout = new TTCCLayout(); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/zeroconf/ZeroConfPlugin.java:106: cannot find symbol [javac] symbol : variable Zeroconf4log4j [javac] location: class org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin [javac] Zeroconf4log4j.shutdown(); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/zeroconf/ZeroConfPlugin.java:126: cannot find symbol [javac] symbol : variable Zeroconf4log4j [javac] location: class org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin [javac] jmDNS = Zeroconf4log4j.getInstance(); [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/zeroconf/ZeroConfPlugin.java:129: cannot find symbol [javac] symbol : variable ZeroConfSocketHubAppender [javac] location: class org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin [javac] ZeroConfSocketHubAppender.DEFAULT_ZEROCONF_ZONE, [javac] ^ [javac] /x1/gump/public/workspace/logging-chainsaw/src/main/ java/org/apache/log4j/chainsaw/zeroconf/ZeroConfPlugin.java:132: cannot find symbol [javac] symbol : variable ZeroConfSocketHubAppender [javac] location: class org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin [javac] jmDNS.addServiceListener (ZeroConfSocketHubAppender.DEFAULT_ZEROCONF_ZONE, discoveredDevices); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 9 errors [javac] 12 warnings BUILD FAILED /x1/gump/public/workspace/logging-chainsaw/build.xml:59: Compile failed; see the compiler error output for details. Total time: 5 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/logging-chainsaw/ logging-log4j-chainsaw/rss.xml - Atom: http://vmgump.apache.org/gump/public/logging-chainsaw/ logging-log4j-chainsaw/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 1925062007, vmgump.apache.org:vmgump-public: 1925062007 Gump E-mail Identifier (unique within run) #48. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
On 25/06/2007, at 4:32 PM, Sagi Mann wrote: I have a few questions: I originally concentrated on ease-of-use as much as possible. I, as Arnold, am concerned that usage will become overly complex. Current use is to treat JulAppender as if it was ConsoleAppender (even replacing any refs to ConsoleAppender with JulAppender would work). This way, existing log4j apps running in JUL environments will have better integration without any changes to code or deployment (log4j config can be changed without the need to redeploy everything). Will usage be somehow affected if this appender is provided outside log4j itself? (i.e. apps may need to be redeployed, jars added, etc) Will usage be somehow affected if this appender is provided as a part of a larger jul bridge package (i.e. more complex configuration, env prerequisites, code changes, etc)? In terms of code change, it is only an additional JAR file that would need to be added into a deployed project. If the JULAppender was added to log4j 1.2.15, the user would still need to update their log4j jar, so it's not really any different. I think Curt's concerns of changing log4j 1.2.15 this late is warranted, and I don't see this Appender as a core component. I would have thought putting it in the bridge project was a logical place. Anything java.util.logging that relates to log4j is in here. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JUL appender
I have got the JULAppender (subtle rename, made it upper case to match the rest of the bridge projects naming conventions) into the bridge project in my local workspace. I've slightly changed the Appender to use the JULLevelConverter interface so that users can customize the Level mapping. I've added a test case to cover this. Files have been moved into the .jul package name spaces as well. What's odd is that running all the unit tests inside Eclipse pass fine, but not under maven. I haven't worked out what is going on there, it appears the TestHandler (renamed AssertionHandler to prevent maven thinking it's a unit test) is being activated by a trace level event when it shouldn't. I don't quite understand it yet. Sagi, if I commit my local changes soon, would you be able to checkout the bridge project and help debug this? cheers, Paul On 25/06/2007, at 4:42 PM, Sagi Mann wrote: Thanks for the feedback, makes total sense to me as well. Sagi Mann -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 09:44 AM To: Log4J Developers List Subject: Re: JUL appender On 25/06/2007, at 4:32 PM, Sagi Mann wrote: I have a few questions: I originally concentrated on ease-of-use as much as possible. I, as Arnold, am concerned that usage will become overly complex. Current use is to treat JulAppender as if it was ConsoleAppender (even replacing any refs to ConsoleAppender with JulAppender would work). This way, existing log4j apps running in JUL environments will have better integration without any changes to code or deployment (log4j config can be changed without the need to redeploy everything). Will usage be somehow affected if this appender is provided outside log4j itself? (i.e. apps may need to be redeployed, jars added, etc) Will usage be somehow affected if this appender is provided as a part of a larger jul bridge package (i.e. more complex configuration, env prerequisites, code changes, etc)? In terms of code change, it is only an additional JAR file that would need to be added into a deployed project. If the JULAppender was added to log4j 1.2.15, the user would still need to update their log4j jar, so it's not really any different. I think Curt's concerns of changing log4j 1.2.15 this late is warranted, and I don't see this Appender as a core component. I would have thought putting it in the bridge project was a logical place. Anything java.util.logging that relates to log4j is in here. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
http://svn.apache.org/repos/asf/logging/sandbox/jul-to-log4j-bridge/ you'll need maven 2.0.6+. mvn clean package Currently fails with 1 unit test. You can see the details of the failure in target/surefire-reports which is created during the test run. Any help appreciated, the tests work fine in Eclipse. cheers, Paul On 25/06/2007, at 4:54 PM, Sagi Mann wrote: Sure. However, I'm having firewall/proxy issues here in the office. I will probably not be able to checkout the code, but I could start by looking at it using a browser… Pls provide the repository link once all is checked in. thanks, Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 09:55 AM To: Log4J Developers List Subject: Re: JUL appender I have got the JULAppender (subtle rename, made it upper case to match the rest of the bridge projects naming conventions) into the bridge project in my local workspace. I've slightly changed the Appender to use the JULLevelConverter interface so that users can customize the Level mapping. I've added a test case to cover this. Files have been moved into the .jul package name spaces as well. What's odd is that running all the unit tests inside Eclipse pass fine, but not under maven. I haven't worked out what is going on there, it appears the TestHandler (renamed AssertionHandler to prevent maven thinking it's a unit test) is being activated by a trace level event when it shouldn't. I don't quite understand it yet. Sagi, if I commit my local changes soon, would you be able to checkout the bridge project and help debug this? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
oh, you actually need more than just maven, read the installation guide for Chainsaw: http://svn.apache.org/repos/asf/logging/chainsaw/trunk/HOWTOBUILD.txt in the bridge's case, you only need log4j 1.2.15-SNAPSHOT from the branch svn, and the log4j-component and receivers to build the whole project (they're needed to compile the Receiver). It's actually not going to be simple as I thought it would to build this. Paul On 25/06/2007, at 5:07 PM, Paul Smith wrote: http://svn.apache.org/repos/asf/logging/sandbox/jul-to-log4j-bridge/ you'll need maven 2.0.6+. mvn clean package Currently fails with 1 unit test. You can see the details of the failure in target/surefire-reports which is created during the test run. Any help appreciated, the tests work fine in Eclipse. cheers, Paul On 25/06/2007, at 4:54 PM, Sagi Mann wrote: Sure. However, I'm having firewall/proxy issues here in the office. I will probably not be able to checkout the code, but I could start by looking at it using a browser… Pls provide the repository link once all is checked in. thanks, Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 09:55 AM To: Log4J Developers List Subject: Re: JUL appender I have got the JULAppender (subtle rename, made it upper case to match the rest of the bridge projects naming conventions) into the bridge project in my local workspace. I've slightly changed the Appender to use the JULLevelConverter interface so that users can customize the Level mapping. I've added a test case to cover this. Files have been moved into the .jul package name spaces as well. What's odd is that running all the unit tests inside Eclipse pass fine, but not under maven. I haven't worked out what is going on there, it appears the TestHandler (renamed AssertionHandler to prevent maven thinking it's a unit test) is being activated by a trace level event when it shouldn't. I don't quite understand it yet. Sagi, if I commit my local changes soon, would you be able to checkout the bridge project and help debug this? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system. Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
On 24/06/2007, at 7:03 AM, Curt Arnold wrote: On Jun 23, 2007, at 11:32 AM, Scott Deboy wrote: The test case looks fine. Anyone opposed to me merging this into the 1.2 branch, added to a new org.apache.log4j.jul package. Yes, I am opposed at the moment. log4j 1.2.15's release is imminent and would really like to avoid adding a new enhancement right at the end of a review cycle. Plus, it likely depends on JDK 1.4 which log4j 1.2 can be built (using Ant) on JDK 1.3. Plus, I'm not convinced that it needs to be in log4j itself, but isn't better packaged as a companion. I also think it's best done as some sort of companion. Perhaps it could live inside the jul-log4j-bridge project? I haven't been tracking the JUL - log4j stuff as well as I would like, but there are enough things that I'm unsettled with that I'm not ready to see them in an imminent release. If you're feeling unsettled, I would appreciate it if you could tell us what is unsettling you? It's hard to address any issues without feedback. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JUL appender
I don't think you have access to commiting to the logging svn tree? If not, you should update the bugzilla issue you raised with the latest patch against the 1.2 branch. We can apply it from there. The jul-to-log4jbridge is still not officially released, but you can see a sample of what the website will appear as here: http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j- bridge/ Some downloadable maven artifacts are available here: http://people.apache.org/~psmith/logging.apache.org/repo/org/apache/ logging/apache-jul-log4j-bridge/1.0.0-SNAPSHOT/ Includes source and binary distributions. Information for SVN access is here: http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j- bridge/source-repository.html but the svn url is http://svn.apache.org/repos/asf/logging/sandbox/jul-to-log4j-bridge/ cheers, Paul On 22/06/2007, at 3:33 PM, Sagi Mann wrote: Paul, 'jul' it is. Should I check in under the v1_2branch? By the way, where can I find info on the bridge project you mentioned? Thanks. Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Fri 6/22/2007 01:04 To: Log4J Developers List Subject: Re: JUL appender I think 'org.apache.log4j.jul' might be a good choice for packaging. That's what I've used for log4j related code in the jul- log4j-bridge project. Any non-log4j class (or more formally, all java.util.logging ) code could go in 'org.apache.logging.jul'. This way there is a clean seperation of what is log4j related, and what is not. cheers, Paul I believe we are starting to standardize on 'org.apache.logging.something' as the preferred package naming structure for non-core log4j stuff. On 22/06/2007, at 7:49 AM, Sagi Mann wrote: Got it working. Thanks, Paul. The testcase is now attached in issue 42664: http://issues.apache.org/bugzilla/show_bug.cgi?id=42664 I'd appreciate if someone verifies this is the expected kind of test case. Currently, both appender and test classes are defined under the org.apache.log4j package. What is the final desired location, and may I commit under v1_2branch? thanks. On 6/21/07, Sagi Mann [EMAIL PROTECTED] wrote: Still, same error. Any advice? Can I get SVN to produce more error detail? I use the cmdline: svn checkout http://svn.apache.org/repos/asf/logging/log4j/ branches/v1_2-branch/ Thanks, Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 12:36 PM To: Log4J Developers List Subject: Re: JUL appender This is the correct URL for downloading via svn: http://svn.apache.org/repos/asf/logging/log4j/branches/v1_2-branch/ cheers, Paul On 20/06/2007, at 5:27 PM, Sagi Mann wrote: Scott, Where can I find information on setting up SVN for use with Apache's SVN server? I'm using SVN 1.4.4 and unable to initially checkout from: http://svn.apache.org/viewvc/logging/log4j/branches/v1_2-branch error is: svn: PROPFIND request failed on '/viewvc/logging/log4j/branches/ v1_2-branch' svn: PROPFIND of '/viewvc/logging/log4j/branches/v1_2-branch': could not connect to server (http://svn.apache.org) Maybe I need a username other that guest? thanks, Sagi Mann -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 03:41 PM To: Log4J Developers List [EMAIL PROTECTED] Subject: RE: Jull Appender We're currently integrating the 1.2 branch (http://svn.apache.org/viewvc/logging/log4j/branches/v1_2-branch/ ) with the 'companions' structure (http://svn.apache.org/viewvc/logging/log4j/companions/) So please provide patches against that codebase. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Sagi Mann [mailto:[EMAIL PROTECTED] Sent: Mon 6/18/2007 5:21 AM To: log4j-dev Subject: RE: Jull Appender Hi Scott, I'm using the 1.2.14 package. Based on the URL you sent, seems like I need the 1.3 package to get going. How do I get all the 1.3 code? I have SVN, but I'm not sure of the checkout cmdline. Where can I find this info in log4j site? thanks. Sagi -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 08:29 PM To: Log4J Developers List; [EMAIL PROTECTED] Subject: RE: JUL appender Great! The tests you'd write aren't quite like the tests we've got (at least that I could find), but here is the link to what we have: http://svn.apache.org/viewvc/logging/log4j/trunk/tests/src/java/ org/apac he/log4j/ You'd need to use a memoryhandler on the java.util.logging side and assert that an event sent by log4j was received by the memoryhandler. Good stuff! Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950
Re: apache-log4j-component-1.0 rc2
On 21/06/2007, at 4:18 PM, Scott Deboy wrote: I'd still like us to consider finishing the property support included in LoggerRepositoryEx (mostly requiring new functionality being added to LoggingEvent). It would make finishing up the backporting of the appenders receivers essentially complete. Will these new functionality still retain binary backward compatibility? Also, I'm not sure of the state of our support for slf4j via ULogger - are we planning on removing that or tracking slf4j? Gosh, I hadn't even thought about this. I don't even remember the concept of ULogger. Maybe slf4j is the way to go, we could use maven profiles to produce two seperate versions of log4j? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549610 - /logging/log4j/branches/v1_2-branch/BUILD-INFO.txt
Just an additional note on maven deployment that I've learned the hard way, perhaps you might want to consider adding this as a note. Maven or the Wagon deployment plugin appears to assume the local username is the destination username, _even_ if you specify a username property in the settings.xml. For example, the username on my local computer is 'paulsmith', however my remote username is psmith. I have only found it works if I manually add '-Duser.name=psmith' to the commandline ala: mvn deploy assembly:assembly -Duser.name=psmith I think this is a known bug with the wagon deployment at the moment. Paul On 22/06/2007, at 6:55 AM, [EMAIL PROTECTED] wrote: Author: carnold Date: Thu Jun 21 13:55:23 2007 New Revision: 549610 URL: http://svn.apache.org/viewvc?view=revrev=549610 Log: Bug 37930: Add Maven settings.xml info Modified: logging/log4j/branches/v1_2-branch/BUILD-INFO.txt Modified: logging/log4j/branches/v1_2-branch/BUILD-INFO.txt URL: http://svn.apache.org/viewvc/logging/log4j/branches/v1_2- branch/BUILD-INFO.txt?view=diffrev=549610r1=549609r2=549610 == --- logging/log4j/branches/v1_2-branch/BUILD-INFO.txt (original) +++ logging/log4j/branches/v1_2-branch/BUILD-INFO.txt Thu Jun 21 13:55:23 2007 @@ -32,3 +32,27 @@ -Dversion=1.1 -Dpackaging=jar -Dfile=~/jms1.1/lib/jms.jar $ cd log4j $ mvn site assembly:assembly + + +If you intended to deploy jars to the repo or update the site, +you need to copy your private keys for people.apache.org +over to ~/.ssh and update ~/maven-2.0.6/conf/settings.xml +to specify user name and key location. + +server + idlogging.repo/id + usernameUSERNAME for people.apache.org/username + privateKey/home/ubuntu/.ssh/id_rsa/privateKey + passphrase/passphrase +/server +server + idlogging.site/id + usernameUSERNAME for people.apache.org/username + privateKey/home/ubuntu/.ssh/id_rsa/privateKey + passphrase/passphrase +/server + +You should test your ssh connection to people.apache.org before +attempting a deployment like: + +$ ssh -l USERNAME people.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: JUL appender
I think 'org.apache.log4j.jul' might be a good choice for packaging. That's what I've used for log4j related code in the jul-log4j-bridge project. Any non-log4j class (or more formally, all java.util.logging) code could go in 'org.apache.logging.jul'. This way there is a clean seperation of what is log4j related, and what is not. cheers, Paul I believe we are starting to standardize on 'org.apache.logging.something' as the preferred package naming structure for non-core log4j stuff. On 22/06/2007, at 7:49 AM, Sagi Mann wrote: Got it working. Thanks, Paul. The testcase is now attached in issue 42664: http://issues.apache.org/bugzilla/show_bug.cgi?id=42664 I'd appreciate if someone verifies this is the expected kind of test case. Currently, both appender and test classes are defined under the org.apache.log4j package. What is the final desired location, and may I commit under v1_2branch? thanks. On 6/21/07, Sagi Mann [EMAIL PROTECTED] wrote: Still, same error. Any advice? Can I get SVN to produce more error detail? I use the cmdline: svn checkout http://svn.apache.org/repos/asf/logging/log4j/branches/ v1_2-branch/ Thanks, Sagi Mann From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 12:36 PM To: Log4J Developers List Subject: Re: JUL appender This is the correct URL for downloading via svn: http://svn.apache.org/repos/asf/logging/log4j/branches/v1_2-branch/ cheers, Paul On 20/06/2007, at 5:27 PM, Sagi Mann wrote: Scott, Where can I find information on setting up SVN for use with Apache's SVN server? I'm using SVN 1.4.4 and unable to initially checkout from: http://svn.apache.org/viewvc/logging/log4j/branches/v1_2-branch error is: svn: PROPFIND request failed on '/viewvc/logging/log4j/branches/ v1_2-branch' svn: PROPFIND of '/viewvc/logging/log4j/branches/v1_2-branch': could not connect to server (http://svn.apache.org) Maybe I need a username other that guest? thanks, Sagi Mann -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 03:41 PM To: Log4J Developers List [EMAIL PROTECTED] Subject: RE: Jull Appender We're currently integrating the 1.2 branch (http://svn.apache.org/viewvc/logging/log4j/branches/v1_2-branch/ ) with the 'companions' structure (http://svn.apache.org/viewvc/logging/log4j/companions/) So please provide patches against that codebase. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Sagi Mann [mailto:[EMAIL PROTECTED] Sent: Mon 6/18/2007 5:21 AM To: log4j-dev Subject: RE: Jull Appender Hi Scott, I'm using the 1.2.14 package. Based on the URL you sent, seems like I need the 1.3 package to get going. How do I get all the 1.3 code? I have SVN, but I'm not sure of the checkout cmdline. Where can I find this info in log4j site? thanks. Sagi -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 08:29 PM To: Log4J Developers List; [EMAIL PROTECTED] Subject: RE: JUL appender Great! The tests you'd write aren't quite like the tests we've got (at least that I could find), but here is the link to what we have: http://svn.apache.org/viewvc/logging/log4j/trunk/tests/src/java/org/ apac he/log4j/ You'd need to use a memoryhandler on the java.util.logging side and assert that an event sent by log4j was received by the memoryhandler. Good stuff! Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Sagi Mann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 10:22 AM To: log4j-dev@logging.apache.org Subject: RE: JUL appender Scott, Ok great, I've added the information and uploaded the code to issue 42664. I don't have unit tests at the moment. If there are any existing unit tests I can read for reference, I'd be happy to provide unit tests for the appender. Any advice where I can find any? thanks. -sagi -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 06:46 PM To: Log4J Developers List [EMAIL PROTECTED] Subject: RE: JUL appender We need the current Apache license added to each source file, Javadoc and comments where appropriate. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Sagi Mann [mailto: [EMAIL
Re: log4j 1.2.15 RC 3
On 21/06/2007, at 1:27 PM, Curt Arnold wrote: I've just pushed another release candidate out. This won't be the last since I forgot to update the release date and another tweak to the POM that I'd like to do. I'll likely refresh it tomorrow, but I thought I would leave it up overnight for any immediate feedback. The distributions are at http://people.apache.org/builds/ logging/log4j/1.2.15 and Maven artifacts are in the staging repo at http://people.apache.org/build/logging/repo. the repo url doesn't work for me. mkdir test cd test tar -xvzf ~/log4j/target/log4j-1.2.15.tar.gz cd apache-log4j-1.2.15 jar xf log4j-1.2.15.jar hexdump NTEventLogAppender.dll NTEventLogAppender.hex cd ../.. mkdir reference cd reference tar -xvzf ~/downloads/apache-log4j-1.2.15_rc3.tar.gz cd apache-log4j-1.2.15 jar xf log4j-1.2.15.jar hexdump NTEventLogAppender.dll NTEventLogAppender.hex cd ../.. diff -r reference test Would running a jdiff report between 1.2.14 and 15 help? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jul-log4j-bridge distribution test
Thanks muchly! On 21/06/2007, at 1:55 PM, Curt Arnold wrote: On Jun 20, 2007, at 9:10 PM, Paul Smith wrote: I've been tweaking the jul-log4j-bridge pom to experiment with the distribution mechanism, and have placed a site and repo sample here: http://people.apache.org/~psmith/logging.apache.org/ I'm not sure why the source distribution doesn't go with it. Any ideas appreciated. Paul You need to specify a maven-source-plugin in your builds section. Here is a section borrowed from the component's pom.xml. Index: pom.xml === --- pom.xml (revision 549346) +++ pom.xml (working copy) @@ -126,6 +126,27 @@ /executions /configuration /plugin + plugin +artifactIdmaven-javadoc-plugin/artifactId +executions +execution +goals +goaljar/goal +goaljavadoc/goal +/goals +/execution +/executions + /plugin + plugin +artifactIdmaven-source-plugin/artifactId +executions +execution +goals +goaljar/goal +/goals +/execution +/executions + /plugin /plugins /build dependencies Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: log4j 1.2.15 RC 3
I've done the following quick test to compare 1.2.14-1.2.15. After
unpacking both, I compared the contents of the respective jars. One
way to see missing/additional files was this:
unzip -l log4j-1.2.14.jar /tmp/log4j.1.2.14.txt
..
unzip -l log4j-1.2.15.jar /tmp/log4j.1.2.15.txt
cat log4j.1.2.14.txt | awk '{print $NF}' | sort a
cat log4j.1.2.15.txt | awk '{print $NF}' | sort b
comm -3 a b
This shows all the file entries that are not in both jars. In this
case, there are only new entries in the 1.2.15 distribution:
[EMAIL PROTECTED] tmp]$ comm -3 a b
log4j-1.2.14.jar
log4j-1.2.15.jar
META-INF/maven/
META-INF/maven/log4j/
META-INF/maven/log4j/log4j/
META-INF/maven/log4j/log4j/pom.properties
META-INF/maven/log4j/log4j/pom.xml
NTEventLogAppender.o
org_apache_log4j_nt_NTEventLogAppender.h
org_apache_log4j_Priority.h
org/apache/log4j/xml/UnrecognizedElementHandler.class
Obviously the 2 jar names are different, and the the maven stuff is
expected. The .o and .h files are new, but probably benign. The
new class, IIRC, is expected in 1.2.15.
I thought of doing byte size comparison between the file entries in
the jar, but I'm not sure what that would tell us.
From the above test, the jar looks ok to me.
A Jdiff report would be nice I think, just to compare the binary
compatibility aspects.
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
pinpoint - a proposed companion to log4j
Hi, I have been in the background working on a companion to log4j that I'm initially calling 'pinpoint'. It is designed as a log context tool to facilitate production queries. Logging events to a DB for querying is fine, except SQL queries, IHMO, on that are time consuming and unsatisfying, and miss some important features such as full text indexing. I find for my own use I tend to rely on grep/fgrep to analyse logs files because the regexp is handy, but that often trims off important stack traces. Usually you have to dice the file several times to work with it. It seemed to make sense to index these log files and be able to analyse them using Lucene. pinpoint is designed to create a Context which is a container of indexed LoggingEvents. The Context contains an Lucene index, and a serialized version of the events. searches against the index then return hits that contain offset+length pointers to the serialization file. That way the full LoggingEvent can be brought back for display in the results, formatted anyway you'd like. Using a CLI client, one can open that index and do arbitrary queries. An example is worth a thousand words: $ sh pinpoint-cli/target/appassembler/bin/pinpoint -h /temp/pinpoint- home/ -c testlog -s pinpointsearch level:INFO factory -english +message:factory -message:english [2007-06-08 12:13:00,122 INFO ][eNotificationsAction][Maintenance Tasks Scheduler_Worker-9] Executing OverdueCorrespondenceNotificationsAction: exclusionDate=2006-06-08, maxEmailSendRate=240, maxNumEmails=2147483647, sendEmailEnabled=TRUE [2007-06-08 12:13:00,553 ERROR][urityInfoRetrieveCmd][Maintenance Tasks Scheduler_Worker-9][][] Could not find class for command factory. Class com.aconex.security.command.SecuredAssetListCmd ... pinpoint Only the basics are there right now, with a simple importer utility that uses LogFilePatternReceiver to soak events from text-based log files, but obviously eventually any Receiver might be usable to soak events into a context.The CLI module has handy command-line completion support, but it could definitely do with some extensions. Pinpoint is made up of: * pinpoint-core * pinpoint-importer * pinpoint-search * pinpoint-cli and lives in a maven multi-project module setup. It relies on the log4j companion 1.0-SNAPSHOTs and log4j 1.2.15-SNAPSHOT. I'd like to eventually add a pinpoint-service module allowing standard socket/JMS-based receivers to be configured out of the box to allow easy connection to it as a remote service. Right now indexing the logs is likely to be slower than the rate of incoming events, so we'd need to build in some asynch behaviour to allow pinpoint to buffer some logs (say via an internal JMS implementation using ActiveMQ) as it processes them. This allows the producing application to not be slowed down by the indexing. I'd also like to create pinpoint-webapp to create a nice and easy deployable webapp than can browse the pinpoint contexts and easily search logs based on MDC variables etc. (Imagine browsing all logs generated by a User when using, say, MDC), and once found an interesting logging event quickly see more context lines from around that time. I'd be happy to have this added as a log4j module if other people are interested. Otherwise I'm just as happy to tinker with it and use it for my own use. Perhaps I'm the only one that wants to use logging this way? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LogFilePatternReceiver notification of completion
isn't it the reverse? I need a synchronous receiver. The current behaviour is async. ? Can I apply my change? On 18/06/2007, at 3:34 AM, Scott Deboy wrote: Sounds like an AsyncReceiver (essentially what Chainsaw is doing under the covers). Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Sat 6/16/2007 10:42 PM To: Log4J Developers List Subject: LogFilePatternReceiver notification of completion Is there any way a thread that creates a LogFilePatternReceiver to soak in a file of events can be notified or joined onto the Thread that the Receiver creates to imports the file? I can't see a way. I was wondering if I could add a small property: setUseCurrentThread(boolean) , than when true, uses the current thread for the importing, or by default (false), creates a new Thread to run it. I'd also like to change the Thread creation so that it creates nicer thread names if that's ok? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: LogFilePatternReceiver notification of completion
yep, I think that's a required step for all receivers. Thanks Scott. On 18/06/2007, at 1:22 PM, Scott Deboy wrote: Sure--fyi, I vaguely recall needing activateoptions to be ran in a new threadwithout it, chainsaw behaved badly. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Sun 6/17/2007 2:42 PM To: Log4J Developers List Subject: Re: LogFilePatternReceiver notification of completion isn't it the reverse? I need a synchronous receiver. The current behaviour is async. ? Can I apply my change? On 18/06/2007, at 3:34 AM, Scott Deboy wrote: Sounds like an AsyncReceiver (essentially what Chainsaw is doing under the covers). Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Sat 6/16/2007 10:42 PM To: Log4J Developers List Subject: LogFilePatternReceiver notification of completion Is there any way a thread that creates a LogFilePatternReceiver to soak in a file of events can be notified or joined onto the Thread that the Receiver creates to imports the file? I can't see a way. I was wondering if I could add a small property: setUseCurrentThread(boolean) , than when true, uses the current thread for the importing, or by default (false), creates a new Thread to run it. I'd also like to change the Thread creation so that it creates nicer thread names if that's ok? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system. winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
LogFilePatternReceiver notification of completion
Is there any way a thread that creates a LogFilePatternReceiver to soak in a file of events can be notified or joined onto the Thread that the Receiver creates to imports the file? I can't see a way. I was wondering if I could add a small property: setUseCurrentThread(boolean) , than when true, uses the current thread for the importing, or by default (false), creates a new Thread to run it. I'd also like to change the Thread creation so that it creates nicer thread names if that's ok? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chainsaw + Receivers + Maven: Custom distribution
Hmm, while I was mavenizing the Chainsaw site content I was reading the notes about the VFS, DB and JMS support in Chainsaw again and realise that right now, Chainsaw is bundling the DB/JMS Receivers in the maven distribution. Due to hideous classloading rules, they won't work. This is because the JMS and DB provider jars ( the implementation classes) are user specific, and need to be dropped in manually in the users plugins directory, and loaded via the PluginClassLoader that is created by Chainsaw. This means that the spec classes are loaded by the main classloader, but the child (provider) classes are in another, and they can't see each other. For Chainsaw purposes therefore, we need to ship a stripped down version of the log4j-receivers jar that does not contain these, log4j- receivers-chainsaw...? This sounds like a job for the maven assembler plugin, but I'm a new to that. Curt, do you have any suggestions as to the best way to handle this case? Chainsaw would need to declare it as a dependency I think? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Local changes to Chainsaw and pending POM and documentation work
I think I've done everything I'll need in the short term, so feel free to consolidate stuff into a parent pom. On 09/06/2007, at 5:57 PM, Curt Arnold wrote: I'm probably not going to get to it in the next day or so, but I've been thinking about looking at the Chainsaw POM and seeing what if any of the stuff from the other log4j POM's, src/site, src/ assembly. src/changes et al should be copied over. However, would not want to conflict with anything that might be happening in local copies, so if you have local mods to Chainsaw along that line or have other objects, commit or speak up or risk having to merge later. Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Zeroconf module
I moved the Zeroconf source directory recently into the main Chainsaw source tree, which I think is a mistake. Chainsaw needs to have it, but a standalone jar is needed in the client end to zeroconf-enable the application to expose it on the network. It make more sense to create a log4j-zeroconf module with just these classes, _or_ roll this up in some companion module. It's just 2 classes: http://svn.apache.org/repos/asf/logging/chainsaw/trunk/src/main/java/ org/apache/log4j/net/ Thoughts? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chainsaw maven + javadoc artifact
I'm a bit at a loss to work out how exactly to accomplish this one, so asking for advice. The Chainsaw build sort of needs a subset of the log4j javadoc bundled with it for users to read the Receiver javadoc. I'm not sure how to declare that with maven. The only way I can think of is hacky. Create the relevant javadoc jar from log4j, and do a 'mvn install' declaring some artifactId that chainsaw can use. Can anyone think of something better.. ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw Maven: completed (I think)
Got it all working. A few things: - getting the log4j 1.2 branch to mvn install was a bit of a hassle because I needed to get nteventappender.dll into my path (from 1.2.14) - the dll wasn't getting built via mvn install - should it have been? maybe another maven target I should have looked into. Weird, I didn't need to do that (but then I'm not on Windows). - I had to install each of the log4j snapshots into my local repo (the mvn install error info told me to do it - it wasn't mentioned in the build instructions) Hmm, I did update HOWTOBUILD.txt that mentioned that one needed to do a 'mvn install' in each repo. Did you do that? If you did, did it still force you to do the manual install?) - Chainsaw wouldn't mvn install until I copied known.receivers to chainsaw/target/classes (was getting an error on the receivershelpertest) Ahh, I understand now, but what's weird is that some timse the tests pass for me, but sometimes they don't. You can work around this by doing: mvn package -Dmaven.test.skip=true I'll look into it. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw Maven: completed (I think)
- Chainsaw wouldn't mvn install until I copied known.receivers to chainsaw/target/classes (was getting an error on the receivershelpertest) Fixed it, some resources were still in the java tree, where they shouldn't have been. Do: svn update mvn clean test It should consistently pass now. thanks Scott Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chainsaw Maven: completed (I think)
Ok gang, mavenization completed I think. Please grab maven 2.0.4 and install it, and if you use Eclipse, install the Maven Eclipse plugin: http://maven.apache.org/ http://m2eclipse.codehaus.org/ After installing the Maven Eclipse plugin, you can activate the project as a Maven project by doing this in Eclipse: * Right click on the project * Team-Maven-Enable (if it's not already enabled) * Team-Maven-Update Source Folders (even if it is enabled, I've found you sometimes need to do this to 'nudge' the plugin to refresh it's view of things) You will need to have installed into your local repository the snapshot releases of the log4j-* projects (component, receivers, expression-filter) as well as the log4j 1.2.15 snapshot. The steps involve: cd sub-project mvn install Once mvn install works well, you can try 'mvn package' and it will produce: * target/appassembler/bin/chainsaw shell script and chainsaw.bat batch file which can be used to launch Chainsaw from the command line If you've got OSX, then try: mvn package appbundler:bundle It will produce an OSX distribution sitting in the target directory, together with a .dmg version. I haven't added to much organizational/scm/reports stuff to the pom as yet, will do that next. Please let me know if I can help anyone get things started. Maven appears to new people to be huge and complicated (like it did for me), but it's actually quite simple at it heart. I found this free PDF most valuable reading: http://www.mergere.com/m2book_download.jsp Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chainsaw Maven
Hi all, I've begin on a maven journey recently, and I'm convinced of it's value. I would like to mavenize the Chainsaw project as part of integrating it with log4j 1.2.15. It would be nice to do a set of small directory changes to fit the standard maven project; we're not far off it, and it's not strictly necessary, but I think keeping the structure standard is probably worth the investment. So, I'm proposing we do the following: src/java - src/main/java mv *.properties into src/main/resources tree (there's only one) test - src/test/java packaging/* - src/jnlp/resources I have found the appassembler and webstart maven plugins to be outstandingly useful. Out of the box building .sh/.bat and webstart distributions. Much simpler than my ant hack! The zeroconf src tree is an interesting one. The reason that it is in a separate source tree in the first place is to make it 'optional' during the build cycle because the jmdns library is LGPL. With maven, by declaring the dependency it just goes and gets it. I'm not sure what it means for Gump though. Does gump handle maven projects? That is, are we required to provide a build.xml for Gump? The maven-eclipse plugin (and assuming IDEA) are fantastic. All of this depends on using the log4j-component/receiver/etc modules as snapshots, which is a straightforward svn checkout, and mvn install. I'm happy to do all of this, just want to check. Isuru is starting to get involved via the GSOC, and I'd hope not to muck anyone about too much. Thoughts? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoC Project : Enhancing Chainsaw
that sleep level should be a receiver configurable setting too. A
default of 5 seconds is good, and perhaps we should have per-remote
resource type defaults. that is, perhaps 1 second is ok as a default
for files, but 5 seconds seems a nice default for other classes of
remote protocols (http, sftp etc).
Not sure what the overhead is in VFS for gaining access to the
RandomAccessContent object. Be interesting to profile that. Do you
have access to a Profiler tool like Yourkit ?
cheers,
Paul
On 29/05/2007, at 10:25 AM, Scott Deboy wrote:
Looks good..I'd suggest doing a file.exists on the 1st line of the
do loop reset the pointer to zero if it's false, sleep for 5
secs, and continue..
Will help folks like me who use apps which truncate a log file on
app start.
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax:503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
-Original Message-
From: Isuru Suriarachchi [mailto:[EMAIL PROTECTED]
Sent: Mon 5/28/2007 7:00 AM
To: Log4J Developers List
Subject: GSoC Project : Enhancing Chainsaw
Hi Scott and Paul,
I have been working on my first task to fix the tailing capability
of VFS
log receiver, for last few days. First of all I would like to
describe why
tailing is not working in the current implementation as I
understand and
then I will suggest my solution.
Current Implementation
In the current implementation, in VFSLogFilePatternReceiver, VFSReader
creates a FileSystemManager and makes a FileObject by giving the
file URL
using the created FileSysemManager. After that it creates an
InputStreamReader to read the log file and passes it to the process
(reader)
method in the LogFilePatternReceiver in log4j. In this process()
method, a
BufferedReader is created using the reader passed and this
BufferedReader is
checked for new lines (new logs in the log file), until 'tailing'
is kept
true.
This works for URLs in the local file system (Eg: file:///foo/
bar.log ) as
the BufferedReader is updated whenever a new line is written to the
file.
But when the log file is accessed through some other protocol, say
http,
this Buffered reader is not updated through the protocol when new
lines are
added to the log file. That's why tailing is not working with such a
protocol.
My Solution
As I can see, keeping only the InputStreamReader of the file in the
method
we run the while loop (the loop which runs until 'tailiing' is kept
true) is
not going to work. And also we can't pass a FileObject to the
process()
method as it is a method in a standardized interface. So I think
the above
while loop should run inside VFSReader (in
VFSLogFilePatternReceiver) in
which we have the access to the FileObject of the log file. Then we
can get
this working by getting the randomAccessContent of the log file,
inside the
while loop and seeking for the line pointed by the file pointer.
According to the method proposed by Mario on the VFS team, this can
be done
in the following manner.
//This part comes inside the VFSReader class...
long lastFilePointer = 0;
do
{
RadomAccessContent rac = FileObject.getRandomAccessContent()
rac.seek(lastFilePointer)
reader = new InputStreamReader(rac.getInputStream());
process(reader);
lastFilePointer = rac.getFilePointer();
rac.close();
}while (isTailing());
Here, as the while loop is taken out of the process() method,
activateOptions() method in the LogFilePatternReceiver should also be
changed as it calls the process() method.
If this method is okay, I can send the patch with the modifications
mentioned above. Your comments are welcome..
Thanks,
~Isuru
winmail.dat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED] www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
maven dependencies for JULBridge
Ok, I have a local patch that adds a new JULReceiver class plus unit test that works fine if I add the log4j-component Eclipse project as a dependency. Yet, if I remove that project dependency, and add a maven dependency to apache-log4j-component 0.1-SNAPHOT after 'mvn install' that into my local repository, it still compiles, yet the test case doesn't pass, because the Receiver never gets constructed and no event is received. I get DomConfigurator warnings about not recognizing the plugin tags:log4j:WARN Element type "plugin" must be declared.log4j:WARN Continuable parsing error 25 and column 23log4j:WARN The content of element type "log4j:configuration" must match "(renderer*,appender*,(category|logger)*,root?,categoryFactory?)".log4j: Threshold ="null".log4j: Level value for root is [debug].log4j: root level set to DEBUGApr 28, 2007 5:10:44 PM org.apache.log4j.jul.JULReceiverTest testJULReceiverPluginConfigurationINFO: booMy local patch is attached for review. I just don't get it. It's as if the installed component jar in the repo is different than the Eclipse project version, but I've hand removed it from the repo, and redeployed it. I'm using the Maven Eclipse plugin, but even running the tests locally fail, so I don't think it's that. I tried mucking about with the pom.xml by hand.Any ideas? julbridge.patch Description: Binary data
Re: maven dependencies for JULBridge
On 28/04/2007, at 10:16 PM, Curt Arnold wrote: Did you svn update, rebuild and install log4j 1.2.15? The fragment of DTD that shines through in the warnings is prior to the recent changes to log4j 1.2.15. Definitely, several times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven dependencies for JULBridge
On 29/04/2007, at 1:13 PM, Curt Arnold wrote: On Apr 28, 2007, at 4:32 PM, Paul Smith wrote: On 28/04/2007, at 10:16 PM, Curt Arnold wrote: Did you svn update, rebuild and install log4j 1.2.15? The fragment of DTD that shines through in the warnings is prior to the recent changes to log4j 1.2.15. Definitely, several times. I found a bug in component, but I don't think it affected you. Also the Ant build was out of sync. I'm thinking the likely culprit is an Maven built log4j 1.2.15 triggering chaos due to a missing log4j.dtd resource. My suggestions: a) If you built log4j 1.2.15 with Maven, remove it from the repository, build it with Ant and install it using mvn install:install-file (attempt to build the bridge and it will tell you the syntax). The Maven build doesn't include the log4j.dtd, LICENSE, NOTICE and other resources that the Ant build places in the Jar. I've been doing this in the 1.2 source treee for the last week or so, to keep my local maven repo up2date with the 1.2.15 ant clean jar mvn install:install-file -DgroupId=log4j -DartifactId=log4j - Dversion=1.2.15 -Dpackaging=jar -Dfile=/workspace/log4j12/dist/lib/ log4j-1.2.15.jar b) svn update component and mvn install c) Try to run the tests again on a fresh checkout. If the test fails under Maven, try the ant build. If eclipse and ant pass and maven fails, then we should take take it to [EMAIL PROTECTED] I would suggest before doing that downloading and installing a Gump built log4j 1.2.15 and trying the process again. It would make it easier for any Maven guru debugging the issue to not have to learn how to build log4j. Weird, works with ant, but in Eclipse (maven plugin) and with maven I now get a somewhat different error (see results further below). I now get a NoSuchMethodError: java.lang.NoSuchMethodError: org.apache.log4j.spi.LocationInfo.init (Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/ String;)V at org.apache.logging.julbridge.JULLog4jEventConverter.convert (JULLog4jEventConverter.java:124) at org.apache.logging.julbridge.JULBridgeHandler.publish (JULBridgeHandler.java:49) at java.util.logging.Logger.log(Logger.java:428) at java.util.logging.Logger.doLog(Logger.java:450) at java.util.logging.Logger.log(Logger.java:473) at java.util.logging.Logger.info(Logger.java:992) at org.apache.log4j.jul.JULReceiverTest.testJULReceiverPluginConfiguration( JULReceiverTest.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... What's interesting is that if I blow away the log4j section of my local maven repo, then install the 1.2.15 jar into the repo, when I run 'mvn test' inside the JULI bridge, I see this: Paul-Smiths-Computer:/workspace/juli-log4j-bridge paulsmith$ mvn test [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - org.apache.logging:apache-juli-log4j- bridge:jar:0.1.0 [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/log4j/log4j/1.2.15/ log4j-1.2.15.pom Downloading: http://repo1.maven.org/maven2/log4j/log4j/1.2.14/ log4j-1.2.14.pom 2K downloaded [INFO] [compiler:compile] . It seems to want to download the 1.2.14 stuff, but I can't see why exactly. How was the build.xml generated? Is the build.xml file generated from maven? I'm going to commit my local change for now and try the maven list. [ant test versus mvn test] Paul-Smiths-Computer:/workspace/juli-log4j-bridge paulsmith$ ant test Buildfile: build.xml init: compile: test-compile: test: [junit] Running org.apache.log4j.jul.JULReceiverTest [junit] Testsuite: org.apache.log4j.jul.JULReceiverTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.641 sec [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.641 sec [junit] - Standard Output --- [junit] log4j: Threshold =null. [junit] log4j: Pushing plugin on to the object stack. [junit] log4j: Level value for root is [debug]. [junit] log4j: root level set to DEBUG [junit] - --- [junit] [junit] Testcase: testJULReceiverPluginConfiguration took 0.629 sec [junit] Running org.apache.logging.julbridge.JULLog4jBridgeTest [junit] Testsuite: org.apache.logging.julbridge.JULLog4jBridgeTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.128 sec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.128 sec [junit] [junit] Testcase: testBridgeJULLogger took 0.119 sec [junit] Testcase: testLocationInfo took 0.001 sec [junit] Testcase
Re: svn commit: r533461 - in /logging/sandbox/juli-to-log4j-bridge/src: main/java/org/apache/log4j/ main/java/org/apache/log4j/jul/ test/java/org/apache/log4j/ test/java/org/apache/log4j/jul/ test/res
Missing ASF headers on two of the java files. Thanks, I've added a local Eclipse code template snippet to auto add that to each new file. I wish there was some jalopy-style maven thingy to automatically put it there. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layout experiment in sandbox
Only comment I can think of after looking at the code is that the sub- layout elements (logger, priority, messageLayout etc) don't quite make senses to me as 'layout's. they are really LayoutElements rather than a complete layout, but given one _might_ want to simply have a layout of only one element, your approach does mean you could use a low-level layout. It's just the names of the classes I guess. Any reason to choose LogRecord as the name of the interface rather than come up with a distinct name that doesn't use something from the jul framework? (there's no reason to use log4j LoggingEvent either). Paul On 29/04/2007, at 5:45 AM, Curt Arnold wrote: I've committed an initial dump of a rework of the apache-log4j- pattern-layout project into a log4j 2.0 design experiment. The code is not currently functional, but does compile. All the new stuff is in the org.apache.logging and derived packages. org.apache.log4j.* sources should be identical to the pattern-layout project and similar to the log4j 1.3 source. Package layout is very preliminary. Highlights: Two-phase pipeline on layouts: an initial value extraction step that would occur on the same thread as the logging request and a subsequent render step that could be deferred. The idea is that asynchronous appenders would be implemented by extracting the data that would be later rendered and not try to preserve the entire state of the logging event even if much of it is not used. Attribute based declaration of thread safety: @Immutable and @ThreadSafe are used to declare thread-safety. If things are naturally thread-safe, they should declare it and the configuration code may optimize based on it. If code needs thread-safety, then it can check for the presence of the attributes and if not there, externally synchronize the object (see o.a.logging.core.impl.SynchronizedLayout for example). Parameterized layouts: Layouts can be parameterized for different destination types. The most common would be a LayoutAppendable which would be the closest analog to org.apache.log4j.Layout. Other layouts may be LayoutByteBuffer for binary layouts or Layoutorg.xml.sax.ContentHandler for XML layouts. All the composting, threading and extracting stuff is generic for layouts regardless of their destination type. Opaque context: The context of the logging call is provided by a distinct context object which is should have value semantics. The nature of the context beyond that is very open ended. The log4j 1.2 LoggingEvent wrapper exposes the NDC and MDC through the context object. The j.u.l wrapper doesn't provide a context object. Advanced logging API's could introduce any fancy thing (per thread, per connection, per user etc) they would like (they would just need to add the corresponding layouts that interpret it at the back end). Context may be constant across a large number of logging requests, so keeping the context as a distinct value object just seems right. Localization: I've tried to preserve all the localization capabilities of j.u.l at hopefully little cost when they are not used. Object messaging: The message is still a plain Object, not a string. Stock layouts will likely convert it to a string during the extraction phase, but you could provide your own layout that does special handling if it is safe for deferred processing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
Re: Layout experiment in sandbox
Probably should be renamed since it did get annoying when both were in scope. It would also be good to avoid conflict with LoggingEvent, so the obvious choices are LoggingRecord and LogEvent. I'd prefer LoggingRecord. I think it is probably best to choose an existing jul name for methods since the Java naming cops likely did a pretty through review and we can link to the platform Javadoc for elaboration when the concepts are identical. While I agree that Sun probably has done a few good things, I wouldn't necessarily automatically defer to their naming convention. Lets face it, they _still_ have the 'thing' that is called a Java bug database, one of the most appalling tools I've ever had the mispleasure to use. They, like everyone else, can do dumb things from time to time (why is java.util.logging.Handler a class and not an interface for example?) So, if a name does feel good, I'm happy to use their names, however I wouldn't want to blanket borrow from them. I don't mind LogEvent personally, but LoggingRecord isn't too bad either. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw log4j 1.2 status
o.a.l.db.DBAppender and o.a.l.varia.ListModelAppender are in apache- log4j-receivers though maybe that is not the best place and likely not tested. DBAppender probably needs to be moved into either the 1.2 branch with the other appenders, or into a new optional appenders module. The following packages and classes have not been ported: o.a.l.multiplex I think we can pretty much drop the above. I started work on that, but it got messy very quickly. I don't this we should do anything for 1.2 here. o.a.l.net.MulticastAppender o.a.l.net.UDPAppender o.a.l.varia.ListAppender o.a.l.varia.SoundAppender I'm not that familiar with these appenders. If you have suggestions on how to organize them, I can set up the projects. The first 2 are pretty important to some folks, and if we have the matching Receiver, then that's no use without the appender. The other 2 are useful utility functions for GUI based apps. I'd say if we decide to have a optional-appenders module, they could go in there. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JULBridge and Receivers module
I began to do a local working copy svn move from the JUL bridge into the log4j-receivers module. But then I stopped, because the JUL bridge requires JDK1.4, and I didn't want to pollute the receivers module with that dependency just yet. I'll instead work towards making the bridge contain a plugin class. thoughts? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JULi bridge log4j Configurator
I'd like to propose that in 1.2.15 we allow the Configurator classes to recognize support for the juli-log4j bridge. For example: log4j.xml: log4j:configuration debug=false threshold=debug assimilateJUL=true ... log4j.properties: log4j.assimilateJUL=true If set, the Configurator classes check if the juli-bridge classes are available, and invoke the appropriate method on the JuliLog4jBridge class. If classes are not present, then an ERROR level LogLog can be output. Should be easy to do? This would enable component writers to use JUL logging directly rather than use JCL or other frameworks, and let the integrator use the bridge. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn site generation error (I'm still learning)
On 25/04/2007, at 4:08 PM, Curt Arnold wrote:
I just saw this show up on previously working pom's this
afternoon. Removing the ${reports} will eliminate the error but
mess up the index.html page. I'm guessing this is due to
something gone terribly wrong on a component upgrade in Maven, but
I haven't checked out their lists yet.
Nothing obvious on their list traffic or jira. I posted a question
on [EMAIL PROTECTED] I checked the documentation and it was
supposed to be ${ reports} instead of {$reports} and I have again
let CR's instead of LF's into a file, but neither had previously
caused a problem and fixing them didn't make the problem go away.
Will wait to hear what the Maven gurus have to say.
Thanks Curt.
Re: CR/LF's. I think there's some svn repository setting that allows
one to automatically configure appropriate line endings:
http://trac.lighttpd.net/trac/wiki/Devel/Subversion
(see bottom section)
I haven't tried it yet myself though, we have exactly the same battle
where I work as we have a mixed Linux/OSX/W32 dev environment, and
XML and other files often end up quite confused. It makes diffs much
harder. I wonder whether we should try that?
Paul
Re: JULi bridge log4j Configurator
To take messages from java.util.logging and dispatch them into log4j would require some key to signify the appender should work in reverse. Don't have a great name for it, but import might work. Receiver? :) !-- takes java.util.logging events and calls log4j -- appender class=org.apache.log4j.julibridge.JULIAppender param name=import value=true/ /appender I was putting log4j related sandbox projects under .../logging/ sandbox/log4j. Since the sandbox is likely only a temporary home, I don't see any need to move it. I'm not sure about JULI. Seems a little cute. SLF4J calls it JDK14. I think calling the project logging-log4j-bridge, using the package org.apache.log4j.bridge and the class JDK14Appender would be better. For some reason I always thought people referred to java.util.logging as JULI, but maybe I've just had it wrong. Easy to change the names though. I'd be less keen on adding support to bridge the other way around. We're trying to help people who want to use log4j, rather than those who want to use java.util.logging stuff. As per how this gets configured, the approach to make it configure based on being a Renderer/Appender might work, but that's even hackier than my original hack idea to have some reflective based code that can detect the companion code and use it. Obviously this is a 'plugin', so perhaps some combination of the component stuff with this might work. For now though, if users do want to use it, it's only 1 line of code, post log4j configuration, so perhaps we simply leave it for now until we've bedded down the component receiver stuff for log4j 1.2 Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JULi bridge log4j Configurator
On reflection, it does seem like the bridge from JULI to log4j seems conceptually similar to the existing receivers and a bridge from log4j to JULI really seems like a appender. I'm thinking that JULI-log4j bridge should join the other receivers in apache- logging-receivers. If there is a log4j-JULI bridge it would be a distinct custom appender project. Yep, that makes sense. I can merge the module into the log4j- receivers module. I can add a Plugin that does the 'assimilation' so that it can be used in the configuration via the standard plugin mechanism. I'm going to first go back to Chainsaw and work out any problematic plugin or LoggingEvent problems, and if the component/ receivers module is working well inside Chainsaw, that will give me some confidence to move the bridge into receivers. On the naming front, I've now realised where I got JULI from. It's not quite java.util.logging, but something the Tomcat team come up with. I'll need to do some renaming. Thanks for fixing the site.xml stuff, site generation seems to be working now locally. I'm taking that the approach you're aiming at is such that at some point a 'mvn deploy' style command will build the distribution and site and auto-upload everything to the repository automatically? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw log4j 1.2 status
On 22/04/2007, at 3:21 PM, Paul Smith wrote:
I've committed a PluginConfigurator to both the component and
log4j 1.3 and copied the LoggerRepositoryExImpl over to log4j 1.3.
Thanks, I'll give that a crack and see what we get.
Success!
With the below diff, I am able to use the same configuration file
we'd been using internally to attach to our QA box via
SocketHubAppender/Receiver. This is using the latest 1.2.15 +
component+receiver+expression-filter modules.
On top of that, I see lovely juicy MDC values appearing as new
columns in Chainsaw. w00t.
Scott, what else do you think we need to consider before deciding on
whether we bind Chainsaw to log4j 1.2 permanently (if at all)?
Index: src/java/org/apache/log4j/chainsaw/LogUI.java
===
--- src/java/org/apache/log4j/chainsaw/LogUI.java (revision
532553)
+++ src/java/org/apache/log4j/chainsaw/LogUI.java (working copy)
@@ -53,6 +53,7 @@
import java.util.List;
import java.util.Map;
import java.util.Set;
+
import javax.swing.AbstractAction;
import javax.swing.Action;
import javax.swing.BorderFactory;
@@ -83,10 +84,12 @@
import javax.swing.event.EventListenerList;
import javax.swing.event.HyperlinkEvent;
import javax.swing.event.HyperlinkListener;
+
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.LogManager;
import org.apache.log4j.Logger;
+import org.apache.log4j.LoggerRepositoryExImpl;
import org.apache.log4j.chainsaw.dnd.FileDnDTarget;
import org.apache.log4j.chainsaw.help.HelpManager;
import org.apache.log4j.chainsaw.help.Tutorial;
@@ -104,7 +107,6 @@
import org.apache.log4j.chainsaw.receivers.ReceiversPanel;
import org.apache.log4j.chainsaw.version.VersionManager;
import org.apache.log4j.helpers.Constants;
-import org.apache.log4j.joran.JoranConfigurator;
import org.apache.log4j.net.SocketNodeEventListener;
import org.apache.log4j.plugins.Plugin;
import org.apache.log4j.plugins.PluginEvent;
@@ -114,9 +116,12 @@
import org.apache.log4j.rule.ExpressionRule;
import org.apache.log4j.rule.Rule;
import org.apache.log4j.spi.Decoder;
-import org.apache.log4j.spi.LoggingEvent;
import org.apache.log4j.spi.LoggerRepository;
import org.apache.log4j.spi.LoggerRepositoryEx;
+import org.apache.log4j.spi.LoggingEvent;
+import org.apache.log4j.spi.RepositorySelector;
+import org.apache.log4j.xml.DOMConfigurator;
+import org.apache.log4j.xml.PluginConfigurator;
import org.apache.log4j.xml.XMLDecoder;
@@ -190,6 +195,10 @@
*/
private EventListenerList shutdownListenerList = new
EventListenerList();
private WelcomePanel welcomePanel;
+
+ private static final Object repositorySelectorGuard = new Object();
+ private static final LoggerRepositoryExImpl repositoryExImpl = new
LoggerRepositoryExImpl(LogManager.getLoggerRepository());
+
private PluginRegistry pluginRegistry;
/**
@@ -245,9 +254,19 @@
* @param args
*/
public static void main(String[] args) {
+
if(OSXIntegration.IS_OSX) {
System.setProperty(apple.laf.useScreenMenuBar, true);
}
+
+
+LogManager.setRepositorySelector(new RepositorySelector() {
+
+public LoggerRepository getLoggerRepository() {
+return repositoryExImpl;
+}}, repositorySelectorGuard);
+
+
ApplicationPreferenceModel model = new
ApplicationPreferenceModel();
SettingsManager.getInstance().configure(new
ApplicationPreferenceModelSaver(model));
@@ -298,6 +317,7 @@
showSplash(logUI);
}
logUI.cyclicBufferSize = model.getCyclicBufferSize();
+logUI.pluginRegistry = repositoryExImpl.getPluginRegistry();
logUI.handler = new ChainsawAppenderHandler();
logUI.handler.addEventBatchListener(logUI.new
NewTabEventBatchReceiver());
@@ -1889,8 +1909,7 @@
try {
// we temporarily swap the TCCL so that plugins can
find resources
Thread.currentThread().setContextClassLoader
(classLoader);
- JoranConfigurator jc = new JoranConfigurator();
- jc.doConfigure(url, LogManager.getLoggerRepository());
+ PluginConfigurator.configure(url);
}finally{
// now switch it back...
Thread.currentThread().setContextClassLoader
(previousTCCL);
Index: src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
===
--- src/java/org/apache/log4j/chainsaw/layout/
EventDetailLayout.java(revision 532553)
+++ src/java/org/apache/log4j/chainsaw/layout/
EventDetailLayout.java(working copy)
@@ -191,16 +191,15 @@
li = formatLocationInfo(event);
}
Hashtable properties = formatProperties(event);
-LoggingEvent copy = new LoggingEvent();
-copy.setLogger(logger);
-copy.setTimeStamp(event.getTimeStamp());
-copy.setLevel(event.getLevel());
-copy.setThreadName(threadName
Re: Chainsaw log4j 1.2 status
On 26/04/2007, at 11:00 AM, Scott Deboy wrote: Full speed ahead! You mean we may get an official release out the door with Chainsaw? I started it when my first child was born. He's 4 now! (and I have 2 others) You're well on your way to breading an extended log4j-dev team then! What I'll do is whip up a bundle of deployments, and set them up alongside the current releases. I can do a webstart and zip bundle, and provide the links so that others can help with a QA cycle to truly verify we haven't done something wacky. If that passes, then we can vote on updating the current 'release' for mainstream users. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2 and maven pom.xml
Sorry about the line-endings, hopefully I did better this time. I was able to simplify the dependencies so that only one file (jmxtools) needs to be manually downloaded and installed to build log4j 1.2 on Java SE 5. I added explicit specifications to target Java 1.3 or later and only accept Java 1.3 language features. I specified the working directory for the unit tests which allowed things to get started, but there are a decent number of failures. Some are due to the tests not stripping out Maven's entries in the stack traces. I cut and pasted some of the site reporting code from one of the plugins. I thought, but refrained, from copying over src/site and src/changes from one of the other projects, but I am pretty tempted to make a shot at moving to a Maven generated site and documentation. I can't remember what exactly used to be the case, but was the log4j 1.2 tree supposed to work on JDK 1.1+ I noticed just as you posted that the new constructor in LoggingEvent takes a java.util.Map, which was introduced in JDK 1.2. I just wouldn't want us to completely break down compatibility. But perhaps that already happened before? I dunno. I can't see too many people being effected by this, but it's something to keep in mind. As per the site management, whatever makes our life easier, I can start to see the benefit in putting a little Maven-effort into things, over the long haul I think it does pay off. There was nothing really wrong with the old way; slightly more manual, but given Maven is starting to get more and more traction across Apache projects I can't see why not. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposed patch to LocationInfo in 1.2.15
A new constructor was added to LocationInfo for 1.2.15, but it
doesn't quite work properly. The other get*() methods use the
fullInfo field to calculate values, but the new constructor
effectively sets them.
I'm proposing the following diff:
Index: src/java/org/apache/log4j/spi/LocationInfo.java
===
--- src/java/org/apache/log4j/spi/LocationInfo.java (revision
531299)
+++ src/java/org/apache/log4j/spi/LocationInfo.java (working copy)
@@ -179,6 +179,8 @@
*/
public
String getClassName() {
+if(className != null ) return className;
+
if(fullInfo == null) return NA;
if(className == null) {
// Starting the search from '(' is safer because there is
@@ -219,6 +221,8 @@
*/
public
String getFileName() {
+if(fileName !=null) return fileName;
+
if(fullInfo == null) return NA;
if(fileName == null) {
@@ -240,6 +244,8 @@
*/
public
String getLineNumber() {
+if(lineNumber !=null ) return lineNumber;
+
if(fullInfo == null) return NA;
if(lineNumber == null) {
@@ -258,6 +264,8 @@
*/
public
String getMethodName() {
+if( methodName !=null ) return methodName;
+
if(fullInfo == null) return NA;
if(methodName == null) {
int iend = fullInfo.lastIndexOf('(');
This will then give the juli-log4j bridge complete LocationInfo
support (other than java.util.logging not supporting the line # and
source file data AFAIK)
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2 and maven pom.xml
Wasn't intentional, but I don't think we need to change it (at least at the moment). The LoggingEvent methods (getProperties, getPropertyKeySet) copied over from log4j 1.3 already used Map and Set, so it would not be possible to compile on JDK 1.1 without changing the return types, but the 1.1 and 1.2 javac's haven't been able to compile log4j for a long time due to compiler bugs.I don't think that you'd get a ClassNotFoundException unless you called one of these methods and they aren't used internally within log4j 1.2, so it should not affect any hypothetical JDK 1.1 user. It does look like the new implementation of AsyncAppender (since 1.2.14) uses ArrayList and HashMap in its implementation would not work on JDK 1.1 where the older implementation might have. Nobody has reported it. The JDK 1.2 classes could be replaced with JDK 1.1 equivalents without changing the signature. The only viable JDK 1.1 compatible environment is Microsoft Visual J# and maybe it would be good to see where we are with that. I'd suspect that you'd have to stub a lot of things out since I'm guessing that javamail, JMS and the like aren't available for Visual J#. If you were using Visual J#, you could use log4net. I'm honestly open to having 1.2.14+ require JDK 1.2 and above. As long as we are open about it in the release notes. There are previous releases, just as stable and useful (geez, I was using 1.2.8 for absolutely years without ever needing to upgrade). Anyone who is stuck in JDK1.1 land has far bigger issues than log4j I'd imagine... Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn site generation error (I'm still learning)
Was interested in seeing exactly what happens during a mvn site run.
I tried it on the juli-bridge project after you added lots of juicy
details to the pom.
But I get this error:
[WARNING] Error loading report org.apache.maven.plugin.jxr.JxrReport
- AbstractMethodError: canGenerateReport()
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position:
TEXT seen ...http://logging.apache.org/log4j/companions/\r/
links\r{m... @1:1339)
I gazed at the site.xml file, but it looks fine to me. I don't get it.
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
juli-log4j bridge
I've committed a new sandbox module that (tries) to bridge the gap between java.util.logging and log4j. it's not 100% perfect yet, but getting there. Comments appreciated. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.15 proposed bugs to address
On 22/04/2007, at 5:00 PM, Curt Arnold wrote: On Apr 21, 2007, at 10:40 PM, Paul Smith wrote: While sitting in a day spa cafe while my wife got some much needed pampering, I sat down and reviewed all the open issues in bugzilla and put some thought towards each of them, and where they might sit. What follows is my analysis of what might be worth considering tackling in a 1.2.15 release on top of what is already there (I actually need to review the diffs between .14 and current status too), or as a 1.2.16 release. Be good if we could review and agree/ change this list and then work towards a release. These are bugs, not enhancements. I'll put a separate email together with some thought on some 1.2 work we might want to consider post 1.2.15 that should be achievable and add value to the community. 1.2.1[56] Potential bug fixes == Bug 30588 - log4j cannot parse stacktraces from JRockit simple fix Looked at this one last night. The change seems innocuous but that is supposing there isn't yet another VM that works with the current implementation and fails with the suggested. At least before committing this, I think that we'd have to check the unit tests pass on JRockit with the fix. Better yet, check it on some set of implementations. Anybody want to throw out a list of VM's that should be checked (better all run on Intel on either Mac OS, Linux or Windows for me to help). We could defend against that by only using a different algorithm when the underlying JVM version is JRockit, and use the standard algorithm for other VM's, or do you think that's getting hacky? A system property read on class init to detect jrockit-ness? Bug 37736 - LoggerEventListener's appenderRemovedEvent() and levelChangedEvent() methods are never called this is, according to the bug report, both 1.2 and 1.3 related (see below). Worth investigating. I'm thinking that it is 1.3 specific as LoggingEventListener doesn't exist in log4j 1.2. Fair point, if that listener interface isn't in 1.2, we could just consider it for 1.3 changes. Bug 17531 - PropertyConfigurator.configureAndWatch() don't reset the configuration some work done in trunk, is it worth reviewing for a port? I'd be concerned that this is a change of behavior that would break someone who depended on the old interpretation. I think that log4j 1.3 added an explicit reset property so that you could explicitly request a reset before reconfiguring. Yes, could go either way, we could defer this one for later 1.2.x, if at all. On the whole though, happy with that set as a target for the next release? I'd like to finalise a maven pom.xml for the 1.2 branch as well. We shouldn't need to move the repo around, I think there's a pom setting element to define the source folders. I'm also getting my gpg setup as well, so we can have a few more people capable of signing the releases. Only yourself and Mark have your stuff in the KEYS file. Once I get my head around it, do I simply append my signature to that file? I'm gathering I won't get my signature signed into the Web of Trust for a while, given I'm Down Under. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
