On Sunday 29 May 2005 00:27, Mark Womack wrote:
> It may not be within Gump's domain, but I would still like to see some kind
> of remote build machine/process. Something that is used to build official
> versions of apache software with known sets of dependent sources, etc. Do
> you think that th
On Thursday 26 May 2005 01:18, Yoav Shapira wrote:
> Hi,
> One other suggestion: ask the Gump folks if they're willing to set up runs
> for us on these JDKs. They do so for other projects. What's in the run
> depends on us: we craft an Ant script and tell them which target to call in
> that file.
On Wednesday 25 May 2005 01:49, Mark Womack wrote:
> As usual, I am +1 for the above.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Monday 23 May 2005 13:16, Mark Womack wrote:
Wow. A lot more response than I expected. Let's not dwell in it.
> But we need to get our own house in order and get
> moving on our releases. We have been working on the current cvs head for
> too long without a major release.
Cheers
Niclas
On Monday 23 May 2005 12:44, Mark Womack wrote:
> Option 2 - 1.2.11 with just jms (and maybe throw in the bug fixes for the
> current 1.2.12 scheduled release). 1.3 based on last release of 1.2.X with
> the TRACE changes and some more deprecation in prep for the next major
> release. 1.4 release
Gang,
Trying not to be sarchastic or disrespectful, and only giving a hint of how I
perceive stuff at the moment.
Currently, the Log4J project is in a disarray and conflicting messages are
being sent to the users.
IMHO, SLF4J is a hasty conversion of UGLI and has not gotten much feedback
from
On Friday 20 May 2005 07:09, Curt Arnold wrote:
> I subscribe to the Gump list and there has been chatter that I'm not
> sure I'm interpreting correctly, but it appears that the main Gump
> server "Brutus" is being redeployed so Gump will be off-line for a
> few days and will be reborn running on a
On Thursday 19 May 2005 19:14, Endre Stølsvik wrote:
> 1.3 as 1.2+Trace-and-other-small-stuff,
+1 on that.
I wouldn't like to have announcements of quite extensive addition in a
normally known as a "bug fix" release.
Cheers
Niclas
---
On Friday 25 March 2005 21:32, Simon Kitching wrote:
> > So please don't let egos or politics screw up any chance of a solution
> > to this mess. Take something that works (UGLI sounds the best
> > candidate), call it 'JCL 2.0', encourage everyone to use it, and we can
> > all get on with life.
>
On Friday 25 March 2005 00:15, Jacob Kjome wrote:
> ALAPI" (Apache Logging API)
+1
Make a proposal to the JCL guys to that effect under a new subproject in
Apache LS, and transfer their karma here. Get rid of the "we vs them" and
create a "we" atmosphere.
By dropping the existing names, we get
On Thursday 24 March 2005 07:00, Ceki Gülcü wrote:
> Thanks Mark. Just finished reading it. As you said, it does not go into
> terrible but otherwise a pretty decent article.
Didn't we discuss before the possibility to make JUL the application API, and
Log4J the backend logging provider? Would th
On Saturday 05 March 2005 02:40, Harper, Allen (AHARPER) wrote:
> In a nutshell heres whats happening. The entire instance of the logger
> is syncronized. (Actually the syncronized object is the Category object
> from which the Logger is derived.) A caller makes a log call
> Log.(), in this ca
On Saturday 12 February 2005 01:38, Ceki Gülcü wrote:
> No objections from me.
>
> I've heard of rollovers based on date and size but never on message
> contents. I am curious about the use case.
I can think of one from the Process Control industry;
A lot of Process Control is operating around 'b
On Wednesday 09 February 2005 20:20, Ceki Gülcü wrote:
> Hello,
>
> For those interested I've been busy writing an article about the problems
> encountered when using JCL.
>
>http://www.qos.ch/logging/classloader.jsp
Is there any way we could get the Jakarta PMC and/or the ASF Board to kill th
On Thursday 10 February 2005 18:27, Ceki Gülcü wrote:
> UGLI is rather modest in its goals. It does not have the pretension of
> initiating any major technological leap. JCL promises more than what it can
> deliver. UGLI does what JCL does today but without the headaches.
This is a *very* good as
On Thursday 10 February 2005 03:34, Ceki Gülcü wrote:
> nless the ugli-xxx.jar file is corrupt, UGLI cannot never cause bugs of
> Type-I, Type-II or Type-III for the simple reason that all the required
> files are bundled together in the ugli-xxx jar file. UGLI's LoggerFactory
> only uses the class
On Wednesday 09 February 2005 23:34, you wrote:
> As you are very knowledgeable in class loader
> problems, I'd appreciate your comments and/or critical reviews.
First of all, I am very happy to see that someone else care, and care to such
an extent and goes through all the pain to explain this t
On Wednesday 09 February 2005 20:20, Ceki Gülcü wrote:
> Hello,
>
> For those interested I've been busy writing an article about the problems
> encountered when using JCL.
>
>http://www.qos.ch/logging/classloader.jsp
>
> Your comments and critical reviews are welcome.
Great work, BUT on *my* b
On Thursday 20 January 2005 16:24, Jacob Kjome wrote:
> > Whether Log4J has added its share to the current state, I will leave
> > unsaid... :o)
>
> If you are going to imply it, please say it (even with a happy face). I'm
> not sure what you mean here, but maybe the UGLI stuff eases this issue.
On Thursday 20 January 2005 05:48, Jacob Kjome wrote:
> Only server implementing
> child-first classloading behavior could allow you to bundle log4j.jar with
> the webapp and count on that version being used rather than the server
> version.
Not necessarily true.
IMHO, A container should NOT prov
On Thursday 13 January 2005 09:08, Ceki Gülcü wrote:
> I propose to split log4j.jar by
> dependency. For example,
> What do you think?
I like that a lot, since we can do all kind of funky dependency declarations
and get exactly what is required loaded correctly.
Cheers
Niclas
On Wednesday 15 December 2004 02:41, Mark Womack wrote:
> If there are that many projects in there, all dependent on
> each other in a multitude of ways, it amazes me that Gump ever completes a
> nightly build of all the projects. I like Gump, I support it, but I am not
> going to take special ac
On Tuesday 14 December 2004 00:22, [EMAIL PROTECTED] wrote:
> Index: SMTPAppender.java
> ===
> /home/cvs/logging-log4j/src/java/org/apache/log4j/net/SMTPAppender.java,v
> retrieving revision 1.35
> retrieving revision 1.36
> -
On Tuesday 14 December 2004 14:20, Mark Womack wrote:
> Not sure how you want to resolve this.
May I suggest a revert of the change first, and then think about how it should
be done?? :o) (only 200 projects are affected...)
Cheers
Niclas
--
+--//---+
/ http://www.dp
On Tuesday 14 December 2004 22:57, Ceki Gülcü wrote:
> When a totally silly problem attains such cataclysmic proportions, it
> puts us (log4j developers) under unnecessary and useless
> pressure.
My sincerest apologies. Of course, Log4J are entitled to "fuck up" from time
to tim
On Saturday 11 December 2004 03:17, Curt Arnold wrote:
> The best example of this is the use of the log4j namespace prefix. Per
> the namespaces spec, these two documents should have identical
> interpretations:
>
> http://jakarta.apache.org/log4j/"/>
>
> http://jakarta.apache.org/log4j/"/>
>
> H
On Saturday 11 December 2004 02:11, Curt Arnold wrote:
> If PropertyConfigurator had an include mechanism, it too would need
> some way to resolve relative file references.
Sorry for butting in, and there may be a lot of what I am saying is out of
line, but;
One thing that has always bugged m
On Tuesday 07 December 2004 05:23, Curt Arnold wrote:
> I'm sure that you could do better with a custom wire-format than the
> current Java default serialization, however I'm not sure that you would
> see any significant advantage over custom serialization. The benefits
> for using Java custom se
On Monday 06 December 2004 21:59, Shapira, Yoav wrote:
> Hi,
> We should balance the performance aspect versus the requirement for
> serialization compatibility. I think the latter is a nice to have, but
> by no means an essential feature. I think the former is imperative for
> log4j as it is for
On Sunday 05 December 2004 16:20, Scott Deboy wrote:
> I haven't tried sending events from log4j 1.3 to log4j 1.2.8, but I doubt
> deserialization would work, without more changes to serialization logic.
>
> In 1.3, LoggingEvent contains a new field:
> long sequenceNumber
> The 1.2.8 code wouldn't
On Sunday 28 November 2004 01:40, Ceki Gülcü wrote:
> However, the
> JLS (Java Language Specification) explicitly states that the JVM can
> collapse stack frames as an optimization measure.
Now when you mention it, I am not sure whether the IBM JVM (the one that comes
with WebSphere ver ??.? )
On Saturday 27 November 2004 05:12, Vlad Skarzhevskyy wrote:
> And it generaly cost only 0.1 milliseconds.
> for 1000 classes application ~ 1 sec to start.
0.1 x 1000 != ~1sec
Cheers
Niclas
--
+--//---+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+---
On Friday 26 November 2004 21:21, Ceki Gülcü wrote:
Ceki,
> The change is not not a backward compatible. My suggestion would be use a
> simple FileAppender instead of RollingFileAppender.
One too many "not" ?
Assuming that is the case, are we talking about a Log4J 2.0 in the making, or
is 1.3
Hi,
http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
Jakarta Velocity is somehow using the RollingFileAppender in code, and I
wonder if you guys have moved it from
org.apache.log4j.RollingFileAppender
to
org.
Gang,
I think the following Gump failure could be related to recent Log4J changes...
http://brutus.apache.org/gump/public/ws-axis/ws-axis/gump_work/build_ws-axis_ws-axis.html
Any input is appreciated.
Cheers
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://n
Gang,
I think that this build failure is due to recent Log4J changes;
http://brutus.apache.org/gump/public/ws-axis/ws-axis/gump_work/build_ws-axis_ws-axis.html
and possibly this one is the same problem;
http://brutus.apache.org/gump/public/xjavadoc/xjavadoc/gump_work/build_xjavadoc_xjavadoc.html
On Thursday 28 October 2004 03:01, E. Epstein (ML) wrote:
> So having not contributed to log4j before, what step next?
> P.S., Since writing this I've gone ahead and changed NDC.java. It
> compiles and passes basic tests. It is gzipped and attached here.
Generally, most Apache projects appr
On Wednesday 20 October 2004 20:45, Ceki Gülcü wrote:
> Is there a valid reason for gump to track log4j 1.2? As I discussed with
> you privately, Niclas, I do not wish to have the code on the CVS 1.2 branch
> changed so that it differs from the released version (1.2.8.). We agreed
> that you would
We have started to trial with JDK1.5 in Gump. It won't be soon for it to
become the official build platform, nor nagging you about it.
However, I think it is time to slowly reporting problems found, to the
respective camps, for them to take a look at it.
http://brutus.apache.org/gump/jdk15/log
On Monday 11 October 2004 18:04, Ceki Gülcü wrote:
> Hello Niclas,
>
> Just look at the docs:
>
> http://logging.apache.org/log4j/docs/api/org/apache/log4j/Priority.html
Please don't beat up (kill?) the messenger ;o)
cannot resolve symbol
symbol : method toPriority (java.lang.String,org.apache
Gang,
I am trying to sort out Gump related build issues.
The eyebrowse.tigris.org project has a build error in Gump;
[javac]
/usr/local/gump/public/workspace/eyebrowse/src/java/org/tigris/eyebrowse/util/EyebrowseLogger.java:108:
cannot resolve symbol
[javac] symbol : method toPriority
(
On Sunday 26 September 2004 18:48, Ceki Gülcü wrote:
> In order to fix bug 24159, would it be possible for you to not log
> from within a synchronized resource which is also used from within
> rendering code?
May I quietly add, Mr Ross, that this is not at all unique to Log4J as a
subsy
42 matches
Mail list logo
