public static class TransactionVerificationException.ConflictingAttachmentsRejection
Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.
Constructor and Description |
---|
ConflictingAttachmentsRejection(SecureHash txId,
java.lang.String contractClass)
Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file
path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not
allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency,
in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually
attach dependency JARs when building the transaction.
|
Modifier and Type | Method and Description |
---|---|
java.lang.String |
getContractClass()
The fully qualified class name of the failing contract.
|
public ConflictingAttachmentsRejection(SecureHash txId, java.lang.String contractClass)
Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.
contractClass
- The fully qualified class name of the failing contract.