Robert,
I think contacting JavaWorld before writing the
article is a good idea. First, they will tell you if
they are interested in topic to begin with. Second,
they will set a deadline which makes it a priority
project, not some item on your todo list. Regards,
Ceki
--- Robert Bushman <[EMAIL
On Wed, 5 Dec 2001, Ceki Gulcu wrote:
>
> Robert,
>
> I will look at your code as soon as I have some time.
> I also encourage you write an article about the
> subject. We can write it together if you wish. Would
> you like me to contact JavaWorld? Regards, Ceki
No worries on time constraints, I
Robert,
I will look at your code as soon as I have some time.
I also encourage you write an article about the
subject. We can write it together if you wish. Would
you like me to contact JavaWorld? Regards, Ceki
--- Robert Bushman <[EMAIL PROTECTED]> wrote:
> The latest version of LoggingEvent i
The latest version of LoggingEvent includes commentary,
a fix of a forward compatibility bug (not reading
unexpected primitives), and a switch statement in
the place of an if(char) else if (char).
http://traxel.com/java/log4j/LoggingEvent.java
On Sun, 2 Dec 2001, Robert Bushman wrote:
> In read
In reading this post, I find it very confusing.
A simpler explanation is:
1. Compile all three classes and add them to your 1.2 jar file.
2. Create a jar containing *only* UnitTestLoggingEvent.class
called "unit-test.jar".
3. export CLASSPATH=unit-test.jar:junit.jar
NOTE: Do not add "." or
Hi,
Here's the latest source for the version safe LogginEvent
and the unit test.
http://traxel.com/java/log4j/
You'll also need UnitTestProxy.java, which has to be
included in the jar with the current version of Log4j.
You must have a copy of UnitTestLoggingEvent.class in
a seperate directory
On JUnit:
Following is a pretty rough pre-alpha. It is currently
capable of reading a LoggingEvent, Category, and Priority
definition from a 1.1.3 jar file (pops a JFileChooser
to ask for the jar); using those to instantiate
a LoggingEvent; serializing it into a byte[]; then
reading that byte[] in
On Tue, 20 Nov 2001, Robert Bushman wrote:
> There are some other issues that should be
> addressed, such as "What if a subclass overrides
> an internal method without knowing it?" Declaring
> the method final would solve this problem, and
> using a more "namespace friendly" name might
> make tha
On Tue, 20 Nov 2001, Ceki Gulcu wrote:
> My question was actually about the opportunity of calling readFields.
>More like, "how do you know you can call readFields at that point?"
A,
I'm guessing there are several questions here,
so let me take a stab at a few of them (as much
so that I ca
Robert,
At 19:45 19.11.2001 -0500, you wrote:
>Thank you for the author credit, I am honored.
We are honored to have you as a contributor.
>I'll be happy to thoroughly document the code.
Good.
>On readFields():
>According to the API spec, the only three cases
>in which readFields() will fail
Robert,
If I understand correctly, LogJam is intended to test the performance of serialization
and as a side effect can be viewed as a compatibility check. It would be very helpful
to have a test suite performing more aggressive compatibility tests. Are we sure that
log4j 1.2 can flawlessly r
Here's a brutally simplistic class that spews
logs, works with 1.2 or 1.1.3:
http://traxel.com/java/LogJam.java
And here it is packaged as an executable jar
with Log4j 1.1.3.
http://traxel.com/java/logjam-1_1_3.jar
java -jar logjam-1_1_3.jar socket:127.0.0.1:4445
(Currently only has a socket ap
readResolve sounds ideal, I'll play around with it
a bit and see what I can come up with.
On 1.2 v. 1.1. IMHO the question should be "How can
Log4j be of the most value to the most developers?"
Cost:
The number of people who will lose value by Log4j
1.2 and higher not being compatible with JDK 1
Thank you for the author credit, I am honored.
I'll be happy to thoroughly document the code.
On readFields():
According to the API spec, the only three cases
in which readFields() will fail are:
ClassNotFoundException - if the class of a serialized object
could not be found.
- Presumeably
Sorry, I meant dropping backward compatibility for JDK 1.1 since
ObjectInputStream#readFields requires JDK 1.2.
At 00:14 20.11.2001 +0100, you wrote:
>Robert,
>
>I also noticed that ObjectInputStream#readFields method was introduced in
>JDK 1.2. I have no qualms about dropping support for JDK
Robert,
I also noticed that ObjectInputStream#readFields method was introduced in
JDK 1.2. I have no qualms about dropping support for JDK 1.2. However, if
that is going to be the case, then the Priority class can be made
serializable while still conserving the flyweight property by implementin
I have looked at your code. You should definitely add yourself as an author. However,
before I can commit the change to the CVS repository I need to throughly understand
the code which I currently don't. Some extra documentation would not hurt. In
particular, how do you know that in customRead
I resubscribed with my real email address,
which will hopefully fix the posting lag issue.
I've just completed a real world test of the
version independant deserialization with a client
that spews an enormous number of v1.1.3 events
in a very short period of time. All went without
any noticable m
I'm pretty happy with the new version posted at
http://traxel.com/tools/LoggingEvent.java
It's now reading 1.1.3 and 1.2, and deserialization
has been refactored to a satisfactory level.
Known Issues:
- It has not been rigorously tested.
- startTime is static, so when you serialize,
then
First, brute-force pass is complete. For those interested
in seeing the general concept, i've posted it. Fair warning,
it's pretty ugly. Much polishing before I submit it formally.
http://traxel.com/tools/LoggingEvent.java
The method of interest is customReadObject( ObjectInputStream )
Note: I
> > > Hello,
> > >
> > > Anyone interested in adding version support for LoggingEvent
> > serialization?
> > > Currently, the sending side and the receiving side of a LoggingEvent have
> > > to have the same fields. If a field is added or if a fi
On Sun, 18 Nov 2001, robert burrell donkin wrote:
> On Saturday, November 17, 2001, at 12:24 AM, Robert Bushman wrote:
>
> > Well, rather than adding fuel to the fire, why
> > don't I take a crack at the native Java version,
> > then if the XML version is better, or mine
> > doesn't work out, no
If you're running Log4cpp, Can you post a comprehensive
copy of a serialized C++ LoggingEvent somewhere where I
can download it?
On Sun, 18 Nov 2001, Leathers, Burton wrote:
> Another thing to bear in mind in the serialization discussion is the need to
> have a 'logging event consolidator' which
e.
Burton
-Original Message-
From: robert burrell donkin [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 18, 2001 8:19 AM
To: Log4J Developers List
Subject: Re: LoggingEvent Serialization
On Saturday, November 17, 2001, at 12:24 AM, Robert Bushman wrote:
> Ahh, OK, thanks for the backgro
On Saturday, November 17, 2001, at 12:24 AM, Robert Bushman wrote:
> Ahh, OK, thanks for the background.
>
> Well, rather than adding fuel to the fire, why
> don't I take a crack at the native Java version,
> then if the XML version is better, or mine
> doesn't work out, no harm done, you can ju
>
>
> Robert Bushman <[EMAIL PROTECTED]> on 11/16/2001 12:09:51 PM
>
> Please respond to "Log4J Developers List" <[EMAIL PROTECTED]>
>
> To: Log4J Developers List <[EMAIL PROTECTED]>
> cc:
> Subject: LoggingEvent Serialization
>
>
>
&
quot;Log4J Developers List" <[EMAIL PROTECTED]>
To: Log4J Developers List <[EMAIL PROTECTED]>
cc:
Subject: LoggingEvent Serialization
What was the basic spin of the discussion?
"It's easy, just gotta do it.", "It seems
easy, but is going to be a real
proble
EMAIL PROTECTED]>
>
> To: "Log4J Developers List" <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Question about the properties file. Please Help.
>
>
>
>
> Hello,
>
> Anyone interested in adding version support for LoggingEvent serialization?
> Curren
I just started running this problem through my
head this morning. I'd be happy to write it.
On Fri, 16 Nov 2001, Ceki Gulcu wrote:
>
> Hello,
>
> Anyone interested in adding version support for LoggingEvent serialization?
>Currently, the sending side and the receiving si
Ceki Gülcü wrote:
>
> ps: See http://www.hta-bi.bfh.ch/~sevem/marco/school/advancedjava/descriptor.html
>
That's good to have. The Sun docs don't explain that very well.
/mike
--
**
Mike Dougherty -- Java Software Engineer
*
At 10:37 08.06.2001 -0400, you wrote:
>An alternative to adding a version number to each serialized
>LoggingEvent, and thus sending it for each event, is to think of
>SocketAppender as using a protocol with a higher version number. The
>difference is that the version number (which would still sig
Hi,
Ceki's suggestion
sounds good.
Just a comment re
the XML side of things. The bulk of the bloat with XML is often the tag
names, attribute names and namespace qualifiers. The beauty of XML is that it
doesn't matter what these are; what is important is their relationship to
each other
Hi Anders,
At 10:37 08.06.2001 -0400, you wrote:
>An alternative to adding a version number to each serialized
>LoggingEvent, and thus sending it for each event, is to think of
>SocketAppender as using a protocol with a higher version number. The
>difference is that the version number (which wo
Hi Mike,
I'm also leaning towards Ceki's and Mike's suggestion. By ensuring the v_n
data gets serialized before v_n+1, one should at least be able to upgrade
log4j on the downstream log4j servers without affecting the upstream
application servers (log4j clients).
As for the XML solution, perhap
Hello Mike,
>
> The only way I can think of solving this problem is by adding version control in
>side the LoggingEvent serialization code. For example, in version t0, the version
>number t0 is written to the stream before other data. On the retrieving end,
>LoggingEvent version t
Hello Mike,
The only way I can think of solving this problem is by adding version control in side
the LoggingEvent serialization code. For example, in version t0, the version number
t0 is written to the stream before other data. On the retrieving end, LoggingEvent
version t0 checks that the
I am trying to pin down what it is (if anything) that needs to be done
to (for) the LoggingEvent serialization.
The Problem: Serialization of the object works fine at present because
the class definition versions are the same. However, at some point in
the future this may not be the case
aul Glezen" <[EMAIL PROTECTED]>
To: "LOG4J Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 10:56 AM
Subject: Re: LoggingEvent Serialization (was: Re:
Contributing)
> I think the item Ceki has you working on takes priority over
LoggingEvent> s
paul,
XML based serialization could be useful for non-Java translations of log4j. Just one
of my far-fetched wishes... Ceki
At 10:56 04.06.2001 -0700, you wrote:
>I think the item Ceki has you working on takes priority over LoggingEvent
>serialization issues.
>
>As for the XM
At 14:24 04.06.2001 -0400, you wrote:
>The rules for XML serialization/deserialization can be external to
>the LoggingEvent itself. Only when a remote logging event gets ready
>to go across the wire, it would inspect the LoggingEvent object and
>build the appropriate XML representation. This way
t would be a bad fit...), but if you're
going to go the XML route, give it a look.
Anyway, my $.02...
- Tim
-Original Message-
From: Paul Glezen [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 1:57 PM
To: LOG4J Developers Mailing List
Subject: Re: LoggingEvent Serialization (was: Re
I think the item Ceki has you working on takes priority over LoggingEvent
serialization issues.
As for the XML idea, that would solve the problem of version changes.
Presently, log4j is not dependent on the user having XML parsers available.
You need one if you want to use DOMConfigurator or if
n version of the event.
> If a log4j upgrade involves changes to the event class, then all clients
> and servers must be upgraded at the same time. Otherwise object
> serialization errors occur. This can make log4j upgrades prohibitive in
> such an environment.
>
> It may be possibl
43 matches
Mail list logo
