Description of problem: As of 6.0.2 (because of BZ 1067772), the JMS API requires SSL in order to send some of the messages (those containing the password of the user). Version-Release number of selected component (if applicable): Starting with 6.0.2.ER1 How reproducible: Always Steps to Reproduce: This bug is to track the following config and installer changes. - BPMS installer changes: : keystore generation for the server : keystore(/truststore) generation for the client : configuration change to the standalone*xml files (adding a JMS SSL netty connector) - Configuration changes (when not using the installer) : configuration change to the standalone*xml files (adding a JMS SSL netty connector) Additional info: DOCUMENTATION: we will have to add a section to the JMS documentation explaining the following: 1. SSL is needed in order to send certain JMS requests (because they contain the password) 2. How to setup the (BPMS) Remote Java API client to send requests via JMS/SSL. Lastly: as part of this fix, I've added a new "factory builder" API to the (BPMS) Remote Java API client to make the remote client configuration easier and friendly. I/We also need to document this.
(In reply to Marco Rietveld from comment #0) > Description of problem: > > As of 6.0.2 (because of BZ 1067772), the JMS API requires SSL in order to > send some of the messages (those containing the password of the user). > > Version-Release number of selected component (if applicable): > > Starting with 6.0.2.ER1 > > How reproducible: > > Always > > Steps to Reproduce: > > This bug is to track the following config and installer changes. > > - BPMS installer changes: > : keystore generation for the server > : keystore(/truststore) generation for the client > : configuration change to the standalone*xml files (adding a JMS SSL netty > connector) > - Configuration changes (when not using the installer) > : configuration change to the standalone*xml files (adding a JMS SSL netty > connector) > > Additional info: > > DOCUMENTATION: we will have to add a section to the JMS documentation > explaining the following: > > 1. SSL is needed in order to send certain JMS requests (because they contain > the password) > 2. How to setup the (BPMS) Remote Java API client to send requests via > JMS/SSL. > > Lastly: as part of this fix, I've added a new "factory builder" API to the > (BPMS) Remote Java API client to make the remote client configuration easier > and friendly. I/We also need to document this. Should we also add how to configure websphere for this issue since we also need to release the deployable for websphere 6.0.2?
Marco has sent me the xstl file and we still wait for the cli for installer package assembly.
The required changes for the installer are as follows: A new panel in which the following is specified: - The server keystore password - The client keystore password - The number of distinct client keystores required A default vault must now be specified as well, in a similar fashion to FSW, otherwise the server keystore password will be visible in the standalone*.xml and domain.xml / host.xml files. This means that there will be a new panel and the user will be prompted for another keystore password set (if they do not choose to install a custom password vault).
Created attachment 886132 [details] XSLT to change Messagng config
Tom, I have added your cli changes into the cli-script in ip.git. Plus I add them also for domain ones(See add-mdb-conf-domain.cli). The commit id is: 6f195f530e6cfdbc282f5739afeb6f60c4084513 (6.0.x branch) Please let me know if anything more is required for ip.git assembly. (In reply to Thomas Hauser from comment #4) > The required changes for the installer are as follows: > > A new panel in which the following is specified: > - The server keystore password > - The client keystore password > - The number of distinct client keystores required > > A default vault must now be specified as well, in a similar fashion to FSW, > otherwise the server keystore password will be visible in the > standalone*.xml and domain.xml / host.xml files. > This means that there will be a new panel and the user will be prompted for > another keystore password set (if they do not choose to install a custom > password vault).
The issue can't be configured in deployable-eap6.x.zip since it requires keystore file and password generation. It needs customer's interactive operation. S
I will tweak them a little bit. The trust-store addition is not necessary, according to Marco, so I'll remove that from the standalone / domain scripts. After that I think we're ok. Thanks, Tom (In reply to Ryan Zhang from comment #6) > Tom, I have added your cli changes into the cli-script in ip.git. Plus I add > them also for domain ones(See add-mdb-conf-domain.cli). > The commit id is: 6f195f530e6cfdbc282f5739afeb6f60c4084513 (6.0.x branch) > > Please let me know if anything more is required for ip.git assembly. > (In reply to Thomas Hauser from comment #4) > > The required changes for the installer are as follows: > > > > A new panel in which the following is specified: > > - The server keystore password > > - The client keystore password > > - The number of distinct client keystores required > > > > A default vault must now be specified as well, in a similar fashion to FSW, > > otherwise the server keystore password will be visible in the > > standalone*.xml and domain.xml / host.xml files. > > This means that there will be a new panel and the user will be prompted for > > another keystore password set (if they do not choose to install a custom > > password vault).
OK， Thanks Tom! (In reply to Thomas Hauser from comment #8) > I will tweak them a little bit. The trust-store addition is not necessary, > according to Marco, so I'll remove that from the standalone / domain > scripts. After that I think we're ok. > > Thanks, > Tom > > (In reply to Ryan Zhang from comment #6) > > Tom, I have added your cli changes into the cli-script in ip.git. Plus I add > > them also for domain ones(See add-mdb-conf-domain.cli). > > The commit id is: 6f195f530e6cfdbc282f5739afeb6f60c4084513 (6.0.x branch) > > > > Please let me know if anything more is required for ip.git assembly. > > (In reply to Thomas Hauser from comment #4) > > > The required changes for the installer are as follows: > > > > > > A new panel in which the following is specified: > > > - The server keystore password > > > - The client keystore password > > > - The number of distinct client keystores required > > > > > > A default vault must now be specified as well, in a similar fashion to FSW, > > > otherwise the server keystore password will be visible in the > > > standalone*.xml and domain.xml / host.xml files. > > > This means that there will be a new panel and the user will be prompted for > > > another keystore password set (if they do not choose to install a custom > > > password vault).
There are some changes in BPMS installer which include the generation of necessary keystores. However, I am not able to verify if it really works because there is no mention of RemoteJmsRuntimeEngineFactoryBuilder in the documentation. Marco, could you provide me with some basic steps how to get the JMS client working?
Hi Tomas, Sorry for the late answer! 1. Generate keys for client and server. If you're using the installer, the keys will have been generated. 2. Here's an example of the RemoteJmsRuntimeEngineFactoryBuilder when setting it up for JMS: https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.0.x/kie-remote/kie-services-client/src/test/java/org/kie/services/client/builder/RemoteRuntimeEngineBuilderTest.java#L359
Verified on BPMS 6.0.2 ER2