logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mi...@apache.org>
Subject Re: [log4j] Adding methods to org.apache.logging.log4j.core.appender.nosql.NoSqlObject<W>
Date Thu, 25 Jan 2018 20:28:18 GMT
Is it really that useful to have "NoSQL" as an abstraction in the first 
place? Is there that much code to share?


On 2018-01-22 21:43, Gary Gregory wrote:
> On Mon, Jan 22, 2018 at 12:30 PM, Matt Sicker <boards@gmail.com> wrote:
> 
>> Back when I wrote the initial CassandraAppender implementation, I found the
>> existing NoSQL interfaces to be too restrictive. I found a similar problem
>> long ago when I was experimenting with a DynamoDB appender. Most NoSQL APIs
>> I've used tend to accept a generic Map for documents/records, and it was
>> only the Mongo API that had its own thing going on.
>>
> 
> The good news is that the new log4j-mongodb3 appender that I have ready but
> not committed (see "The Shape of Log4j" thread) is based on BSON Documents
> which implement java.util.Map, so that would be a good clean up.
> 
> Maybe we could bypass this NoSqlObject-vs-NoSqlObject2 issue with a new
> interface NoSqlMapObject instead of NoSqlObject?
> 
> I've not looked at the other appenders though...
> 
> Gary
> 
>>
>> With that in mind, I'd support breaking that API and redoing it entirely so
>> it's not as specific to Mongo/Couch. I think I still have a backlog item
>> about implementing a DynamoDB appender, and I'd also like to see something
>> similar eventually for Elasticsearch (which I've been working with
>> extensively lately).
>>
>> On 21 January 2018 at 23:47, Gary Gregory <garydgregory@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> The interface org.apache.logging.log4j.core.
>> appender.nosql.NoSqlObject<W>
>>> requires arrays in two methods:
>>>
>>> set(String, NoSqlObject<BasicDBObject>[])
>>> set(String, Object[])
>>>
>>> For some providers like the new MongoDB driver 3.x provider I am working
>> on
>>> this causes double work. First the log4j NoSQL guts converts a list into
>> an
>>> array
>>> in org.apache.logging.log4j.core.appender.nosql.NoSqlDatabaseManager.
>>> setFields(LogEvent,
>>> NoSqlObject<W>):
>>>
>>> entity.set("contextStack", contextStack.asList().toArray());
>>>
>>> Then, the new NoSqlObject impl I have converts that array back into a
>> list
>>> to pass to Mongo.
>>>
>>> If I wanted to add List versions of the two array APIs in NoSqlObject,
>>> should I:
>>>
>>> - Just add-em and adjust all providers.
>>> - Create a NoSqlObject2 sub-interface
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com>
>>
> 


Mime
View raw message