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

Abierto
  • ¿Algo no está bien?
#343 6 comentarios 0 reacciones 0 asignados Ver en GitHub

@ManishS6 ya está trabajando en esto.

Desde el 4/10/2024.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java
Área
api

Línea de trabajo

Empieza leyendo Cloudinary.loadStrategies(), Cloudinary.class y Configuration.class para entender la carga actual de estrategias y la configuración basada en Map. Revisa cómo se seleccionan las estrategias Apache, OkHttp, Jetty y Asynch, y cómo llega la configuración al constructor. Done debería proporcionar una forma decidida y documentada para que los consumidores seleccionen clientes HTTP y los configuren sin un Map opaco.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
176
Forks
113
Merge medio
9 d 20 h
PR fusionados (30 d)
2

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudinary/cloudinary_java

Todos los issues de cloudinary/cloudinary_java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.