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 Gary Gregory <ga...@gmail.com> on 2014/03/31 05:04:32 UTC
core.impl.Log4jLogEvent.LogEventProxy
As I am working on
LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into
core.impl.Log4jLogEvent.LogEventProxy.
- LogEventProxy is used to move events across threads internally
- A real Log4jLogEvent is used in the SerializedLayout.
Why the different?
As you answer, if you can avoid committing to Log4jLogEvent that would be
great as I currently have pending changes there related to
LOG4J2-583.<https://issues.apache.org/jira/browse/LOG4J2-583>
I am wondering if SerializedLayout should use LogEventProxy or if
LogEventProxy is a leftover from old development.
Thank you,
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
If you want to do XML IO with Jackson, Jackson recommends using Woodstox
for XML IO but it is not clear to me if that is a suggestion or a
requirement.
Gary
On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
> I would use Jackson for JSON since we already use it. I don't recall that
> we use an XML serializer anywhere else so I would stick with either JAXB or
> Jackson since they don't introduce any new dependencies.
>
> Ralph
>
> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Jackson will do both the JSON and XML if you want. If you can manage to
>> use the Proxy I think that would be better.
>>
>> Ralph
>>
>> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that
> instead of JAXB.
>
> Thoughts?
>
> Gary
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> Out of curiosity, why does implementing an XML socket server require
>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>> going to do that would require that?
>>>
>>
>> My current working implementation uses JAXB annotations on Log4jLogEvent,
>> no need to deal with messy DOM nonsense. The XML layout can then be a one
>> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
>> also with a one liner to convert from XML to a Log4jLogEvent.
>>
>> But I could do it in the existing "proxy" log event instead or a new XML
>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>> extra object. So I am asking...
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>
>>> - LogEventProxy is used to move events across threads internally
>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>
>>> Why the different?
>>>
>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>> be great as I currently have pending changes there related to
>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>
>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>> LogEventProxy is a leftover from old development.
>>>
>>> Thank you,
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Matt Sicker <bo...@gmail.com>.
Just FYI, Jackson supports JAXB annotations:
https://github.com/FasterXML/jackson-module-jaxb-annotations
They've also got an experimental avro dataformat:
https://github.com/FasterXML/jackson-dataformat-avro
which could be handy with the flume logger, yes?
On 31 March 2014 20:11, Ralph Goers <rg...@apache.org> wrote:
> I would use Jackson for JSON since we already use it. I don't recall that
> we use an XML serializer anywhere else so I would stick with either JAXB or
> Jackson since they don't introduce any new dependencies.
>
> Ralph
>
> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Jackson will do both the JSON and XML if you want. If you can manage to
>> use the Proxy I think that would be better.
>>
>> Ralph
>>
>> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that
> instead of JAXB.
>
> Thoughts?
>
> Gary
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> Out of curiosity, why does implementing an XML socket server require
>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>> going to do that would require that?
>>>
>>
>> My current working implementation uses JAXB annotations on Log4jLogEvent,
>> no need to deal with messy DOM nonsense. The XML layout can then be a one
>> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
>> also with a one liner to convert from XML to a Log4jLogEvent.
>>
>> But I could do it in the existing "proxy" log event instead or a new XML
>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>> extra object. So I am asking...
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>
>>> - LogEventProxy is used to move events across threads internally
>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>
>>> Why the different?
>>>
>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>> be great as I currently have pending changes there related to
>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>
>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>> LogEventProxy is a leftover from old development.
>>>
>>> Thank you,
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
Matt Sicker <bo...@gmail.com>
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Matt Sicker <bo...@gmail.com>.
I meant if it is possible to reuse the JAXB annotations to (de)serialize
JSON
On Tuesday, 1 April 2014, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 4:40 PM, Matt Sicker <boards@gmail.com<javascript:_e(%7B%7D,'cvml','boards@gmail.com');>
> > wrote:
>
>> With the existing JAXB annotations, do you think a compatible JSON file
>> could be generated?
>>
>
> No. Because it is not enough to annotate, you need custom un/marshallers.
>
>
>> Minus namespaces of course (or even with namespaces by prepending them to
>> keys). I might tinker with that later to see. Could get a structured text
>> sort of API going out of it.
>>
>
> This is what I have working now locally:
> - XML unmarshalling (or "deserializing" in Jackson parlance) with JAXB.
> - Unit tests for UDP and TCP passing
> - Reworked the frameworf to neatly account for Serialization, XML and JSON.
>
> My next step is to make the same changes I did with JAXB but with JSON.
>
> Then I'll have JSON unmarshalling working.
>
> Then I can see if I can unmarshal from XML using JSON. If that works, I
> can remove the JAXB annotations.
>
> Next would be to replace all the custom code in the XML and JSON layouts
> with Jackson (almost) one liners.
>
> Gary
>
>
>
> On 1 April 2014 11:03, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Apr 1, 2014 at 11:04 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Oh good catch. Maybe in JDK9 they'll put JSON in there.
>
>
> One can only hope... but I do marvel at the lack of vision though, how can
> this not be a tweak on top of JAXB?
>
> Gary
>
>
>
>
> On 1 April 2014 07:39, Gary Gregory <ga...@gmail.com> wrote:
>
> OK, I've looked at EJ item #78, JAXB and Jackson a little more. Initially,
> it looks like #78 is specific to Java Serializable objects but the pattern
> should also apply to other "extralinguistic mechanisms" for marshalling.
> I'll go back and see my JAXB implementation can be made cleaner...
>
> Gary
>
>
> On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
>
> I would use Jackson for JSON since we already use it. I don't recall that
> we use an XML serializer anywhere else so I would stick with either JAXB or
> Jackson since they don't introduce any new dependencies.
>
> Ralph
>
> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> Jackson will do both the JSON and XML if you want. If you can manage to
> use the Proxy I think that would be better.
>
> Ralph
>
> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that
> instead of JAXB.
>
> Thoughts?
>
> Gary
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> Out of curiosity, why does implementing an XML socket server require
> touching the LogEvent? What are XMLLogEventI
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com<javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>| ggregory@apache.org
> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Apr 1, 2014 at 4:40 PM, Matt Sicker <bo...@gmail.com> wrote:
> With the existing JAXB annotations, do you think a compatible JSON file
> could be generated?
>
No. Because it is not enough to annotate, you need custom un/marshallers.
> Minus namespaces of course (or even with namespaces by prepending them to
> keys). I might tinker with that later to see. Could get a structured text
> sort of API going out of it.
>
This is what I have working now locally:
- XML unmarshalling (or "deserializing" in Jackson parlance) with JAXB.
- Unit tests for UDP and TCP passing
- Reworked the frameworf to neatly account for Serialization, XML and JSON.
My next step is to make the same changes I did with JAXB but with JSON.
Then I'll have JSON unmarshalling working.
Then I can see if I can unmarshal from XML using JSON. If that works, I can
remove the JAXB annotations.
Next would be to replace all the custom code in the XML and JSON layouts
with Jackson (almost) one liners.
Gary
>
> On 1 April 2014 11:03, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Tue, Apr 1, 2014 at 11:04 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Oh good catch. Maybe in JDK9 they'll put JSON in there.
>>>
>>
>> One can only hope... but I do marvel at the lack of vision though, how
>> can this not be a tweak on top of JAXB?
>>
>> Gary
>>
>>
>>>
>>>
>>> On 1 April 2014 07:39, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> OK, I've looked at EJ item #78, JAXB and Jackson a little more.
>>>> Initially, it looks like #78 is specific to Java Serializable objects but
>>>> the pattern should also apply to other "extralinguistic mechanisms" for
>>>> marshalling. I'll go back and see my JAXB implementation can be made
>>>> cleaner...
>>>>
>>>> Gary
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
>>>>
>>>>> I would use Jackson for JSON since we already use it. I don't recall
>>>>> that we use an XML serializer anywhere else so I would stick with either
>>>>> JAXB or Jackson since they don't introduce any new dependencies.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>
>>>>>> Jackson will do both the JSON and XML if you want. If you can manage
>>>>>> to use the Proxy I think that would be better.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> So the options are:
>>>>>
>>>>> - JRE JAXB can do XML but not JSON
>>>>> - Eclipse JAXB ("MOXy") can do XML and JSON
>>>>> - Jackson can do both XML and JSON
>>>>>
>>>>> Because we already depend on Jackson it sounds like I should use that
>>>>> instead of JAXB.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gary
>>>>>
>>>>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>
>>>>>>> Out of curiosity, why does implementing an XML socket server require
>>>>>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>>>>>> going to do that would require that?
>>>>>>>
>>>>>>
>>>>>> My current working implementation uses JAXB annotations on
>>>>>> Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can
>>>>>> then be a one liner: JAXB.marshal(logEvent, result). Right now the socket
>>>>>> server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>>>>
>>>>>> But I could do it in the existing "proxy" log event instead or a new
>>>>>> XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create
>>>>>> an extra object. So I am asking...
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>>>>
>>>>>>> - LogEventProxy is used to move events across threads internally
>>>>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>>>>
>>>>>>> Why the different?
>>>>>>>
>>>>>>> As you answer, if you can avoid committing to Log4jLogEvent that
>>>>>>> would be great as I currently have pending changes there related to
>>>>>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>>>>>
>>>>>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>>>>>> LogEventProxy is a leftover from old development.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Gary
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Matt Sicker <bo...@gmail.com>.
With the existing JAXB annotations, do you think a compatible JSON file
could be generated? Minus namespaces of course (or even with namespaces by
prepending them to keys). I might tinker with that later to see. Could get
a structured text sort of API going out of it.
On 1 April 2014 11:03, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 11:04 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Oh good catch. Maybe in JDK9 they'll put JSON in there.
>>
>
> One can only hope... but I do marvel at the lack of vision though, how can
> this not be a tweak on top of JAXB?
>
> Gary
>
>
>>
>>
>> On 1 April 2014 07:39, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> OK, I've looked at EJ item #78, JAXB and Jackson a little more.
>>> Initially, it looks like #78 is specific to Java Serializable objects but
>>> the pattern should also apply to other "extralinguistic mechanisms" for
>>> marshalling. I'll go back and see my JAXB implementation can be made
>>> cleaner...
>>>
>>> Gary
>>>
>>>
>>> On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
>>>
>>>> I would use Jackson for JSON since we already use it. I don't recall
>>>> that we use an XML serializer anywhere else so I would stick with either
>>>> JAXB or Jackson since they don't introduce any new dependencies.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <
>>>> ralph.goers@dslextreme.com> wrote:
>>>>
>>>>> Jackson will do both the JSON and XML if you want. If you can manage
>>>>> to use the Proxy I think that would be better.
>>>>>
>>>>> Ralph
>>>>>
>>>>> So the options are:
>>>>
>>>> - JRE JAXB can do XML but not JSON
>>>> - Eclipse JAXB ("MOXy") can do XML and JSON
>>>> - Jackson can do both XML and JSON
>>>>
>>>> Because we already depend on Jackson it sounds like I should use that
>>>> instead of JAXB.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>
>>>>>> Out of curiosity, why does implementing an XML socket server require
>>>>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>>>>> going to do that would require that?
>>>>>>
>>>>>
>>>>> My current working implementation uses JAXB annotations on
>>>>> Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can
>>>>> then be a one liner: JAXB.marshal(logEvent, result). Right now the socket
>>>>> server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>>>
>>>>> But I could do it in the existing "proxy" log event instead or a new
>>>>> XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create
>>>>> an extra object. So I am asking...
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>>>
>>>>>> - LogEventProxy is used to move events across threads internally
>>>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>>>
>>>>>> Why the different?
>>>>>>
>>>>>> As you answer, if you can avoid committing to Log4jLogEvent that
>>>>>> would be great as I currently have pending changes there related to
>>>>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>>>>
>>>>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>>>>> LogEventProxy is a leftover from old development.
>>>>>>
>>>>>> Thank you,
>>>>>> Gary
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Apr 1, 2014 at 11:04 AM, Matt Sicker <bo...@gmail.com> wrote:
> Oh good catch. Maybe in JDK9 they'll put JSON in there.
>
One can only hope... but I do marvel at the lack of vision though, how can
this not be a tweak on top of JAXB?
Gary
>
>
> On 1 April 2014 07:39, Gary Gregory <ga...@gmail.com> wrote:
>
>> OK, I've looked at EJ item #78, JAXB and Jackson a little more.
>> Initially, it looks like #78 is specific to Java Serializable objects but
>> the pattern should also apply to other "extralinguistic mechanisms" for
>> marshalling. I'll go back and see my JAXB implementation can be made
>> cleaner...
>>
>> Gary
>>
>>
>> On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
>>
>>> I would use Jackson for JSON since we already use it. I don't recall
>>> that we use an XML serializer anywhere else so I would stick with either
>>> JAXB or Jackson since they don't introduce any new dependencies.
>>>
>>> Ralph
>>>
>>> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <
>>> ralph.goers@dslextreme.com> wrote:
>>>
>>>> Jackson will do both the JSON and XML if you want. If you can manage
>>>> to use the Proxy I think that would be better.
>>>>
>>>> Ralph
>>>>
>>>> So the options are:
>>>
>>> - JRE JAXB can do XML but not JSON
>>> - Eclipse JAXB ("MOXy") can do XML and JSON
>>> - Jackson can do both XML and JSON
>>>
>>> Because we already depend on Jackson it sounds like I should use that
>>> instead of JAXB.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <
>>>> ralph.goers@dslextreme.com> wrote:
>>>>
>>>>> Out of curiosity, why does implementing an XML socket server require
>>>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>>>> going to do that would require that?
>>>>>
>>>>
>>>> My current working implementation uses JAXB annotations on
>>>> Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can
>>>> then be a one liner: JAXB.marshal(logEvent, result). Right now the socket
>>>> server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>>
>>>> But I could do it in the existing "proxy" log event instead or a new
>>>> XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create
>>>> an extra object. So I am asking...
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>>
>>>>> - LogEventProxy is used to move events across threads internally
>>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>>
>>>>> Why the different?
>>>>>
>>>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>>>> be great as I currently have pending changes there related to
>>>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>>>
>>>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>>>> LogEventProxy is a leftover from old development.
>>>>>
>>>>> Thank you,
>>>>> Gary
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Matt Sicker <bo...@gmail.com>.
Oh good catch. Maybe in JDK9 they'll put JSON in there.
On 1 April 2014 07:39, Gary Gregory <ga...@gmail.com> wrote:
> OK, I've looked at EJ item #78, JAXB and Jackson a little more. Initially,
> it looks like #78 is specific to Java Serializable objects but the pattern
> should also apply to other "extralinguistic mechanisms" for marshalling.
> I'll go back and see my JAXB implementation can be made cleaner...
>
> Gary
>
>
> On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
>
>> I would use Jackson for JSON since we already use it. I don't recall
>> that we use an XML serializer anywhere else so I would stick with either
>> JAXB or Jackson since they don't introduce any new dependencies.
>>
>> Ralph
>>
>> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ralph.goers@dslextreme.com
>> > wrote:
>>
>>> Jackson will do both the JSON and XML if you want. If you can manage to
>>> use the Proxy I think that would be better.
>>>
>>> Ralph
>>>
>>> So the options are:
>>
>> - JRE JAXB can do XML but not JSON
>> - Eclipse JAXB ("MOXy") can do XML and JSON
>> - Jackson can do both XML and JSON
>>
>> Because we already depend on Jackson it sounds like I should use that
>> instead of JAXB.
>>
>> Thoughts?
>>
>> Gary
>>
>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ralph.goers@dslextreme.com
>>> > wrote:
>>>
>>>> Out of curiosity, why does implementing an XML socket server require
>>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>>> going to do that would require that?
>>>>
>>>
>>> My current working implementation uses JAXB annotations on
>>> Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can
>>> then be a one liner: JAXB.marshal(logEvent, result). Right now the socket
>>> server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>
>>> But I could do it in the existing "proxy" log event instead or a new XML
>>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>>> extra object. So I am asking...
>>>
>>> Gary
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>
>>>> - LogEventProxy is used to move events across threads internally
>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>
>>>> Why the different?
>>>>
>>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>>> be great as I currently have pending changes there related to
>>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>>
>>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>>> LogEventProxy is a leftover from old development.
>>>>
>>>> Thank you,
>>>> Gary
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
OK, I've looked at EJ item #78, JAXB and Jackson a little more. Initially,
it looks like #78 is specific to Java Serializable objects but the pattern
should also apply to other "extralinguistic mechanisms" for marshalling.
I'll go back and see my JAXB implementation can be made cleaner...
Gary
On Mon, Mar 31, 2014 at 9:11 PM, Ralph Goers <rg...@apache.org> wrote:
> I would use Jackson for JSON since we already use it. I don't recall that
> we use an XML serializer anywhere else so I would stick with either JAXB or
> Jackson since they don't introduce any new dependencies.
>
> Ralph
>
> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Jackson will do both the JSON and XML if you want. If you can manage to
>> use the Proxy I think that would be better.
>>
>> Ralph
>>
>> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that
> instead of JAXB.
>
> Thoughts?
>
> Gary
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> Out of curiosity, why does implementing an XML socket server require
>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>> going to do that would require that?
>>>
>>
>> My current working implementation uses JAXB annotations on Log4jLogEvent,
>> no need to deal with messy DOM nonsense. The XML layout can then be a one
>> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
>> also with a one liner to convert from XML to a Log4jLogEvent.
>>
>> But I could do it in the existing "proxy" log event instead or a new XML
>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>> extra object. So I am asking...
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>
>>> - LogEventProxy is used to move events across threads internally
>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>
>>> Why the different?
>>>
>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>> be great as I currently have pending changes there related to
>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>
>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>> LogEventProxy is a leftover from old development.
>>>
>>> Thank you,
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Ralph Goers <rg...@apache.org>.
I would use Jackson for JSON since we already use it. I don't recall that we use an XML serializer anywhere else so I would stick with either JAXB or Jackson since they don't introduce any new dependencies.
Ralph
> On Mar 31, 2014, at 5:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> Jackson will do both the JSON and XML if you want. If you can manage to use the Proxy I think that would be better.
>>
>> Ralph
> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that instead of JAXB.
>
> Thoughts?
>
> Gary
>
>>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> Out of curiosity, why does implementing an XML socket server require touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput going to do that would require that?
>>>
>>> My current working implementation uses JAXB annotations on Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can then be a one liner: JAXB.marshal(logEvent, result). Right now the socket server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>
>>> But I could do it in the existing "proxy" log event instead or a new XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an extra object. So I am asking...
>>>
>>> Gary
>>>>
>>>> Ralph
>>>>
>>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> As I am working on LOG4J2-583 I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>>
>>>>> - LogEventProxy is used to move events across threads internally
>>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>>
>>>>> Why the different?
>>>>>
>>>>> As you answer, if you can avoid committing to Log4jLogEvent that would be great as I currently have pending changes there related to LOG4J2-583.
>>>>>
>>>>> I am wondering if SerializedLayout should use LogEventProxy or if LogEventProxy is a leftover from old development.
>>>>>
>>>>> Thank you,
>>>>> Gary
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 31, 2014 at 8:55 PM, Matt Sicker <bo...@gmail.com> wrote:
> Jackson also does YAML! I think that might be our best bet, although Java
> 1.7 did add a JSON API similar to JAXB.
>
Incorrect, the Java JSON API is not in Java 7.
It is in Java *EE* 7, which is quite a different beast.
Gary
>
> On 31 March 2014 19:34, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ralph.goers@dslextreme.com
>> > wrote:
>>
>>> Jackson will do both the JSON and XML if you want. If you can manage to
>>> use the Proxy I think that would be better.
>>>
>>> Ralph
>>>
>>> So the options are:
>>
>> - JRE JAXB can do XML but not JSON
>> - Eclipse JAXB ("MOXy") can do XML and JSON
>> - Jackson can do both XML and JSON
>>
>> Because we already depend on Jackson it sounds like I should use that
>> instead of JAXB.
>>
>> Thoughts?
>>
>> Gary
>>
>> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ralph.goers@dslextreme.com
>>> > wrote:
>>>
>>>> Out of curiosity, why does implementing an XML socket server require
>>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>>> going to do that would require that?
>>>>
>>>
>>> My current working implementation uses JAXB annotations on
>>> Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can
>>> then be a one liner: JAXB.marshal(logEvent, result). Right now the socket
>>> server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>>
>>> But I could do it in the existing "proxy" log event instead or a new XML
>>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>>> extra object. So I am asking...
>>>
>>> Gary
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>>
>>>> - LogEventProxy is used to move events across threads internally
>>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>>
>>>> Why the different?
>>>>
>>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>>> be great as I currently have pending changes there related to
>>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>>
>>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>>> LogEventProxy is a leftover from old development.
>>>>
>>>> Thank you,
>>>> Gary
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Matt Sicker <bo...@gmail.com>.
Jackson also does YAML! I think that might be our best bet, although Java
1.7 did add a JSON API similar to JAXB.
On 31 March 2014 19:34, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Jackson will do both the JSON and XML if you want. If you can manage to
>> use the Proxy I think that would be better.
>>
>> Ralph
>>
>> So the options are:
>
> - JRE JAXB can do XML but not JSON
> - Eclipse JAXB ("MOXy") can do XML and JSON
> - Jackson can do both XML and JSON
>
> Because we already depend on Jackson it sounds like I should use that
> instead of JAXB.
>
> Thoughts?
>
> Gary
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> Out of curiosity, why does implementing an XML socket server require
>>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>>> going to do that would require that?
>>>
>>
>> My current working implementation uses JAXB annotations on Log4jLogEvent,
>> no need to deal with messy DOM nonsense. The XML layout can then be a one
>> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
>> also with a one liner to convert from XML to a Log4jLogEvent.
>>
>> But I could do it in the existing "proxy" log event instead or a new XML
>> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
>> extra object. So I am asking...
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>
>>> - LogEventProxy is used to move events across threads internally
>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>
>>> Why the different?
>>>
>>> As you answer, if you can avoid committing to Log4jLogEvent that would
>>> be great as I currently have pending changes there related to
>>> LOG4J2-583. <https://issues.apache.org/jira/browse/LOG4J2-583>
>>>
>>> I am wondering if SerializedLayout should use LogEventProxy or if
>>> LogEventProxy is a leftover from old development.
>>>
>>> Thank you,
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> Jackson will do both the JSON and XML if you want. If you can manage to
> use the Proxy I think that would be better.
>
> Ralph
>
> So the options are:
- JRE JAXB can do XML but not JSON
- Eclipse JAXB ("MOXy") can do XML and JSON
- Jackson can do both XML and JSON
Because we already depend on Jackson it sounds like I should use that
instead of JAXB.
Thoughts?
Gary
On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Out of curiosity, why does implementing an XML socket server require
>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>> going to do that would require that?
>>
>
> My current working implementation uses JAXB annotations on Log4jLogEvent,
> no need to deal with messy DOM nonsense. The XML layout can then be a one
> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
> also with a one liner to convert from XML to a Log4jLogEvent.
>
> But I could do it in the existing "proxy" log event instead or a new XML
> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
> extra object. So I am asking...
>
> Gary
>
>>
>> Ralph
>>
>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>
>> - LogEventProxy is used to move events across threads internally
>> - A real Log4jLogEvent is used in the SerializedLayout.
>>
>> Why the different?
>>
>> As you answer, if you can avoid committing to Log4jLogEvent that would be
>> great as I currently have pending changes there related to LOG4J2-583.<https://issues.apache.org/jira/browse/LOG4J2-583>
>>
>> I am wondering if SerializedLayout should use LogEventProxy or if
>> LogEventProxy is a leftover from old development.
>>
>> Thank you,
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Ralph Goers <ra...@dslextreme.com>.
Didn’t you read my email last night? SerializedLayout DOES use the proxy. Read item #78 in Effective Java.
Ralph
On Mar 31, 2014, at 10:42 AM, Gary Gregory <ga...@gmail.com> wrote:
> Should the Serialized layout use the proxy?
>
> Gary
>
>
> On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> Jackson will do both the JSON and XML if you want. If you can manage to use the Proxy I think that would be better.
>
> Ralph
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> Out of curiosity, why does implementing an XML socket server require touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput going to do that would require that?
>>
>> My current working implementation uses JAXB annotations on Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can then be a one liner: JAXB.marshal(logEvent, result). Right now the socket server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>>
>> But I could do it in the existing "proxy" log event instead or a new XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an extra object. So I am asking...
>>
>> Gary
>>
>> Ralph
>>
>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> As I am working on LOG4J2-583 I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>>
>>> - LogEventProxy is used to move events across threads internally
>>> - A real Log4jLogEvent is used in the SerializedLayout.
>>>
>>> Why the different?
>>>
>>> As you answer, if you can avoid committing to Log4jLogEvent that would be great as I currently have pending changes there related to LOG4J2-583.
>>>
>>> I am wondering if SerializedLayout should use LogEventProxy or if LogEventProxy is a leftover from old development.
>>>
>>> Thank you,
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
Should the Serialized layout use the proxy?
Gary
On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> Jackson will do both the JSON and XML if you want. If you can manage to
> use the Proxy I think that would be better.
>
> Ralph
>
> On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Out of curiosity, why does implementing an XML socket server require
>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>> going to do that would require that?
>>
>
> My current working implementation uses JAXB annotations on Log4jLogEvent,
> no need to deal with messy DOM nonsense. The XML layout can then be a one
> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
> also with a one liner to convert from XML to a Log4jLogEvent.
>
> But I could do it in the existing "proxy" log event instead or a new XML
> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
> extra object. So I am asking...
>
> Gary
>
>>
>> Ralph
>>
>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>
>> - LogEventProxy is used to move events across threads internally
>> - A real Log4jLogEvent is used in the SerializedLayout.
>>
>> Why the different?
>>
>> As you answer, if you can avoid committing to Log4jLogEvent that would be
>> great as I currently have pending changes there related to LOG4J2-583.<https://issues.apache.org/jira/browse/LOG4J2-583>
>>
>> I am wondering if SerializedLayout should use LogEventProxy or if
>> LogEventProxy is a leftover from old development.
>>
>> Thank you,
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 31, 2014 at 10:21 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> Jackson will do both the JSON and XML if you want. If you can manage to
> use the Proxy I think that would be better.
>
> Ralph
>
>
Hm... I'll investigate.
Gary
>
>
>
On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Out of curiosity, why does implementing an XML socket server require
>> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
>> going to do that would require that?
>>
>
> My current working implementation uses JAXB annotations on Log4jLogEvent,
> no need to deal with messy DOM nonsense. The XML layout can then be a one
> liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
> also with a one liner to convert from XML to a Log4jLogEvent.
>
> But I could do it in the existing "proxy" log event instead or a new XML
> proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
> extra object. So I am asking...
>
> Gary
>
>>
>> Ralph
>>
>> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>
>> - LogEventProxy is used to move events across threads internally
>> - A real Log4jLogEvent is used in the SerializedLayout.
>>
>> Why the different?
>>
>> As you answer, if you can avoid committing to Log4jLogEvent that would be
>> great as I currently have pending changes there related to LOG4J2-583.<https://issues.apache.org/jira/browse/LOG4J2-583>
>>
>> I am wondering if SerializedLayout should use LogEventProxy or if
>> LogEventProxy is a leftover from old development.
>>
>> Thank you,
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Ralph Goers <ra...@dslextreme.com>.
Jackson will do both the JSON and XML if you want. If you can manage to use the Proxy I think that would be better.
Ralph
On Mar 31, 2014, at 7:04 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> Out of curiosity, why does implementing an XML socket server require touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput going to do that would require that?
>
> My current working implementation uses JAXB annotations on Log4jLogEvent, no need to deal with messy DOM nonsense. The XML layout can then be a one liner: JAXB.marshal(logEvent, result). Right now the socket server ends up also with a one liner to convert from XML to a Log4jLogEvent.
>
> But I could do it in the existing "proxy" log event instead or a new XML proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an extra object. So I am asking...
>
> Gary
>
> Ralph
>
> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> As I am working on LOG4J2-583 I ran into core.impl.Log4jLogEvent.LogEventProxy.
>>
>> - LogEventProxy is used to move events across threads internally
>> - A real Log4jLogEvent is used in the SerializedLayout.
>>
>> Why the different?
>>
>> As you answer, if you can avoid committing to Log4jLogEvent that would be great as I currently have pending changes there related to LOG4J2-583.
>>
>> I am wondering if SerializedLayout should use LogEventProxy or if LogEventProxy is a leftover from old development.
>>
>> Thank you,
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 31, 2014 at 2:36 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> Out of curiosity, why does implementing an XML socket server require
> touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput
> going to do that would require that?
>
My current working implementation uses JAXB annotations on Log4jLogEvent,
no need to deal with messy DOM nonsense. The XML layout can then be a one
liner: JAXB.marshal(logEvent, result). Right now the socket server ends up
also with a one liner to convert from XML to a Log4jLogEvent.
But I could do it in the existing "proxy" log event instead or a new XML
proxy instead of in Log4jLogEvent. I'm not sure why we'd want to create an
extra object. So I am asking...
Gary
>
> Ralph
>
> On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> As I am working on LOG4J2-583<https://issues.apache.org/jira/browse/LOG4J2-583>I ran into core.impl.Log4jLogEvent.LogEventProxy.
>
> - LogEventProxy is used to move events across threads internally
> - A real Log4jLogEvent is used in the SerializedLayout.
>
> Why the different?
>
> As you answer, if you can avoid committing to Log4jLogEvent that would be
> great as I currently have pending changes there related to LOG4J2-583.<https://issues.apache.org/jira/browse/LOG4J2-583>
>
> I am wondering if SerializedLayout should use LogEventProxy or if
> LogEventProxy is a leftover from old development.
>
> Thank you,
> Gary
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Ralph Goers <ra...@dslextreme.com>.
Out of curiosity, why does implementing an XML socket server require touching the LogEvent? What are XMLLogEventInput and JSONLogEventInput going to do that would require that?
Ralph
On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
> As I am working on LOG4J2-583 I ran into core.impl.Log4jLogEvent.LogEventProxy.
>
> - LogEventProxy is used to move events across threads internally
> - A real Log4jLogEvent is used in the SerializedLayout.
>
> Why the different?
>
> As you answer, if you can avoid committing to Log4jLogEvent that would be great as I currently have pending changes there related to LOG4J2-583.
>
> I am wondering if SerializedLayout should use LogEventProxy or if LogEventProxy is a leftover from old development.
>
> Thank you,
> Gary
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: core.impl.Log4jLogEvent.LogEventProxy
Posted by Ralph Goers <ra...@dslextreme.com>.
Unless I completely screwed up SerializedLayout should be using the proxy when the LogEvent is serialized. See item #78 in Effective Java.
Ralph
On Mar 30, 2014, at 8:04 PM, Gary Gregory <ga...@gmail.com> wrote:
> As I am working on LOG4J2-583 I ran into core.impl.Log4jLogEvent.LogEventProxy.
>
> - LogEventProxy is used to move events across threads internally
> - A real Log4jLogEvent is used in the SerializedLayout.
>
> Why the different?
>
> As you answer, if you can avoid committing to Log4jLogEvent that would be great as I currently have pending changes there related to LOG4J2-583.
>
> I am wondering if SerializedLayout should use LogEventProxy or if LogEventProxy is a leftover from old development.
>
> Thank you,
> Gary
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory