Re: Considering porting DI to 2.x

I propose we continue this discussion in the upcoming video call. It is scheduled for the 1st of May. I have added this subject to the meeting notes as a to-be-discussed. On Mon, Apr 18, 2022 at 10:15 PM Ralph Goers wrote: > > > > On Apr 18, 2022, at 9:21 PM, Volkan Yazıcı wrote: > > > > Thanks

Re: Considering porting DI to 2.x

Lol. Ok An app running in Java 11. That changes nothing. We can certainly make some incompatible changes but as we have previously discussed some of the things you removed will have to be reverted. Making Log4J 3 not backward compatible would be a disaster. Ralph > On Apr 18, 2022, at 5:07 PM,

Re: Considering porting DI to 2.x

"an app will certainly be able to replace their 2.x jars with 3.x jars and continue to work" Certainly not since 3.x requires Java 11. Gary On Mon, Apr 18, 2022, 18:19 Ralph Goers wrote: > I have no idea what you are referring to. > > You are talking about having log4j 2 and log4j 3 jars prese

Re: Considering porting DI to 2.x

On Mon, Apr 18, 2022, 18:19 Ralph Goers wrote: > I have no idea what you are referring to. > > You are talking about having log4j 2 and log4j 3 jars present in the > application > at the same time? You can no more do that than you can have a > log4j-core.2.17.1 > jar and a log4j-core-2.17.2 jar o

Re: Considering porting DI to 2.x

I have no idea what you are referring to. You are talking about having log4j 2 and log4j 3 jars present in the application at the same time? You can no more do that than you can have a log4j-core.2.17.1 jar and a log4j-core-2.17.2 jar on the classpath at the same time. But an app will certain

Re: Considering porting DI to 2.x

How can they coexist when they use the same package names? This is why I want to use a different package name root for 3.x, like org.apache.log4j3 or something like that. On Mon, Apr 18, 2022, 17:07 Ralph Goers wrote: > Gary, that really doesn’t say anything. 2.x and 3.x are already designed > t

Re: Considering porting DI to 2.x

Sorry, it occurs to me that you may be implying that stuff written for 3.x should also work in 2.x. That would be a bit strange from a semantic versioning standpoint. In addition, because we have moved the plugin support to its own module in 3.x stuff written for it can’t compile in 2.x. Howe

Re: Considering porting DI to 2.x

Gary, that really doesn’t say anything. 2.x and 3.x are already designed to be able to coexist. Ralph > On Apr 18, 2022, at 10:50 PM, Gary Gregory wrote: > > For my 2c, the better internals are not going to motivate the majority of > users to update to 3.0, features are. It might be different

Re: Considering porting DI to 2.x

For my 2c, the better internals are not going to motivate the majority of users to update to 3.0, features are. It might be different for plugin authors, but how many of those are there? My guess is a minuscule amount. I agree that 2.x should live for a long long time, and should be able to coexist

Re: Considering porting DI to 2.x

> On Apr 18, 2022, at 9:21 PM, Volkan Yazıcı wrote: > > Thanks for your prompt reply Pitor, but I think we have a misunderstanding > here. > > For one, my problem is not simply about `@RequiredClass`, Jackson, etc. I > can solve this with a hardcoded if/else clause in JTL. My point is: there

Re: Considering porting DI to 2.x

See below. > On Apr 18, 2022, at 8:29 PM, Volkan Yazıcı wrote: > > On Mon, Apr 18, 2022 at 10:17 AM Ralph Goers > > wrote: > >>> On Apr 17, 2022, at 10:42 PM, Volkan Yazıcı wrote: >>> Thanks for raising this subject Matt, I am certainly interested in >> port

Re: Considering porting DI to 2.x

Thanks for your prompt reply Pitor, but I think we have a misunderstanding here. For one, my problem is not simply about `@RequiredClass`, Jackson, etc. I can solve this with a hardcoded if/else clause in JTL. My point is: there are places in the code where plugins are loaded, they all employ diff

Re: Considering porting DI to 2.x

Hi Volcan, On Sun, 17 Apr 2022 at 22:42, Volkan Yazıcı wrote: >1. I was working on LOG4J2-3082 (support external serializers, e.g., >Jackson, in JTL) and there I needed `@RequiredClass`. Ralph already >implemented this in `master`, I just need to copy it to `release-2.x`, >after

Re: Considering porting DI to 2.x

On Mon, Apr 18, 2022 at 10:17 AM Ralph Goers wrote: > > On Apr 17, 2022, at 10:42 PM, Volkan Yazıcı wrote: > > Thanks for raising this subject Matt, I am certainly interested in > porting > > the plugin system in 3.x to 2.x for a very simple reason: because plugins > > are broken in 2.x. Let me

Re: Considering porting DI to 2.x

> On Apr 17, 2022, at 10:42 PM, Volkan Yazıcı wrote: > > Thanks for raising this subject Matt, I am certainly interested in porting > the plugin system in 3.x to 2.x for a very simple reason: because plugins > are broken in 2.x. Let me elaborate on this and some more: > > 1. I was working o

Re: Considering porting DI to 2.x

Those are good points. To me, the fact that 2.x will be around for a long time is one of the main reasons why I even considered this idea. I’d like to hear more from the community first, though. — Matt Sicker > On Apr 17, 2022, at 15:42, Volkan Yazıcı wrote: > > Thanks for raising this subje

Re: Considering porting DI to 2.x

Thanks for raising this subject Matt, I am certainly interested in porting the plugin system in 3.x to 2.x for a very simple reason: because plugins are broken in 2.x. Let me elaborate on this and some more: 1. I was working on LOG4J2-3082 (support external serializers, e.g., Jackson, in JTL

Re: Considering porting DI to 2.x

On Sat, Apr 16, 2022 at 11:31 PM Matt Sicker wrote: > > Features only available in DI have been asked about in a couple different > situations already in 2.x development. Whatever those features may be, I think that "use 3.0" is a reasonable reply ti such requests. Jochen -- Philosophy is use

Re: Considering porting DI to 2.x

I’ll defer the justification to those who were interested in the idea. I also lean toward 3.x, but I’ve already prepared most of the code necessary to back port this already. Otherwise, I’d also emphasize working on 3.0.0. — Matt Sicker > On Apr 16, 2022, at 18:14, Gary Gregory wrote: > > I

Re: Considering porting DI to 2.x

I was ok w it either way but I do understand Ralph's POV. So maybe leave 2.x alone in this department, unless there is an issue this would solve that I missed. Gary On Sat, Apr 16, 2022, 18:04 Ralph Goers wrote: > The question isn’t can it be. The question is, should it be. At this point > I do

Re: Considering porting DI to 2.x

The question isn’t can it be. The question is, should it be. At this point I don’t see why it should. It is necessary in 3.0 to accomplish some of the things we want to do there. But at this point I don’t think we should be doing major things to 2.x. Ralph > On Apr 16, 2022, at 11:31 PM, Matt

Re: Considering porting DI to 2.x

Features only available in DI have been asked about in a couple different situations already in 2.x development. I don’t plan on porting _all_ the changes I made in 3.x (such as the various startup optimizations, removal of deprecated code, and making all the existing system property based class

Re: Considering porting DI to 2.x

A) Why? B) I am not really a fan of this. I’d prefer to leave this major of a change for 3.0 unless there is a very compelling reason to do it sooner. I’d prefer to focus on getting 3.0 out sooner. Ralph > On Apr 16, 2022, at 7:14 PM, Matt Sicker wrote: > > Hey all, I’m considering porting th

Considering porting DI to 2.x

Hey all, I’m considering porting the new DI system back to 2.x (but put all in core as there’s no plugins module there) as there seems to be interest in using this earlier than in 3.0. While I’d be willing to do this, I wanted to see what anyone else thinks about the idea. I’d likely begin on a