Print

[brian]

Hi,

The jmxremote_optional jar makes trouble for other libs on my classpath which use those same javax.management.remote APIs but expect different (JDK) impl. If I resolve this by removing the jmxremote_optional jar from my classpath, is there a way to then disable whichever features in JPPF use it?

Thanks.

[lolo]

Hello,

To remove the jppf_jmxremote_optional jar from your client application's classpath you don't need to do anything special. If you want to remove it from a driver or node, then you need to disable management in their respective configuration:

For a driver:

Code: [Select]

jppf.management.enabled = false
jppf.management.ssl.enabled = false
For a node:

Code: [Select]

jppf.management.enabled = false
However, I would be interested in understanding what kind of problem this is causing with your other libraries, so we can fix it in upcoming versions of JPPF. Would you mind providing details on this?
In particular I'm not clear on what you mean by "but expect different (JDK) impl", could you please elaborate?

Thanks,
-Laurent

[brian]

Ok great.

I think the issue is on my side not your problem so there'd be nothing for you to fix. But I'll let you know if I discover otherwise.

Btw in case you never considered it, one thing you could consider doing for this dep is shading (https://maven.apache.org/plugins/maven-shade-plugin/) it so jppf users didn't even realize it was there.

[brian]

Which features will stop working when management is disabled in node and driver? That is, I know visualvm would no longer be able to connect but aside from that are you also using JMX connections to implement other features?

[lolo]

Everything related to driver and node management and monitoring will be unavailable, including:
- management and monitoring APIs
- grid topology and job monitoring APIs
- the Swing-based administration console, which uses the above APIs, will not be able to manage/monitor the drivers and nodes

-Laurent

[brian]

Hi Laurent,

I wanted to revisit an old suggestion I made to shade your jmxremote_optional dependency. It would be great if you did this because I could then add jppf dependency to my main project classpath as a normal dependency vs. the "hack" I use now which is to create a special Ivy configuration and source folder just for jppf code&dependency. I do that separation because I don't want jppf's jmxremote_optional code being used in the many prod apps depending on my library. Today they all use the jmx_optional jar which came from Sun and while I'm sure the jppf version would also work for them, I don't want this jppf-specific dependency leaking outside jppf jmx connections. If you were to shade the packages, both jmxremote_optional impls could live together on the same classpath and your specialized jmxremote_optional jar would only get used by jppf connections.

Thanks for considering it,
Brian

[brian]

Hi Laurent,

This request actually extends to all of JPPF. As our dependency on jppf grows and multiple grids are deployed in production, upgrading them all at the same time is not feasible. Multiple teams working with projects that consume a similar set of internal libs (which have jppf dependencies) require independent upgrade cycles. It would be ideal to have multiple versions of jppf on the classpath like org.jppf52, org.jppf53, org.jppf61 etc. SPI files could also co-exist because package names would not conflict. Maven shade plugin or JarJar could accomplish this, or even doing it in source tree like commons-math3.

Let me know what you think. Thanks.

[brian]

Hi,
FYI I am still interested in this feature. I have used JarJar to emulate this packaging for now, but a supported packaging would be ideal.
Thanks.

[brian]

Hi,
Any thoughts on this feature?
Thanks.