Return-Path: Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: (qmail 48125 invoked from network); 12 Feb 2009 09:04:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2009 09:04:21 -0000 Received: (qmail 26734 invoked by uid 500); 12 Feb 2009 09:04:20 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 26714 invoked by uid 500); 12 Feb 2009 09:04:20 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 26703 invoked by uid 99); 12 Feb 2009 09:04:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Feb 2009 01:04:20 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Feb 2009 09:04:19 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 9C417234C48B for ; Thu, 12 Feb 2009 01:03:59 -0800 (PST) Message-ID: <967718843.1234429439567.JavaMail.jira@brutus> Date: Thu, 12 Feb 2009 01:03:59 -0800 (PST) From: "Freeman Fang (JIRA)" To: issues@cxf.apache.org Subject: [jira] Updated: (CXF-2038) changes for signaturePropFile and decryptionPropFile of WSS4JInteceptor can't be reloaded if we use cxf in container In-Reply-To: <966622914.1234429079565.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CXF-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-2038: ------------------------------ Description: if we use cxf with ws-security in some kind of container such as servicemix, and if we change the content of decryptionPropFile and signaturePropFile, then if we hot redeploy artifacts into container, then the changes can't be loaded. The error is caused by WSSHandler of wss4j, the DEC_PROP_FILE(decryptionPropFile) and SIG_PROP_FILE(signaturePropFile)get loaded only once, see the code of loadDecryptionCrypto in WSSHandler Crypto crypto = null; String decPropFile = getString(WSHandlerConstants.DEC_PROP_FILE, reqData.getMsgContext()); if (decPropFile != null) { if ((crypto = (Crypto) cryptos.get(decPropFile)) == null) { //the cryptos is static so means if decryptionPropFile loaded before, then it won't be loaded again even the content of decPropFile changed crypto = CryptoFactory.getInstance(decPropFile, this .getClassLoader(reqData.getMsgContext())); cryptos.put(decPropFile, crypto); } } we should override the method in AbstractWSS4JInterceptor which is subclass of WSHandler to ensure each change in DEC_PROP_FILE and SIG_PROP_FILE will be reloaded was: if we use cxf with ws-security in some kind of container such as servicemix, and if we change the content of decryptionPropFile and signaturePropFile, then if we hot redeploy artifacts into container, then the changes can't be loaded. The error is caused by WSSHandler of wss4j, the DEC_PROP_FILE(decryptionPropFile) and SIG_PROP_FILE(signaturePropFile)get loaded only once, see the code of loadDecryptionCrypto in WSSHandler Crypto crypto = null; String decPropFile = getString(WSHandlerConstants.DEC_PROP_FILE, reqData.getMsgContext()); if (decPropFile != null) { if ((crypto = (Crypto) cryptos.get(decPropFile)) == null) { //here means if decryptionPropFile loaded before, then it won't be loaded again even the content of decPropFile changed crypto = CryptoFactory.getInstance(decPropFile, this .getClassLoader(reqData.getMsgContext())); cryptos.put(decPropFile, crypto); } } we should override the method in AbstractWSS4JInterceptor which is subclass of WSHandler to ensure each change in DEC_PROP_FILE and SIG_PROP_FILE will be reloaded > changes for signaturePropFile and decryptionPropFile of WSS4JInteceptor can't be reloaded if we use cxf in container > -------------------------------------------------------------------------------------------------------------------- > > Key: CXF-2038 > URL: https://issues.apache.org/jira/browse/CXF-2038 > Project: CXF > Issue Type: Bug > Components: WS-* Components > Affects Versions: 2.0.10, 2.1.4 > Reporter: Freeman Fang > Assignee: Freeman Fang > Fix For: 2.2, 2.0.11, 2.1.5 > > > if we use cxf with ws-security in some kind of container such as servicemix, and if we change the content of decryptionPropFile and signaturePropFile, then if we hot redeploy artifacts into container, then the changes can't be loaded. > The error is caused by WSSHandler of wss4j, the DEC_PROP_FILE(decryptionPropFile) and SIG_PROP_FILE(signaturePropFile)get loaded only once, see the code of loadDecryptionCrypto in WSSHandler > Crypto crypto = null; > String decPropFile = getString(WSHandlerConstants.DEC_PROP_FILE, > reqData.getMsgContext()); > if (decPropFile != null) { > if ((crypto = (Crypto) cryptos.get(decPropFile)) == null) { > //the cryptos is static so means if decryptionPropFile loaded before, then it won't be loaded again even the content of decPropFile changed > crypto = CryptoFactory.getInstance(decPropFile, this .getClassLoader(reqData.getMsgContext())); cryptos.put(decPropFile, crypto); } > } > we should override the method in AbstractWSS4JInterceptor which is subclass of WSHandler to ensure each change in DEC_PROP_FILE and SIG_PROP_FILE will be reloaded -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.