-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Expose ChannelInitializerHolder in protocol module #3776
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
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()?
Thanks |
Please give plugin developers a way to replace the channel initializer. Making everything private and final might look good, but makes using reflection for injection a terrible experience. E.g., add |
Third party plugins using the API provided in SpigotMC#3776 need to reorder their own pipeline elements as soon as the compression is enabled, which is currently not possible (at least not in a proper way without delaying packets). This PR adds a simple netty signal which can be used for this very use-case and is provided similar in other proxy/server projects as well.
…e new [BungeeCord ChannelInitializer API](SpigotMC/BungeeCord#3776) - Updated the `bungeecord-proxy` dependency to 1.21.-R0.1-SNAPSHOT - Added a message when running an outdated bungeecord version (that doesn't support the new ChannelInitializer API) *Kept one and ported one funny comment* **Users are advised to upgrade their bungeecord proxies!**
* - Ported some changes from geyser/floodgate where they switched to the new [BungeeCord ChannelInitializer API](SpigotMC/BungeeCord#3776) - Updated the `bungeecord-proxy` dependency to 1.21.-R0.1-SNAPSHOT - Added a message when running an outdated bungeecord version (that doesn't support the new ChannelInitializer API) *Kept one and ported one funny comment* **Users are advised to upgrade their bungeecord proxies!** * Updated the pullrequest workflow to use upload-artifact@v4 instead of the deprecated v2 * Forgot to delete an old util file that is no longer needed because of the BungeeCord ChannelInitializer API * Removed an unused class related to skins that caused an error on Java 8 * Upgraded push request workflow to java 17
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