Allow subclasses to be used to customize server behavior

Bắt đầu bằng cách đọc McpAsyncServer, đặc biệt là package-private constructor và các entry point prepareRequestHandlers, prepareNotificationHandlers và setSessionFactory được nêu trong issue. So sánh các lớp server gốc khác, bao gồm McpSyncServer và McpStateless*, đồng thời xem xét yêu cầu về khả năng mở rộng liên quan trong issue #525. Công việc được hoàn tất khi người dùng SDK có thể tùy chỉnh các tính năng, quá trình khởi tạo, việc tạo session và kiểu session, cùng hành vi liên quan của server mà không cần triển khai lại server.

What I say below is (mostly) appropriate to the other types of server classes (i.e. McpSyncServer, McpStateless*), but I'm going to focus specifically on McpAsyncServer current impl for clarity.

Currently the McpAsyncServer constructors are package private...e.g.

	/**
	 * Create a new McpAsyncServer with the given transport provider and capabilities.
	 * @param mcpTransportProvider The transport layer implementation for MCP
	 * communication.
	 * @param features The MCP server supported features.
	 * @param jsonMapper The JsonMapper to use for JSON serialization/deserialization
	 */
	McpAsyncServer(McpServerTransportProvider mcpTransportProvider, McpJsonMapper jsonMapper,
			McpServerFeatures.Async features, Duration requestTimeout,
			McpUriTemplateManagerFactory uriTemplateManagerFactory, JsonSchemaValidator jsonSchemaValidator) {
		this.mcpTransportProvider = mcpTransportProvider;
		this.jsonMapper = jsonMapper;
		this.serverInfo = features.serverInfo();
		this.serverCapabilities = features.serverCapabilities().mutate().logging().build();
		this.instructions = features.instructions();
		this.tools.addAll(withStructuredOutputHandling(jsonSchemaValidator, features.tools()));
		this.resources.putAll(features.resources());
		this.resourceTemplates.putAll(features.resourceTemplates());
		this.prompts.putAll(features.prompts());
		this.completions.putAll(features.completions());
		this.uriTemplateManagerFactory = uriTemplateManagerFactory;
		this.jsonSchemaValidator = jsonSchemaValidator;

		Map<String, McpRequestHandler<?>> requestHandlers = prepareRequestHandlers();
		Map<String, McpNotificationHandler> notificationHandlers = prepareNotificationHandlers(features);

		this.protocolVersions = mcpTransportProvider.protocolVersions();

		mcpTransportProvider.setSessionFactory(transport -> {
			String sessionId = UUID.randomUUID().toString();
			return new McpServerSession(sessionId, requestTimeout, transport, this::asyncInitializeRequestHandler,
					requestHandlers, notificationHandlers, () -> this.cleanupForSession(sessionId));
		});
	}

Among other things, this means that users of the sdk cannot customize the server runtime behavior, as they are essentially forced to use not only the static factory methods, but also cannot provide custom features on construction nor customize the server initialization via the methods called in the constructor: prepareRequestHandlers, prepareNotificationHandlers, and importantly: setSessionFactory (which also means that the sessionid creation cannot be altered, nor the type of the McpServerSession.

In some servers the calling of setSessionFactory wants to be delayed, so that construction/initialization of members (feature contents, prepare method), can be separated from putting the server online by setting the session factory.

Use Case - Extensions

To implement some extensions, such as grouping and primitive update it's necessary to customize the feature set, initialization, factory setting session type and in some cases optionally override methods of McpAsyncServer (e.g. notification sending and contents) (which further need to access currently private members...e.g. list of tools, resources, primitives. With the current permissions, to do this customization would mean having to re-implement McpAsyncServer...outside of it's existing package, which seems like an unnecessary burden on sdk developers.

Also, there have been several unrelated community requests for sdk server extensibility here:

https://github.com/modelcontextprotocol/java-sdk/issues/525

I request that the McpAsyncServer (and other server root classes) be made more extensible by sdk consumers.

I understand that composition might be preferable architecturally, but to allow such composition would currently require a major refactoring and generalization of the server classes, so it seems that making members, constructors, and methods protected might be better in the short term.

Another option for implementing...that would retain binary backward compatibility...would be to introduce abstract super class(es) (for McpAsyncServer) and expose the relevant constructors, members, initialization methods in the abstract super class(es).