Make usage of http clients (apache, OkHttp, Jetty, Asynch) easier

Đang mở
  • Có gì không ổn?
#343 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

@ManishS6 đang làm issue này rồi.

Từ ngày 4/10/2024.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
java
Lĩnh vực
api

Hướng nghiên cứu

Bắt đầu bằng việc đọc Cloudinary.loadStrategies(), Cloudinary.class và Configuration.class để hiểu cách tải strategy hiện tại và cấu hình dựa trên Map. Xem lại cách các strategy Apache, OkHttp, Jetty và Asynch được chọn, cũng như cách cấu hình được truyền đến constructor. Done cần cung cấp một cách thức đã được quyết định và có tài liệu để consumer chọn HTTP client và cấu hình chúng mà không cần một Map không minh bạch.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Feature request for Cloudinary Java SDK

General idea: making the settings of http client library to be used easier for consumers of the SDK,
by enabling configuration via new Cloudinary(...) constructor.

Explain your use case

I want to use plain java http client, instead of Apache one.

Describe the problem you’re trying to solve

In Cloudinary.loadStrategies() there's a fixed list of strings with classnames, which a consumer of the SDK can't change.
This means even if I provide my own strategy, this will not loaded and I still being forced to add dependency for apache http.
(hint: technically: when the class om.cloudinary.http5.ApiStrategy is not found, an UnknownError is thrown, which is bad)

Also this brings me to another point: the constructor of Cloudinary should better accept Configuration object, instead of Map config. It's very annoying for me as an SDK user, to provide a Map with configs.
I get no auto-completion on Maps and must find details in either source code or documentation (which is just cumbersome).
So I don't know immediately what config options are available, that I could e.g. provide HTTP proxy address.

(Sorry, if I mix two problems here ... I came to these two, when I thought about a solution proposal, below)

Do you have a proposed solution?

YES.
The constructor of Cloudinary.class (or better the Configuration.class) could have some new field apiStrategy of type class<AbstractApiStrategy>. And another one for the UploadStrategy.
Then, the loadStragies() method will not load by name (which can contain typos), but rather by class(type) directly.

On the second problem, adding a new (overloaded) constructor to Cloudinary is easy to add, but that's not sufficient.
Ideally, the Configuration class will provide a convenient Builder function, so users of the SDK are better guided,
and plausibility checks can easier be implemented.

I'm happy to provide a PR, if this resonates with you.

Ngôn ngữ chính
Java
Star
176
Fork
113
Merge trung bình
9 ngày 20 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cloudinary/cloudinary_java

Tất cả issue của cloudinary/cloudinary_java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.