I just proposed [PR#183016](https://gerrit.libreoffice.org/c/core/+/183016) enabling this new functionality.

I don't think anything is needed here.  As I said in the comment at <https://gerrit.libreoffice.org/c/core/+/181159/11#message-9fe9e1174a481bdbbe46cee415f471ef5017e447> "Add Instrumentation to JVM":

> Everybody can already specify their preferred `-javaagent:/path/to/my/jar` under "Tools - Options... - LibreOffice - Advanced - Java Options - Parameters..."

Yes, we can achieve the same functionality with the option you indicate, but not at all the same deployment.

I can't find the JVM loading arguments in the LibreOffice configuration and I'm not sure if they are recorded there?

So, for an extension to use an instrumentation agent, the following steps are necessary:
- Download the instrumentation agent archive (ie: instrumentagent.jar).
- Place this download in a folder (ie: archivefolder).
- Modify the JVM startup arguments in the LibreOffice options to add:
  -javaagent:archivefolder/instrumentagent.jar
- restart LibreOffice

I don't want to require my extension users to go through such a process. It wouldn't be reasonable.

The PR I'm proposing allows an extension to use a Java instrumentation agent just by installing it. The user doesn't have to do anything else...

So, of course, we have the same functionality, but your solution is reserved for experienced users.

(In reply to prrvchr from comment #3)
> The PR I'm proposing allows an extension to use a Java instrumentation agent
> just by installing it. The user doesn't have to do anything else...

I'm not convinced.  For one, my naive understanding is that Java agents are a means for debugging and monitoring.  Something done by technically skilled people, for which the existing way of enabling such a Java agent should presumably be tolerable.

But, more importantly, for another, and as I already had tried to explain elsewhere:  The LO code instantiating a JVM (jvmaccess, jvmfwk, stoc; all part of URE) cannot access the LO configuration (configmgr, officecfg; both not part of URE).  So, you would first need to address that if using officecfg is a central piece of what you want to achieve here.  (And it wasn't clear to me until your comment 3 above that that shall indeed be a central piece here.)  But _if_ we ever wanted to let the LO code instantiating a JVM have access to the LO configuration, I would rather move all of LO's JVM configuration machinery over to the configmgr/officecfg-based LO configuration, instead of arbitrarily having a single InstrumentationAgentArchive in officecfg and the rest stay in the existing JVM configuration machinery.

Here is part of the copy of my initial request:

> If we want to make this feature accessible to any extension written in Java, it is necessary to make three modifications:
> - Add the UnoAgent.jar archive to the SDK.
> - Add an entry in the LibreOffice configuration (ie: xcu file) to enable or disable instrumentation.
> - Load the JVM with the parameters needed for instrumentation depending on the configuration.
> Please let me know what you think about this.

To this request, Noel Grandin responded:

> It sounds quite reasonable to add this to the core product behind an option.

I've always said that it's necessary to add an option in the configuration if we want to make this usable. This is even the primary reason for my PR.

> But, more importantly, for another, and as I already had tried to explain elsewhere:
> The LO code instantiating a JVM (jvmaccess, jvmfwk, stoc; all part of URE) cannot access the LO configuration (configmgr, officecfg; both not part of URE).

The only Java-related settings I found in the configuration are:
- VirtualMachine/Security
- VirtualMachine/NetAccess
- VirtualMachine/RunUnoComponentsOutOfProcess

These three options are read from the javavm.cxx file line 345 and for now I have not found another place where the configuration for Java is used. So I don't really see any reason to have to move the reading of the Java configuration.

The instrumentation agent will allow me to redirect the use of the JVM's java.lang.System.Logger interface to the UNO singleton com.sun.star.logger.LoggerPool and thus make the logging of all Java applications using System.Logger accessible in LibreOffice.
This should be a checkbox in the jdbcDriverOOo configuration to enable this option. I don't want to ask users to: download a file then change the JVM startup options and finally change the JVM ClassPath when I can do the same thing by adding 50 lines of code in LibreOffice. And it was never meant to be done by technically skilled people. Normally what I write, my mother should be able to use it, and it's a pickaxe.

(In reply to prrvchr from comment #5)
> The only Java-related settings I found in the configuration are:
> - VirtualMachine/Security
> - VirtualMachine/NetAccess
> - VirtualMachine/RunUnoComponentsOutOfProcess
> 
> These three options are read from the javavm.cxx file line 345 and for now I
> have not found another place where the configuration for Java is used. So I
> don't really see any reason to have to move the reading of the Java
> configuration.

Ah, right, there already is some places where we optionally make use of the configmgr/officecfg-based configuration in the stoc JVM loading machinery, if and when it is available, in stoc/source/javavm/javavm.cxx and in stoc/source/javaloader/javaloader.cxx.

I just updated the PR so that it can support loading multiple agents as provided by the -javaagent Java option since version 8.

prrvchr committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fabdac1af8d30f849a94defd516d6699945f908d

tdf#165774 Support for Java instrumentation

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

@Stephan Bergmann, maybe it would be good to backport to 25.2:

- Avoid exception when reading nil NetAccess value <https://gerrit.libreoffice.org/c/core/+/183268>
- configmgr: Let XRegistryKey::getLongValue return boolean values, too <https://gerrit.libreoffice.org/c/core/+/183269>
- tdf#165774 Support for Java instrumentation <https://gerrit.libreoffice.org/c/core/+/183280>

In my opinion, all existing code in getJavaPropsFromSafetySettings in stoc/source/javavm/javavm.cxx was broken and there is no risk in replacing dead code.

(In reply to prrvchr from comment #9)

> - Avoid exception when reading nil NetAccess value
> <https://gerrit.libreoffice.org/c/core/+/183268>
> - configmgr: Let XRegistryKey::getLongValue return boolean values, too
> <https://gerrit.libreoffice.org/c/core/+/183269>

The above two commits address issues that had been like that since ~forever (and which apparently never caused much of an issue), so I see no reason for a backport.

> - tdf#165774 Support for Java instrumentation
> <https://gerrit.libreoffice.org/c/core/+/183280>

The above commit implements a new feature, so I see no reason for a backport.

> The above commit implements a new feature, so I see no reason for a backport.

Provide access to the new functionality immediately and not in 6 months or even in two years for those who are on Linux and who install the LibreOffice version provided with the system.

The next version of jdbcDriverOOo is eagerly awaiting this feature, what is your good reason that justifies having to wait another six months?

(In reply to prrvchr from comment #11)
> > The above commit implements a new feature, so I see no reason for a backport.
> 
> Provide access to the new functionality immediately and not in 6 months or
> even in two years for those who are on Linux and who install the LibreOffice
> version provided with the system.
> 
> The next version of jdbcDriverOOo is eagerly awaiting this feature, what is
> your good reason that justifies having to wait another six months?

The good reason is that minor releases are not meant for adding features, but to stabilise features, reworks and changes made as part of a major release.

https://wiki.documentfoundation.org/ReleasePlan

"... users get a new major release every six months with a wide range of features, fixes and enhancements. They will also receive many bug-fixing micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.3/X.Y.4 bugfix release."

@Buovjaga

I understand, but this is only a deliberate choice, because technically this new feature could be ported to LibreOffice 5.x.

Perhaps it's time to review this way of managing LibreOffice versioning and allow the introduction of new features (ie: medium version) on the latest published version and no longer force ourselves to wait for the release of the next version, which could take six months at worst.

(In reply to prrvchr from comment #13)
> @Buovjaga
> 
> I understand, but this is only a deliberate choice, because technically this
> new feature could be ported to LibreOffice 5.x.
> 
> Perhaps it's time to review this way of managing LibreOffice versioning and
> allow the introduction of new features (ie: medium version) on the latest
> published version and no longer force ourselves to wait for the release of
> the next version, which could take six months at worst.

From a quality assurance perspective, it is not the time to review this way. We constantly run into situations, where a new feature is introduced just before the branching of a major version and then the one month of time for the broader testing community to exercise it is not enough. A clear recent example is the theming rework. Yes, Java instrumentation doesn't have the same level of visibility as theming, but if we started making exceptions we would be spending a disproportionate amount time evaluating what goes through because in fairness it would need committee rather than dictatorial decision making.