I'm having problems executing Spring Tool, I get the error: Could not create the java virtual machine, and this in another window:
The error message isn't really explaining in detail what the problem is, but I would recommend to things here:
update to a recent JDK 1.8.0 (I think it is at 1.8.0_181 at the moment) and use that.
you can also specify the JVM to run STS in the STS.ini file in the same way than you could do that for plain Eclipse in the eclipse.ini file (described in more detail here: https://wiki.eclipse.org/Eclipse.ini).
It also looks like you are running a 64bit operating system, so in case you have a 64bit JDK installed, you should make sure to download and use the 64bit version of STS. From the error dialog it looks like you are trying to use the 32bit version of STS. You can do that, if you want to, but you would need to make sure that it picks up a 32bit JDK then. But I would strongly recommend to use a 64bit JDK together with the 64bit version of STS.
You better use JDK 1.8 etc. 1.6 is so old for starting new STS
Related
~We have some projects still running in AEM 6.1 SP2 (the move to newest version of AEM is in progress) and new projects in AEM 6.5.
AEM 6.1 runs in java 8 and AEM 6.5 runs in java 11.
For us developers this switching between jdk versions is difficult in our local environment, quite often we get our AEM instances corrupted or maven project imports are no longer working properly in IDE.
Anyone else had this situation? What are the best practices for such a situation?
My recommendation would be to set up vagrant box instances to your specs (AEM version + Java) and use automated deployments. This way, you can bring up a preconfigured instances in minutes by executing a single vagrant up command, run your automated deployment, and test your projects. If your instance gets corrupted, run a vagrant destroy command, bring up a new instance again with 0 configurations needed for the next deployment. You willincrease your productivity manifolds with this approach.
I have been using this approach for years and it has saved hours of devops work during critical project timelines
If you are using MAC [OSX], you can try Jenv. It can help you to have a unique Java Environment to a specific directory. We did find it very useful.
https://github.com/jenv/jenv
Thanks!
If you are running your AEM instances via shell scripts E.g. ./crx-quickstart/bin/start you can always specify the JAVA_HOME variable to be used in this particular file.
E.g.
export JAVA_HOME="path to your JVM"
export PATH=$JAVA_HOME/bin:$PATH
Is there a way to upgrade WebSphere 8.5.5.10 to version 9?
When installing Fix Packs using IBM Installation Manager, I only add the repository.config, but after adding the repository.config for Version 9, I only have the install option.
You'll have to do a new install of v9, and then migrate your configuration from the old to the new environment. There are a few different kinds of config migration, but the main overview is here: https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.migration.base.doc/ae/welcome_migrating.html
In particular, the provided tools will include WASPreUpgrade (https://www.ibm.com/support/knowledgecenter/en/SSAW57_9.0.5/com.ibm.websphere.migration.nd.doc/ae/rmig_WASPreUpgrade.html) and WASPostUpgrade (http://www.ibm.com/support/knowledgecenter/en/SSAW57_9.0.5/com.ibm.websphere.nd.multiplatform.doc/ae/rmig_WASPostUpgrade.html). For each profile you want to migrate, you use WASPreUpgrade to create a backup of your old configuration in a separate location, and WASPostUpgrade to merge that configuration with a new profile in the new configuration. You can do this disabling the old environment (standard migration) or keeping them both running side by side (clone migration) and have a choice of staying on the same system or migrating to a new one (remote migration.) All those terms are explained in the overview.
You can only indirectly upgrade by way of migration. You cannot just apply service/maintenance to change the Version or Release (WebSphere use a V.R.M.F versioning)
When migrating from one version or release to another, you perform a full install and use the provided tools to migrate your configuration.
We are trying to install the Klaros-Testmanagement test case management tool (Community Edition). While installing, the Apache Tomcat application container will be installed by the package automatically.
My doubt is even though there is tomcat running, why tomcat server needs to be installed again.
Is there any work around for this?
Klaros-Testmanagement is supported and tested with the supplied Tomcat version only, which also contains some configuration changes from a vanilla Tomcat distribution.
The rationale behind this is to update the distribution on a regular basis and ensure that JVM memory settings and other parameters are configured properly.
If you are feeling adventurous you can try using another version of Tomcat or a completely other application server.
For this you may download the .war only distribution and install it in your container.
Make sure you are picking up configuration changes in the conf and bin folders by diffing them to a vanilla tomcat distribution.
You definitely have to:
Raise memory limitations, esp. MaxPermSize when running under Java 7: -XX:MaxPermSize=192m -Xms256m -Xmx768m or more if needed/available.
Disable session persistence: Uncomment <Manager pathname=""/> in conf/context.xml
Beware that other configuration changes may arise in future releases without further notice, so you are pretty much on your own if things stop working.
I am seeing this when try to install WLS 11g. Has anyone came across with this?Or any solution. At JDK selection pannel, I see nothing under bundled JDK section. I want to install jrockit with this.
It sounds like you got the generic jar installer - generic jar installer doesn't come with a JDK. When using the jar installer, you need to install the supported JDK/JRockit first then run the installer.
When you come to the JDK selection part, select the JAVA_HOME of your JDK/JRockit installation.
One thing I always tell people about weblogic installations: make sure whatever that the OS and JDK are certified by Oracle. You can verify here: http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
Thanks,
Gavin |
http://pitss.com/us
I have been asked to update some old code I worked on years ago. All in xCode no eclipse and the change is needed urgently so do not have time to migrate away from xCode ATM.
I got my hands on a OS 10.5.8 box installed xcode 3.1.4 and the code compiled fine locally.
Tried to deploy never worked " Unsupported major.minor version 49.0 error" seems the server is running JVM 1.4.2 I have 1.6 locally. I followed some instructions on how to downgrade my local machine to java 1.4.2 without success.
So I gave up and put an old copy of the site back on the server. But now ALL the sites on the server get that same error message and none of them will start even though they have not been touched in 3-4 years. Not sure what happened? my only logically explanation is i accidentally did one action on the server instead of locally? Either way I have no idea what is wrong or how to fix it?
Where do I start trying to debug this?
Can I install a new version of java 1.5 or 1.6 on the server (OS 10.3.9) and have it work ok with webobjects?
Was this project a framework or an Application? If it is a framework that is depended-on by the other WebObjects projects, that would explain why everything started failing when you updated this project.
By default, Xcode did not include (or "embed") any depended-upon libraries or frameworks in the Project.woa bundle. Apps built this way depend upon any required resources being available in a few specific locations and then load them at launch. If they all now link to a framework or library that is incompatible, then they'll all stop working.
As far as the actual "Unsupported major.minor version" error goes, you do not need to downgrade the version of Java on your Mac, you can simply tell the compiler to target an older version of Java.
I can't remember if Xcode used Ant to do its Java compiling, but if it did and you are using Ant 1.7 or later, you can force Ant to compile 1.4-compatible binaries with Java 1.6 by editing the build.xml file so the javac tag includes a "target" parameter such as: <javac target="1.4" ... /> or by passing in the ant.build.javac.target property when you call Ant, either via command line or by modifying a properties file that Ant will load. I believe build.properties still existed in Xcode-based WebObjects projects. If it does this would be a good place for the property.
The basics are covered by this stackoverflow question: How to compile classes to JDK1.5 when ant is running in JDK1.6