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: Wedding plans
Congratulations Curt, best wishes for you and Julie. Remember to concentrate on enjoying the wedding day, because it goes by in a flash (the organization before hand though may feel like eternity... :) I remember being up till 2am discussing font sizes for the wedding invitations...) cheers, Paul On 23/12/2008, at 8:33 AM, Curt Arnold wrote: Sorry about being a little slow to respond recently, but I've been working on wedding plans. Julie Ferguson and I are marrying in New Braunfels, TX on December 27th. Julie and I have known each other a little over 6 years as friends and we kept in touch infrequently after she moved away from Houston. I dropped her my bi-annual "how are you doing email" a few months ago and it snowballed in to longer and longer emails, then phone calls and then face to face. Things have gone too well for it to be either of our doing. I do not expect to be checking the mailing lists frequently until January 4th or so. We would appreciate your prayers as we build our marriage. Our blog: http://curtandjulie.blogspot.com Registered at Amazon (http://tinyurl.com/curtjulie) and Sur La Table (http://giftreg.surlatable.com). - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org 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: psm...@aconex.com 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: [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
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]
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 - 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 {
+priva
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: 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
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: plain log4j trunk - "mvn install" fails
The only thing I had to do was to delete the jmx reference in pom.xml as this is present in the JDK. Then it built and installed without a hinch (except it took 11 minutes). That 11 minutes will be all the Maven artifacts being downloaded (almost nothing to do with log4j - only a handful of artifacts to get). Having a local Archiva or Nexus proxy close by makes it much much faster! :) (especially for us folks downunder). 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]
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: 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 was trying to preserve the external behavior that would occur
with the old code if you did not provide jmxtools.jar at runtime.
As implemented, both the new code and the old code would result in
a NoClassDefFoundError if it was deployed without jmxtools.jar.
However, the likelihood that some client code out there has
something like:
try {
new Agent().start();
} catch (NoClassDefFoundError ex) {
}
is vanishingly small, so switching to a RuntimeException is not a
big issue to me. I'd prefer not to revert the whole change, but
to change the Error constructors to RuntimeException constructors
which I'll do and see what you think.
Yes, thanks, although I _wish_ we could use this slightly different
pattern instead (as I'm sure you probably agree):
throw new RuntimeException("Failure starting... ", e);
except it needs 1.4 source compatibility. *sigh*. bummer.
One other note on the commit, I notice the addition of JavaDoc
comments on things like no-arg constructors. I'm -0 on adding
JavaDoc that adds no value at all ("create new instance"), that
really gets under my goat here at work it just seems pointless, a
waste of effort and makes the code actually harder to read if you ask
me. Simple clean code that is self-explanatory should be the goal IMHO.
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=682879&view=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=682879&r1=682878&r2=682879&view=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=682879&r1=682878&r2=682879&view=diff
===
===
===
=
--- logging/log4j/trunk/build.xml (original)
+++ logging/log4j/trunk/build.xml Tue Aug 5 12:16:07 2008
@@ -32,7 +32,6 @@
-
@@ -120,7 +119,6 @@
-
@@ -169,7 +167,6 @@
classname="com.sun.jdmk.comm.HtmlAdaptorServer">
-
Modified: logging/log4j/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/pom.xml?rev=682879&r1=682878&r2=682879&view=diff
===
===
===
=
--- logging/log4j/trunk/pom.xml (original)
+++ logging/log4j/trunk/pom.xml Tue Aug 5 12:16:07 2008
@@ -407,12 +407,6 @@
true
- com.sun.jdmk
- jmxtools
- 1.2.1
- true
-
-
com.sun.jmx
jmxri
1.2.1
Modified: logging/log4j/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/src/changes/changes.xml?rev=682879&r1=682878&r2=682879&view=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 @@
Make javamail, jmx, jms
dependencies optional in pom.xml.
SocketHubAppender should
expose actual port in use to extending classes.
SocketHubAppender in the
1.2.16 does not support a scroll back buffer or application
property
- Give log4j threads
reasonable names/
+ Give log4j threads
reasonable names.
LocationInfo can report
wrong caller when other class names contain logger class name as
substring.
+ ErrorHandlerTestCase is
not run and does not pass.
+ Agent.java is sole
dependency on jmxtools.jar with Java 5+.
description="SyslogAppender enhancements, NTEventLogAppender and
Maven build.">
Modified: logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/
Agent.java
URL:
http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/Agent.java?rev=682879&r1=682878&r2=682879&view=diff
===
===
===
=
--- logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/
Agent.java (original)
+++ logging/log4j/trunk/src/main/java/org/apache/log4j/jmx/
Agent.java Tue Aug 5 12:16:07 2008
@@ -20,24 +20,84 @@
import javax.management.ObjectName;
import javax.management.MBeanServer;
import javax.management.MBeanServerFactory;
-import com.sun.jdmk.comm.HtmlAdaptorServer;
import org.apache.log4j.Logger;
+import java.lang.reflect.InvocationTargetException;
+
+/**
+ * Manages an instance of com.sun.jdmk.comm.HtmlAdapterServer which
+ * was provided for demonstration purposes in the
+ * Java Management Extensions Reference Implementation 1.2.1.
+ * This class is provided to maintain compatibility with earlier
+ * versions of log4j and use in new code is discouraged.
+ *
+ * @deprecated
+ */
public class Agent {
+/**
+ * Diagnostic logger.
+ * @deprecated
+ */
static Logger log = Logger.getLogger(Agent.class);
+/**
+ * Create new instance.
+ */
public Agent() {
}
+/**
+ * Creates a new instance of com.sun.jdmk.comm.HtmlAdapte
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]
Optional command line onfiguration URL for Chainsaw
I'm considering adding a dependency to Commons-cli to allow Chainsaw start script to have some startup options, the driving force being to allow one to configure a Receiver configuration file to pass to it. This would mean one could configure an automatic URL via the preferences as we can do now, but allow a specific one to be chosen to replace it on the command line. This could be further extended to allow basic "adhoc" receiver startups. So I'm proposing something like: -c or -s ,,... -- Start SocketReceiver connected to listed hosts:ports (default port could be assumed) -h ,,... -- Start SocketHubReceiver These would fill my direct needs. Scott, you may have some suggestions for logical arguments for the other Receivers? cheers, 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: 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]
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: 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?
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?
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-tabpanel&focusedCommentId=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]
[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-tabpanel&focusedCommentId=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]
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=12607124#action_12607124 ] Paul Smith commented on LOG4J2-9: - We should consider Spring as part of this configuration too. I don't have anything off the top of my head in mind here,but since Spring is such a rich configuration environment we should probably not ignore how log4j may fit into a Spring environment. > 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]
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
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
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
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
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?
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: 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.
[PROPOSAL] SocketHubAppender change - allow auto port choice
I'd like to propose a change to SocketHubAppender code to allow it automatically choose a free port on the local host if the Port property is configured with 0.This will allow the Zeroconf module to be more useful, and allow simpler configuration for multiple applications on the same host. We have an open feature request (see [1]) to allow this, and the only simple way I can get this to work is to change SocketHubAppender (see attached patch).In summary, I've moved the ServerSocket initialisation from the ServerMonitor.run() method to the ServerMonitor constructor, and when Port=0, check what port is actually configured, and modify the parent SocketHubAppender instance port variable so that getPort() exposes the real port in use.Sub-classes can then inspect that property after the call to super.activateOptions(). This allows ZeroconfSocketHubAppender to broadcast the correct port in use (it would have broadcast 0 without this change; not very useful).This doesn't appear to break any of the log4j unit tests, and I've added unit tests to the Zeroconf module (see second patch) that confirm behaviour. I've also made the Zeroconf module aware of the fact that it might not be using an appropriate log4j version, given that this feature would/might only be present in log4j 1.2.16. Prior versions of log4j will work fine still, but the automatic port configuration won't work (it throws an UnsupportedOperationException if it detects this).cheers,Paul[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=43295 log4j_sockethubappender.patch Description: Binary data log4j_zeroconf.patch Description: Binary data
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: 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: 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]
latest log4j trunk mvn test failures
Right now, with svn updated in log4j/trunk, a 'mvn clean install' fails: ... [junit] Testcase: testProblemCharacters took 0.016 sec [junit] Testcase: testNDCWithCDATA took 0.008 sec [junit] FAILED [junit] expected:<...> but was:&"' ...> [junit] junit.framework.ComparisonFailure: expected:<...> but was:&"' ...> [junit] at org.apache.log4j.xml.XMLLayoutTest.testNDCWithCDATA (XMLLayoutTest.java:456) [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error executing ant tasks Embedded error: The following error occurred while executing this line: /workspace/log4j/tests/build.xml:186: Test org.apache.log4j.CoreTestSuite failed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug list survey
I don't know what possessed me, but I think I've reviewed all the open log4j bugs today and fixed several of them. I didn't see any of the other ones that seemed ready for log4j 1.2.15. The big clusters of bugs seemed to be: Unless someone wants to lobby for a particular bug, I think I'm going to let Gump do a nightly build and cut another release candidate tomorrow and call a vote. Excellent work, thanks muchly for your efforts. Looking forward to getting this release out! Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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
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: svn commit: r564112 - /logging/chainsaw/trunk/src/main/java/org/apache/log4j/chainsaw/vfs/VFSLogFilePatternReceiver.java
To tail via VFS, a version of commons-vfs is required which provides the fileobject.refresh method (added Mar 30 19:16:24 2006) According to the Commons-VFS Java API docs, this method is available in the 1.0 release, so I think that's ok from a Maven point of view. Did you have any problems with the maven stuff? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML layout
On 09/08/2007, at 3:01 AM, Curt Arnold wrote: I'd propose: 1. Adding support for properties to XMLLayout, but have it be disabled by default. Extra elements showing up in content may disrupt existing applications that consume output from XMLLayout and shouldn't just appear in a minor release. +1 2. Reviewing the holes in XMLLayout and fixing low-risk items. Basically, items that currently produce invalid XML and can be fixed without major surgery. +0 I can't really comment on this one because I don't really understand the bugs themselves. Seems reasonable to fix them to make it valid XML. 3. Adding XSLTLayout to extras. That would be an alternative if you are encountering problems with the log4j XMLLayout, plus it would allow output in other formats (such as Atom or RSS) just by adding an appropriate transform in the configuration. XSLTLayout requires a JDK 1.4, but that shouldn't be an issues with extras. +1 Perhaps deprecate the older XMLLayout as well? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pinpoint is now an Apache Labs project
I've created a new Apache Lab project to hold the 'Pinpoint' concept I mentioned a while back. http://svn.apache.org/repos/asf/labs/pinpoint/trunk/ It's not really close to prime time use yet; I mean even I can't use it yet, but the concept is fleshing out nicely. The eventual goal is to provide a service that can index events using Receivers and a capable CLI and web interface to search/navigate said event 'contexts'. If anyone is interested in feel free to discuss on this or the labs mailing list. cheers, Paul Smith
Re: XML layout
On 08/08/2007, at 7:22 AM, Curt Arnold wrote: The log4j 1.2 layout can produce non well formed content for some atypical content (a message with an embedded -->, threads containing & or >, etc). Plus it does not output MDC content (log4j 1.3 does, but shares the other shortcomings). I've been tempted to overhaul it but am hesitant to break code that might have compensated for its idiosyncracies. My current thought is to add an XsltAppender to the extras companion that uses the xslt support added in idk 1.4. If no transform is provided, a default transform that results in a format compatible with the current output but done right. If you wanted some other format, you could embed the xslt transform if you were using log4j 1.2.15 or higher or the replacement configurator in the extras companion. Hmm, this is a tough one. If we think (and I don't know myself, I don't use XMLLayout at all) that these are really bugs, then we should feel free to address them and note in the release notes that this might be an incompatible change if people have relied on that odd behavior. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rename log4j trunk?
+1 Can we 'svn move' trunk -> branches/BRANCH_1_3_ABANDONED ? Then svn mv branches/log4j_12 > trunk? 1.3 has only ever had alpha releases. It's just a change management issue we'll have to live with. lets roll. Paul On 08/08/2007, at 7:32 AM, Curt Arnold wrote: Log4j/trunk is no longer the main development branch. Renaming it log4j/branches/v1_3-branch would eliminate mistaking it for the latest and greatest. It may disrupt someone (we'd address gump as part of the change), but I think they'd eventually have to deal with it. I'm not sure if we should have trunk be a link to 1.2 or abandon it until 2.0 is viable. Thought? - 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
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
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 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: [EMAIL PROTECTED]: Project logging-log4j-chainsaw (in module logging-chainsaw) failed
On 05/07/2007, at 8:02 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project logging-log4j-chainsaw has an issue affecting its community integration. blah blah blah. I was stumped by this for a while. Firstly, there appears to be 2 problems: 1) the zeroconf module didn't appear to be built by gump, at least, I didn't see a notification sent to the log4j-dev list. However, it appears to have tried to run yesterday (5th July 2am PDT) for the 3rd time. I don't know why it didn't email, that would have helped me a lot. Anyway turns out the svn directory I specified was wrong. That's now fixed. 2) I'm not sure if this was a problem or not, but there was some inconsistencies in the naming of the project inside the gump descriptor. I've aligned them all, and hopefully after zeroconf builds this should also build. Gump was complaining that it couldn't find the zeroconf project, but I'm assuming that's because zeroconf has never built successfully. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: Chainsaw harmonization, branding, etc.
I used the assembly:assembly plug to create a distribution, however the descriptor (src/assembly/bin.xml) needs to be tweaked to drop out non-re-distributable jars. Hopefully, all the non-re- distributable jars are not essential to operation, at least not on JDK 1.5. Currently, you can do java -jar on apache-chainsaw.jar and the app launches. I added the main-class and path entries to the chainsaw jar, wouldn't do that on a library jar but hopefully is a good thing for an application jar. I've never found that main-class much use because of the external reference to jars. Personally I like the appassembler distribution that maven can build, plus the Mac-specific one. The external referenced jars are the crux of the problem with Chainsaw. Out-of-the-box, Chainsaw is useful for socket-based operations and local file reading. For JMS, DB, and VFS style operations, the 3rd-party requirements make it a tricky distribution problem. Which exactly are the non-redistributable jars? Xstream and jmdns are the only listed dependencies in the pom, both of which are ASL licensed. JSch (for ssh-based stuff like vfs) used to LGPL but is now BSD licensed, but we don't actually need to depend on that per-se (they can go in the plugins directory). I will probably need to get my head around the distribution mechanisms. I think we do need a classic distribution tarball that is farmed out to the distribution mirrors. Keeping the WebStart is good, but I think it might need to be placed within and use the Maven repo and have the downloads page point to a nearby Maven mirror. 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. Branding is another issue. Should Chainsaw be presented as a separate product or as a log4j companion or some other model. I've probably not been consistent in what I've set up, but here is how I see the options: Chainsaw as a LS product: Web content: http://logging.apache.org/chainsaw, appear as menu item on http://logging.apache.org groupId = apache-chainsaw or log4j artifactId = apache-chainsaw Chainsaw as a log4j companion: Web content: http://logging.apache.org/log4j/companions/chainsaw, appear as menu item on http://logging.apache.org/log4j and http:// logging.apache.org/log4j/1.2 groupId = log4j artifactId = apache-log4j-chainsaw I think that LS product is better since Chainsaw should be usable with the other LS frameworks and is much more complicated than the other companions. Also, the plugin components could be considered "companions" of chainsaw. Given Chainsaw can interact with non-log4j environments as well with XML logging, I think a standalone position is probably more appropriate. I don't have a problem having Chainsaw continue to use the log4j icon, but maybe we could create a derivative icon that suggest taking a slice of the log4j cup. Don't know if we have access to the original drawing for the icon. Scott and I talked about this a while back, but neither of us a gFx artists.. :) I had always envisaged an image that was a piece of paper with text and a chainsaw slicing right through it. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
additional assemblies for Receivers module?
Hi Curt, I have not yet worked out how to do this yet, but I thought I'd mention it before we perform a release of the Receivers module. Chainsaw will need to be shipped with a cut-down version of the receivers package due to Classloading rules. The Receivers that depend on 3rd-party drivers cannot be packaged up with Chainsaw. Those Receivers will need to be downloaded separately by the user together with their driver jars and placed in their local plugins directory. Is there a way with maven assemblies to create: * standard assembly as we have now * receivers-chainsaw - receivers distro without DBReceiver, JMSRecevier or VFSLogFilePatternReceiver * receivers-chainsaw-extras - inverse of receviers-chainsaw (names can obviously be changed) That way Chainsaw can be shipped with receviers-chainsaw, and we can provide a link for the user to download and install the others. I'm actually considering modifying Chainsaw to be able to automatically soak it for them. Is this possible? cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.2.15 and companion release candidates
thanks Curt for the rework of the naming and pom. I did a poor job of copying various files across to that package; my apologise. You've got a keen eye for detail. Paul Online doc: http://logging.apache.org/log4j/companions/zeroconf Doesn't appear visible to me yet. - 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
ated [javac] .getSettingsDirectory(), 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
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
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
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
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
Answers that I'd be looking for: Are the log4j->jul and jul->log4j solutions symmetric: For example, if there is a JULAppender, is there a corresponding Log4jHandler? The original bridge code dealt with jul->log4j only. The new JULAppender code provide by Sagi Mann is the symmetric equivalent. Since the jul-log4j-bridge project requires JDK 1.4 to build, I think it makes sense to add it to this project rather than log4j itself. There is also some code sharing the Receiver and Appender can share in terms of the LevelConverter interfaces. Are the names appropriate? Is the packaging appropriate? Happy to discuss packaging options. I personally like: * org.apache.log4j.jul - for code dealing with log4j<->jul or for log4j specific code. The JULReceiver is the classic example here, that's the package it sits in in the bridge project * org.apache.logging.julbridge - Generic/bridge specific code, mostly dealing with the jul packages (such as the Filter and Handler implementations. There are no log4j related imports in this section, so it's quite isolated. That's what is sitting there now. I'd propose to add the JULAppender class to org.apache.log4j.jul in the bridge project and update the site documentation for the bridge project on how to use it What are the performance issues? I think the only real way to test this is a stress test, but by code inspection it's pretty light. Is anything overly complex? I think you'll find it's actually all quite trivial. Be great if you (and anyone else) could review it. cheers, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.' 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 rec
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.' 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 F
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=rev&rev=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=diff&rev=549610&r1=549609&r2=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. + + + logging.repo + USERNAME for people.apache.org + /home/ubuntu/.ssh/id_rsa + + + + logging.site + USERNAME for people.apache.org + /home/ubuntu/.ssh/id_rsa + + + +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: 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: 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]
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 @@
+
+maven-javadoc-plugin
+
+
+
+jar
+javadoc
+
+
+
+
+
+maven-source-plugin
+
+
+
+jar
+
+
+
+
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
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]
jul-log4j-bridge distribution test
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
Re: pinpoint - a proposed companion to log4j
If this was a project proposal, I'd have no issue with you starting a sandbox project and allow it to develop out in the open. However, based on your discussion it appears to be pretty far along and it looks like it should be at least reviewed by the Incubator PMC before going into Logging Services. I'd suggest putting it in Apache Labs. If it gains traction in the Labs, then we can migrate it over to LS with appropriate Incubator PMC oversight. "Far along" is probably a stretch... :) the basic project structure is there, and the ability to perform extremely basic operations as proof of concept. It's no where near ready for production usage as yet. What I could is put a tar ball of the project available for review, and then people can comment on what we should do with it: http://people.apache.org/~psmith/pinpoint.1.0.0.5.tar.gz I'll check up on the Apache Labs process in the mean time just so I know what might be coming. cheers, Paul
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 pinpoint>search 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
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] - 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. - 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
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] - 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]
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]
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.
Re: ERFATestCase failure on Ubuntu, might need iptables help
I've found in 'nix machines that some socket openings mixup the localhost vs real IP address ethernet interfaces. The ERFA might be listening on one, but the testcase tries to contact it on the other? I usually confirm this by doing something like (depends on which unix you have): netstat -anp | fgrep LISTEN this will show you which processes and ports have socket listeners, and it can tell you which interface is being used. I think the 'null' parameter is saying use the 'wildcard' address, which I've found can lead to weirdness on unix machines, particularly those that have multiple eth interfaces. In some cases, I've had to work around this by changing the /etc/hosts file so that 'localhost' maps to the real IP address, and not the 127.0.0.1. Not ideal, but it does seem to fix it. On 07/06/2007, at 1:56 AM, Curt Arnold wrote: I've been experimenting with Ubuntu 6.0.6.1 (aka Dapper Drake) as a possible release build environment, but I'm running into a "Connection Refused" exception on a New Socket((String) null, 5500) call around line 70 in ERFATestCase when attempting to send a message to the ExternallyRolledFileAppender to tell it to roll. The same test passes on other platforms and I'm guessing that it is a firewall issue. I've played with iptables rules (newbie at that), but haven't fixed the problem. When I started, sudo iptables -L showed no rules. Build environment: Ubuntu 6.0.6-1 desktop freshly installed in JVM subversion and sun-java6-jdk installed in Package Manager (requires adding multiverse to repos in Settings/Repos) ant-1.6.5 and maven 2.0.6 installed in home directory from Apache binaries (javah task failed in Ant when installed from Ubuntu) export JAVA_HOME=/usr/lib/jvm/java-6-sun export PATH=~/maven-2.0.6/bin:~/apache-ant-1.6.5/bin:$PATH svn co https://svn.apache.org/repos/asf/logging/log4j/branches/v1_2- branch log4j cd log4j mvn test I was able to build an NTEventAppender.dll on Ubuntu by installing mingw from the package manager and copying include/win32/jni_md.h from a Windows JDK 6 to /usr/lib/java-6-sun/include/win32/ jni_md.h. Haven't actually gone back and tried the generated DLL on Windows to make sure that it works. - 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.
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)
- 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]
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]
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 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]
