You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Chip Childers (JIRA)" <ji...@apache.org> on 2012/10/05 15:08:03 UTC

[jira] [Updated] (CLOUDSTACK-264) Upgrade from CS-2.2.14 to ASF 4.0 fails in the cloud-setup-encryption step with Exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/jasypt/intf/cli/JasyptPBEStringEncryptionCLI

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chip Childers updated CLOUDSTACK-264:
-------------------------------------

    Priority: Critical  (was: Major)

IMO, the source issue should be fixed.  What exactly is it about the 3.x installation that makes things work for the 4.0 code, that doesn't work when 2.x is the starting point for the upgrade?
                
> Upgrade from CS-2.2.14 to ASF 4.0 fails in the cloud-setup-encryption step with Exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/jasypt/intf/cli/JasyptPBEStringEncryptionCLI
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-264
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-264
>             Project: CloudStack
>          Issue Type: Bug
>          Components: Install and Setup, Management Server
>    Affects Versions: pre-4.0.0
>         Environment: MS - Rhel 6.3
> Host - KVM (Rhel 6.3)
> ASF Build : http://jenkins.cloudstack.org/job/build-4.0-rhel63/385/artifact/CloudStack-oss-4.0.0-385.tar.bz2
> Git Revision: ef7552fddad567d1509ad897e4df12566b7b9d62
> Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
>            Reporter: Abhinav Roy
>            Priority: Critical
>             Fix For: pre-4.0.0
>
>
> Steps :
> ======================
> Upgrade from CS-2.2.14 to ASF-4.0 by following the procedure given the CS-3.0.5 release notes :
> -----------------
> 1. Stop management server.
> 2. Upgrade to 4.0.
> 3. Run cloud-setup-encryption
> 4. Start Management server
> Expected Behaviour :
> =====================
> The upgrade should be successful.
> Observed behaviour :
> ====================
> Execution of cloud-setup-encryption in step 3 throws an exception
> [root@burnank CloudStack-oss-4.0.0-385]# cloud-setup-encryption
> Preparing /etc/cloud/management/db.properties                                   [ OK ]
> Processing encryption ...                                                       Traceback (most recent call last):
>   File "/usr/bin/cloud-setup-encryption", line 266, in <module>
>     o.run()
>   File "/usr/bin/cloud-setup-encryption", line 255, in run
>     self.processEncryptionStuff()
>   File "/usr/bin/cloud-setup-encryption", line 214, in processEncryptionStuff
>     encryptDBSecretKey()
>   File "/usr/bin/cloud-setup-encryption", line 198, in encryptDBSecretKey
>     self.putDbProperty('db.cloud.encrypt.secret', formatEncryptResult(encrypt(self.dbsecretkey)))
>   File "/usr/bin/cloud-setup-encryption", line 188, in encrypt
>     return runCmd(cmd).strip('\n')
>   File "/usr/bin/cloud-setup-encryption", line 51, in runCmd
>     raise Exception(stderr)
> Exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/jasypt/intf/cli/JasyptPBEStringEncryptionCLI
> Caused by: java.lang.ClassNotFoundException: org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> Could not find the main class: org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI. Program will exit.
> And if we don't execute step 3 then also upgrade fails and exception is seen in the logs.
> Workaround :
> =======================
> However, there is a workaround for this issue.
> We can first do the upgrade from 2.2.14 to 3.0.x and then to 4.0. If we do the upgrade this way then no error is seen and the operation is successful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira