-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose ChannelInitializerHolder in protocol module #3776
base: master
Are you sure you want to change the base?
Expose ChannelInitializerHolder in protocol module #3776
Conversation
I think if we're going to go down this path it should be a proper factory design |
Can you tell me what a proper factory design looks like for you? |
…to make-channel-init-accessable # Conflicts: # protocol/src/main/java/net/md_5/bungee/protocol/holder/ChannelInitializerHolder.java # proxy/src/main/java/net/md_5/bungee/netty/PipelineUtils.java
* Holds the channel initializer for incoming connections | ||
*/ | ||
@Getter | ||
private static BungeeChannelInitializer frontendHolder; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these shouldn't be static
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should i put the non static objects into BungeeCord.java and make them accessable via
ProxyServer.getInstance().unsafe()?
As the protocol module already exposes netty, i think its the best to also put this ChannelInitializerHolder here.
It allows for big plugins like Geyser and ViaVersion to access and modify the channel initializers of the serverchild and backendconnector.
This PR makes the development of software that modifies the networking much easier
I tried to impl it as simple as possible, and expose only the ChannelInitilizers in a nice way