Hi,
The incubation list for for conversations about new project proposals, releases
and graduations and similar things. I think this thread has got off topic and
you should probably carry on the conversation back on the logging project lists.
Building a community around EOLed software, even if
The JMSAppender is an optional module. I think you will get the distinction. It
doesn’t break the world to remove it, unlike changing the class hierarchy of
Appender or removing a method on an extension interface used by same, I think
the distinction is clear. We might find agreement in the resp
> On Jan 8, 2022, at 19:39, Andrew Purtell wrote:
>
>> Are you using the JMS appender? Are you using the socket receiver? If the
> answer is no to those questions, you don’t have security concerns besides
> the more glaring fact that you’re depending on end of life software that
> has been marke
In this current form this discussion belongs either on dev@logging or board@.
Several people here are perfectly capable of forming a proposal, but are
choosing to have an unproductive discussion.
At this point a new podling would be a hostile fork and those are not accepted.
Sent from my iPhone
The discussion continues here because the Logging PMC is intransigent and
non-responsive to the concerns already well established by parties on this
thread. I don't see how this can be resolved without you "giving in".
Perhaps that is the problem, but I don't want to be an armchair
psychiatrist, I
> Are you using the JMS appender? Are you using the socket receiver? If the
answer is no to those questions, you don’t have security concerns besides
the more glaring fact that you’re depending on end of life software that
has been marked as such for going on 7 years now.
I know you keep returning
> On Jan 8, 2022, at 4:34 PM, Andrew Purtell wrote:
>
> The Logging PMC is the hostile party here as far as I can tell, operating
> in defiance of the community of users that have made the points I have just
> written here abundantly clear for years.
The Logging PMC is the owner of Log4j 1.x.
How about we put this lines into the proposal to address the concern?
BTW, Baidu has a commercial product which is based on the HugeGraph.
I think it fine as long as the commercial product flow The Apache trademark
policy[1] and keep the HugeGraph code clean.
[1]https://www.apache.org/foundation
Answers below:
> On Jan 8, 2022, at 17:34, Andrew Purtell wrote:
>
> Log4J 1 has known concurrency issues but many projects live with them or
> work around them. For example, several "Big Data" Apache projects have been
> fine with it, themselves internally highly concurrent and performance
> se
Log4J 1 has known concurrency issues but many projects live with them or
work around them. For example, several "Big Data" Apache projects have been
fine with it, themselves internally highly concurrent and performance
sensitive. Log4J 1 might not be a Platonic ideal, but certainly good
enough, as
On Sat, 8 Jan 2022 at 20:46, Craig Russell wrote:
>
> Hi Josh,
>
> > On Jan 8, 2022, at 7:45 AM, Josh Innis wrote:
> >
> > Hi Craig,
> >
> > John Gemingnani (john.gemign...@bitnine.net) is mapped to the github
> > address jrgemignani. If John isn't getting credit for his work: we need to
> > fix
The problem with v1 is that it doesn’t “just work”. There are numerous dead
locks and other concurrency problems that were unable to be fixed without
breaking various points of compatibility which is why Logback and Log4j2 even
exist rather than continuing v1. There would also be difficulty in m
Hi Josh,
> On Jan 8, 2022, at 7:45 AM, Josh Innis wrote:
>
> Hi Craig,
>
> John Gemingnani (john.gemign...@bitnine.net) is mapped to the github
> address jrgemignani. If John isn't getting credit for his work: we need to
> fix this immediately.
The problem here is that John is subscribed to th
Hi Matt,
Thanks for replying. I think the main issues I found following the guide [1]
for Apache CloudStack (ACS) are:
- APIs are not backward compatible fully, certainly everywhere the imports have
to be fixed
- The config xml files are not fully compatible requiring some changes
- Our codebas
It would be nice if you filed any issues with Log4j2 about problems with
migration. It would have been nice to hear about these issues back when v1
stopped development, but this is the next best time to do so. The Log4j team
are actively working to fill in any remaining gaps on backward compatib
Hi all,
I agree and extend support for Andrew's remarks. Apache CloudStack too uses
log4j 1.x and our use case is simply a logging library that 1.x just satisfies.
The effort to migrate to 2.x is not quick, at least in our initial
investigation and a migration may likely require huge effort in
Hi
Yes I'm sure all the relevant repos at GitHub/hugegraph [1] will be donated
to ASF.
At present, there are more than 10 sub-projects. For the convenience of
management, we plan to merge them into 4 sub-projects [2].
Some demo projects may be ignored(like hugegraph-plugin-stanford-analyzer),
but
17 matches
Mail list logo
