Does my suggestion address your concern or do you feel we need to go another way about it?

ah - you mean with the exact same jar name - I didn’t try that - it must work

I have the feeling that removing the jar file manually on the operating system can have other consequences

I suspect removing the jar from the base and then re-inserting the C3P0 jar in to base would be the way to go.

As far is Equinox is concerned nothing has changed because the plugin ID, name, etc has not changed. Therefor any reference Equinox might have to the plugin will still work (like the file defining runlevels for example).

Thanks

Must be something related to the “base” plugins, those that are installed at the installer.

From what I see:

• Felix and OSGi console install the plugins in a file, somewhere like: configuration/org.eclipse.osgi/[plugin_number]/0/bundleFile

• The plugins installed in the base are located in the plugins folder

• From OSGi console you can install/uninstall the plugins installed in the configuration/org.eclipse.osgi folder

• But, from what I see here, it seems I cannot uninstall from OSGi console the plugins from the plugins folder

• So, wondering what would be the right way to uninstall a base plugin. I have the feeling that removing the jar file manually on the operating system can have other consequences

for some reason it cannot be removed using the OSGi console as it appears again on restart

My memory is a bit hazy on the subject but as far as I know you can’t “delete“ plugins from the OSGi console (meaning deleting the actual JAR) with neither Felix nor Equinox. You can only transition their lifecycle to “uninstalled“. But as soon as you restart the OSGi runtime it will load it’s bundles as it normally would. There is no “persistence“ of the commands you enter in the OSGi console in that regard.

Well - I did a test and it worked partially fine:

• generated plugin org.compiere.db.postgresql.provider from current master (c3p0)

• deployed a server with the hikaricp version

• started the server

• using OSGi console I tried to uninstall the org.compiere.db.postgresql.provider (hikaricp) and install the plugin from step 1

  • this didn’t work, the old plugin survives a restart

• manually I went to idempiere home and removed the file plugins/org.compiere.db.postgresql.provider*.jar

• restarted the server - and now the server is running c3p0 instead of hikaricp

So, it seems possible, currently the database is “injected” using the interface org.compiere.db.AdempiereDatabase in OSGI-INF/pgprovider.xml and the interface org.adempiere.install.IDatabaseConfig on plugin.xml

The only thing that I didn’t like is the need to remove the plugin manually, for some reason it cannot be removed using the OSGi console as it appears again on restart, and the new installed plugin is not used.

To do that, would need to add a new level of abstraction. Perhaps, a new OSGi datasource interface and you can have implementation for c3p0, hikaricp, etc.

the idea about external plugins is that they have their own repo

I’m not really qualified to say what such a solution would look like. For example would the plugin be in a separate repo or in the main repo? I think is probably best qualified to say something about the technical side of it?

The thing is that we are replacing an 11 years plugin tested in really heavy conditions.

So, for me it creates some uncertainty to replace it with something that needs to prove to be so reliable as it has been c3p0, so, I would like to have a backdoor in case some scenarios are not well covered by HikariCP.

Some iDempiere implementations (as framework) run millions of transactions per day, and so far c3p0 has been very capable of managing such loads.

Hi !

Might be possible but what use-case could someone have to prefer c3p0 and invest the time to maintain such a plugin? There is already a bunch of code duplication between the Oracle and PostgreSQL plugin. With a c3p0 plugin that duplication doubles.