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 field is removed in
> > > LoggingEvent from one log4j
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
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 just
use the XML version.
Bob
On Fri, 16 Nov 2001, Paul Glezen wrote:
> The dis
The discussion broke down when some wanted to use XML as the serialization
scheme while others wanted to continue to use Java serialization. I was in
the Java serialization camp. But the open source community is a "put your
money where your mouth is" type of group. Since I was not writing or
pa
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 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
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 signify the
format of whatever is sent over 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
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 XML idea, that would
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 y
32 matches
Mail list logo
