[somewhereinbelgium]

Yes it would speed progress - progress in the wrong direction. What we're doing is pointing you to supported approaches. If you continue to try to find undocumented alternative approaches, that just means that after a lot of effort, you'll have something that breaks next time you upgrade.

Fair enough - point taken. Can I make a feature request and that is for a documented way to register dynamically generated DataSources. I believe, from looking at other threads, that I am not the only one who is generating DataSource instances at runtime so perhaps this would be a great API alternative to saving the XML definition on the hard disk at runtime?

The great thing about being able to register the DataSource is that then all processing goes via the usual RPCManager.parseRequest/DSRequest.parseUploadedFiles chain as per usual and then I handle the update in my overridden IDACall.handleDSRequest method which contains just regular stuff to write the data to SQL Server. I certainly don't have to override IDACall.service which I am VERY :-) happy about.

[Isomorphic]

The recommended way to create DataSources dynamically is to use the server-side API DataSource.fromXML(). Writing XML to disk is a separate approach you might consider. Dynamic DataSource registration has significant lifecycle and concurrency issues - something like this may be available eventually, but it wouldn't be simpler than fromXML().

[somewhereinbelgium]

The recommended way to create DataSources dynamically is to use the server-side API DataSource.fromXML().

I am already using DataSource.fromXML() to create the DataSource.

Dynamic DataSource registration has significant lifecycle and concurrency issues

Each generated datasource serves a particular client request and has a system wide unique id - they are never shared - so how is it possible that there can be concurrency issues?

So what you're saying is you have a publically accessible class named DataStructCache with the following method

public static void addCachedObjectWithNoConfigFile(String typeName, Object config)

which performs precisely what I need but you say

something like this may be available eventually

Sorry but am I missing something?

[Isomorphic]

Documented = supported. We do not use the Java "public" qualifier to indicate that an API is supported, we use whether it appears in JavaDoc.

Your particular case doesn't have concurrency issues, but it does have lifecycle issues (you will leak memory). So, if you need features in this area, please consider sponsoring them, otherwise, use of internal APIs is strictly at your own risk.