You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Simon Woodward <si...@redcabbage.org> on 2005/01/13 18:25:15 UTC
Log4D, Log4Cxx, Log4J interoperability
All,
I've written a reader for Log4Cxx's binary stream as generated by the
SocketAppender. It's based on the Log4J 1.29 code base - is this of
interest to the project?
S
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4D, Log4Cxx, Log4J interoperability
Posted by Simon Woodward <si...@redcabbage.org>.
Well, exactly. The data is dumped onto the stream using whatever
byte-order and native type size the system running the logger happens to
have.
There are ways around it, however: you can configure your log server to
listen in whatever endianness you need, with the default being the
native format of the platform you're running on. If you're expecting
logging from multiple platforms with mixed endianness, well, listen on
two differently configured sockets. The same goes for type sizes, which
gives you a maximum of 4 different flavours of connection.
The main reason that I need this bit of code is to easily produce a
real-time interleaved log file from various components, written in a
spread of perl, C++, Delphi and Java - however, they're all on the same
system so I know the endianness and type sizes. I would be surprised to
come across somebody needing to read more than two of the
endianness/type size combinations - or have I entirely missed the boat?
Are there any plans to ship another version of the 1.29 code stream?
Simon
ps. attempting tar.gz - this list won't accept zips...
Curt Arnold wrote:
> Unfortunately, log4cxx's binary format is not platform independent.
> There have been reports that 32-bit and 64-bit implementations don't
> interoperate and I assume that 32-bit big-endian and 32-bit
> little-endian wouldn't.
>
>
>
> On Jan 13, 2005, at 1:23 PM, Ceki G�lc� wrote:
>
>
>> - Log4j-dev accepts attachments while log4j-user does not.
>>
>> - Performance wise, how well does the cxx method compare to java
>> serialization?
>>
>> At 07:26 PM 1/13/2005, you wrote:
>>
>>> Ceki,
>>>
>>> As the code currently stands it has two drawbacks:
>>>
>>> 1) It has my company's internal package names and structure. Worry
>>> not, I have permission from the organisation to donate this code -
>>> logging software is not exactly our core business. :-)
>>>
>>> 2) Having been written under the assumption that it would be an
>>> internal tool, it has not been properly integrated into Log4J. The
>>> correct way to do this would be to modify
>>> org.apache.log4j.net.SocketServer to accomodate multiple methods of
>>> parsing the incoming stream.
>>>
>>> I'll gladly fix these items if you decide that this will be of
>>> interest - I don't want to do the work if this has to stay an
>>> internal tool! As the apache lists don't accept attachments, how do
>>> I get the code to you?
>>>
>>> Simon
>>
>> -- Ceki G�lc�
>>
>> The complete log4j manual: http://www.qos.ch/log4j/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Re: Log4D, Log4Cxx, Log4J interoperability
Posted by Curt Arnold <ca...@apache.org>.
Unfortunately, log4cxx's binary format is not platform independent.
There have been reports that 32-bit and 64-bit implementations don't
interoperate and I assume that 32-bit big-endian and 32-bit
little-endian wouldn't.
On Jan 13, 2005, at 1:23 PM, Ceki Gülcü wrote:
> - Log4j-dev accepts attachments while log4j-user does not.
>
> - Performance wise, how well does the cxx method compare to java
> serialization?
>
> At 07:26 PM 1/13/2005, you wrote:
>> Ceki,
>>
>> As the code currently stands it has two drawbacks:
>>
>> 1) It has my company's internal package names and structure. Worry
>> not, I have permission from the organisation to donate this code -
>> logging software is not exactly our core business. :-)
>>
>> 2) Having been written under the assumption that it would be an
>> internal tool, it has not been properly integrated into Log4J. The
>> correct way to do this would be to modify
>> org.apache.log4j.net.SocketServer to accomodate multiple methods of
>> parsing the incoming stream.
>>
>> I'll gladly fix these items if you decide that this will be of
>> interest - I don't want to do the work if this has to stay an
>> internal tool! As the apache lists don't accept attachments, how do I
>> get the code to you?
>>
>> Simon
> -- Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4D, Log4Cxx, Log4J interoperability
Posted by Ceki Gülcü <ce...@qos.ch>.
- Log4j-dev accepts attachments while log4j-user does not.
- Performance wise, how well does the cxx method compare to java serialization?
At 07:26 PM 1/13/2005, you wrote:
>Ceki,
>
>As the code currently stands it has two drawbacks:
>
>1) It has my company's internal package names and structure. Worry not, I
>have permission from the organisation to donate this code - logging
>software is not exactly our core business. :-)
>
>2) Having been written under the assumption that it would be an internal
>tool, it has not been properly integrated into Log4J. The correct way to
>do this would be to modify org.apache.log4j.net.SocketServer to accomodate
>multiple methods of parsing the incoming stream.
>
>I'll gladly fix these items if you decide that this will be of interest -
>I don't want to do the work if this has to stay an internal tool! As the
>apache lists don't accept attachments, how do I get the code to you?
>
>Simon
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4D, Log4Cxx, Log4J interoperability
Posted by Simon Woodward <si...@redcabbage.org>.
Ceki,
As the code currently stands it has two drawbacks:
1) It has my company's internal package names and structure. Worry not,
I have permission from the organisation to donate this code - logging
software is not exactly our core business. :-)
2) Having been written under the assumption that it would be an internal
tool, it has not been properly integrated into Log4J. The correct way
to do this would be to modify org.apache.log4j.net.SocketServer to
accomodate multiple methods of parsing the incoming stream.
I'll gladly fix these items if you decide that this will be of interest
- I don't want to do the work if this has to stay an internal tool! As
the apache lists don't accept attachments, how do I get the code to you?
Simon
Ceki Gülcü wrote:
>
> Simon,
>
> You mean a reader for the output generated by the SocketAppender in
> log4cxx? I'd be quite interested to have a look.
>
> At 06:25 PM 1/13/2005, Simon Woodward wrote:
>
>> All,
>>
>> I've written a reader for Log4Cxx's binary stream as generated by the
>> SocketAppender. It's based on the Log4J 1.29 code base - is this of
>> interest to the project?
>>
>> S
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4D, Log4Cxx, Log4J interoperability
Posted by Ceki Gülcü <ce...@qos.ch>.
Simon,
You mean a reader for the output generated by the SocketAppender in
log4cxx? I'd be quite interested to have a look.
At 06:25 PM 1/13/2005, Simon Woodward wrote:
>All,
>
>I've written a reader for Log4Cxx's binary stream as generated by the
>SocketAppender. It's based on the Log4J 1.29 code base - is this of
>interest to the project?
>
>S
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org