What happened to DefaultLogger and the ability to set the logging level?

[jdimeo]

Expected behavior

The DefaultLogger class was removed as was the GraphServiceClient.builder() which had a logger() with no obvious replacement. Do we have to access low level OkHttp to add a logging interceptor? All I want to do is set logging to DEBUG vs. INFO based on the user's config.

Actual behavior

No way to easily set the logging level.

Steps to reproduce the behavior

I migrated from 5.77.0 to 6.6.0

[jdimeo]

Another path that went "poof" was:

client.sites().byId(config.getSiteId()).drive().root().itemWithPath("folder/file");

I totally expect breaking changes going from 5.x.x to 6.x.x but the issue I'm facing is that I can't find a suitable replacement. I'm now stuck either using 6.x.x to get access to publishing site pages or using 5.x.x to access drive items to convert PDFs and I can't seem to do both with one version.

[Ndiritu]

@baywet requesting your help on how to configure OpenTelemetry to work with the SDK. Will add to docs.

[Ndiritu]

Another path that went "poof" was:

client.sites().byId(config.getSiteId()).drive().root().itemWithPath("folder/file");

I totally expect breaking changes going from 5.x.x to 6.x.x but the issue I'm facing is that I can't find a suitable replacement. I'm now stuck either using 6.x.x to get access to publishing site pages or using 5.x.x to access drive items to convert PDFs and I can't seem to do both with one version.

@jdimeo
To reduce the size of the generated SDK we only generate the canonical paths to entities e.g. Drive/Sharepoint etc.

You would need to fetch the drive then use it's ID to get the item:

var drive = client.sites().bySiteId(config.getSiteId()).drive().get();
var driveItem = client.drives().byDriveId(drive.getId()).items().byDriveItemId("root:/folder/file:").get();

[baywet]

@Ndiritu sure!
First off, OpenTelemetry has a sender for OkHttp, this works regardless of what kiota clients provide and will provide the low level http calls tracing information. The way it work is by wrapping around the http client. So building on this example the general configuration flow for that part of the tracing would be:

1. create the http client using the graph factory.
2. wrap it with open telemetry like they do in the example.
3. pass that wrapped client to the request adapter.
4. pass the request adapter to the graph service client.

Then kiota layers also implement additional tracing through open telemetry, it's being sent automatically, the only thing that's required it to start exporting those where-ever required.
We already have a docs issue for Kiota to document that. I'll add the Java details there.

[jdimeo]

Another path that went "poof" was:

client.sites().byId(config.getSiteId()).drive().root().itemWithPath("folder/file");

I totally expect breaking changes going from 5.x.x to 6.x.x but the issue I'm facing is that I can't find a suitable replacement. I'm now stuck either using 6.x.x to get access to publishing site pages or using 5.x.x to access drive items to convert PDFs and I can't seem to do both with one version.

@jdimeo To reduce the size of the generated SDK we only generate the canonical paths to entities e.g. Drive/Sharepoint etc.

You would need to fetch the drive then use it's ID to get the item:

var drive = client.sites().bySiteId(config.getSiteId()).drive().get();
var driveItem = client.drives().byDriveId(drive.getId()).items().byDriveItemId("root:/folder/file:").get();

Thank you for the clarification. While I totally understand the motivation here, this is going to be really hard for users because now the SDK won't match what is written in the public API docs. I've continually gotten "stuck" with 6.x.x because as I find an endpoint in the API docs that does exactly what I want, but I can't find it in the SDK, and I don't necessarily have the knowledge to know what is canonical vs. convenience.

[jdimeo]

Getting a philosophical here, my understanding of "SDK" - software development kit - is that intentionally is a "kit" of tools that make developing software to use the API easy. So I would expect convenience features like setting log to DEBUG without knowledge of OkHttp and I would expect convenient endpoints. An "API client" might just have "raw" or "canonical" mapping to the canonical endpoints but an "SDK" should have a better user experience.

The way AWS reduces size is to break out the client code by product/tool/service, but also provide a BOM if you need to mix and match multiple.