jerryshao commented on PR #5634: URL: https://github.com/apache/gravitino/pull/5634#issuecomment-2517076176
> > > > I think we should not simply delete this configuration, it would be better to 1) make it deprecated; 2) keep the compatible if user set this configuration; 3) warn user that this configuration is deprecated. > > > > > > > > > I'm not 100% clear on why we only need to deprecate it. The change in PR is a compatibility modification, and the previous one was not very elegant in design. > > > for the user which uses `fs.gvfs.filesystem.providers` in 0.7.0 will definitely work in 0.8.0 after this change is merged. > > > > > > Can you please explain more why it is compatible? > > In 0.7.0, If the user does not specify `fs.gvfs.filesystem.providers` , it won't work even though the corresponding bundle jar has been placed in the classpath. > > After this PR is merged, if users: > > 1. Assign `fs.gvfs.filesystem.providers` a value like `s3`, this configuration will not take effect, as long as the AWS-bundle are in the classpath, the GVFS client can always use it. > 2. Do not set `fs.gvfs.filesystem.providers` a value, the GVFS client will automatically load all file system providers in the classpath, things are also okay. > > The only difference is that if users put `aws-bundle` and `gcs-bundle` in the classpath, and then they do not assign a value to `fs.gvfs.filesystem.providers`, Gravitino will throw exceptions in 0.7 but work well in 0.8.0. In my opinion, the behavior in 0.8.0 is more acceptable and reasonable. GVFS clients should be transparent to file system providers. > > Please correct me if I'm wrong, thanks. I see, thanks for the explanation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
