I won't touch the modules. I think we need hash it out a little more and
get a consensus.
If there are 2 modules: JPA and JDBC, then the generic .db package needs to
stay in log4j-core. Which would be OK for now.
Gary
On Fri, Jan 12, 2018 at 11:16 PM, Remko Popma wrote:
> Okay perhaps just two
Okay perhaps just two modules then?
By the way, I have work in progress on the high-precision time stamps that
would be impacted by this. I would like to avoid the merge conflict by
postponing this module breakdown until that is merged. Is that possible?
(Shameless plug) Every java main() metho
The reason to split out JPA would be to avoid bringing in the dependency to
javax.persistenance which is not in the JRE. The JDBC API OTOH is in the
JRE.
Gary
On Fri, Jan 12, 2018 at 10:14 PM, Remko Popma wrote:
> How about moving all of these (generic database support, jdbc and jpa)
> together
How about moving all of these (generic database support, jdbc and jpa) together
into a single separate module?
Something like:
log4j-db
I don’t see much value into splitting them up further, but perhaps that’s just
me.
Remko
(Shameless plug) Every java main() method deserves http://picocli
Hi All:
I wonder if we should move the JDBC Appender to its own module.
Also wondering how we would then slice and dice the generic database
support and the JPA Appender:
- log4j-db
- log4j-jdbc
- log4j-jpa
Those would all be small modules...
?
Thank you,
Gary
Gary, this really doesn’t make sense.
Now If I do:
MapMessage msg = new MapMessage<>();
msg.with(“count”, 5);
msg.with(“amount”, 1.01);
msg.with(“text”, “Hello”);
Map map = msg.getData();
I am going to get back a Map where all the values are Strings because getData()
has cast them to Strings wh
On Fri, Jan 12, 2018 at 10:47 AM, Gary Gregory
wrote:
> On Fri, Jan 12, 2018 at 12:33 AM, Ralph Goers
> wrote:
>
>> Then I don’t understand why you modified MapMessage to be
>>
>> public class MapMessage, V>
>> and the getData method returns has the signature
>>
>> public Map getData()
>>
>> If
On Fri, Jan 12, 2018 at 12:33 AM, Ralph Goers
wrote:
> Then I don’t understand why you modified MapMessage to be
>
> public class MapMessage, V>
> and the getData method returns has the signature
>
> public Map getData()
>
> If you are putting arbitrary stuff in the Map then this signature is wro
I'm working on LOG4NET-566, hoping that we can get a release build from
our CI. The build currently gets stuck because of an unknown reason. It
would be great to get some help on finding out why the heck the
netstandard-1.3 tests behave as they do here:
https://builds.apache.org/job/logging-lo
