[ https://issues.jboss.org/browse/TEIIDDES-2667?page=com.atlassian.jira.plu... ] Paul Richardson edited comment on TEIIDDES-2667 at 9/30/15 5:21 AM: -------------------------------------------------------------------- [~maxandersen], [~pleacu], [~blafond], So last night I came up with an idea ... The dependency on bc is not explicit. The connection-ui plugin depends on the following packages: {code} org.bouncycastle.asn1 org.bouncycastle.x509.extension {code} while the CertificateInfoComposite class uses them in the following manner: {code} // try to parse the extension value byte[] to an ASN1 object byte[] extensionValueBin = certificate.getExtensionValue( oid ); String extensionValue = null; try { ASN1Object extension = X509ExtensionUtil.fromExtensionValue( extensionValueBin ); extensionValue = extension.toString(); } catch ( IOException e ) { extensionValue = new String( Hex.encodeHex( extensionValueBin ) ); } {code} With this in mind, I could # Create a Teiid plugin that includes packages of the same name, eg. org.teiid.designer.bc.dummy # Create classes of the same names as those used which do nothing or just throw an IOException # The TP should remove the bcprov.jar anyway and respins to 4.2.8 so Teiid upgrades to 4.2.8 TP # The inclusion of the dummy plugin should mean that the connection-ui plugin's dependencies are satisfied and that the LDAP wizard starts working for non-X509 directories. # Assuming a user wants X509 directories a second teiid plugin that includes bcprov could be packaged up as a feature and made available on Teiid's website. Such users would have to swap the feature containing the dummy for the feature containing bcprov. Either way, its such a small number of users, the little extra work can be worked through with them. What do you think? was (Author: phantomjinx): [~maxandersen], [~pleacu], [~blafond], So last night I came up with an idea ... The dependency on bc is not explicit. The connection-ui plugin depends on the following packages: {code} org.bouncycastle.asn1 org.bouncycastle.x509.extension {code} while the CertificateInfoComposite class uses them in the following manner: {code} // try to parse the extension value byte[] to an ASN1 object byte[] extensionValueBin = certificate.getExtensionValue( oid ); String extensionValue = null; try { ASN1Object extension = X509ExtensionUtil.fromExtensionValue( extensionValueBin ); extensionValue = extension.toString(); } catch ( IOException e ) { extensionValue = new String( Hex.encodeHex( extensionValueBin ) ); } {code} With this in mind, I could 1) Create a Teiid plugin that includes packages of the same name, eg. org.teiid.designer.bc.dummy 2) Create classes of the same names as those used which do nothing or just throw an IOException 3) The TP should remove the bcprov.jar anyway and respins to 4.2.8 so Teiid upgrades to 4.2.8 TP 4) The inclusion of the dummy plugin should mean that the connection-ui plugin's dependencies are satisfied and that the LDAP wizard starts working for non-X509 directories. 5) Assuming a user wants X509 directories a second teiid plugin that includes bcprov could be packaged up as a feature and made available on Teiid's website. Such users would have to swap the feature containing the dummy for the feature containing bcprov. Either way, its such a small number of users, the little extra work can be worked through with them. What do you think? -- This message was sent by Atlassian JIRA (v6.4.11#64026)