We Keep Coding

Liferay 7 with MySQL Server 5.6 not starting

I’d just downloaded latest Liferay 7 Tomcat bundle
liferay-ce-portal-tomcat-7.0-ga3-20160804222206210
Extracted it and stared from liferay-ce-portal-7.0-ga3\tomcat-8.0.32\bin\startup.bat. Server started successfully and first screen opened on browser. Then I provided basic configurations and database (MySQL Server 5.6) details etc. and re-stared server as instructed. But now whenever I’m starting the server, throwing following exception and server is not starting. Can anyone help me to identify the issue please?
10:23:40,085 INFO [localhost-startStop-1][BaseDB:501] Database does not support case sensitive queries
You must first upgrade to Liferay Portal 7002
10:23:40,097 ERROR [localhost-startStop-1][MainServlet:237] java.lang.RuntimeException: You must first upgrade to Liferay Portal 7002
java.lang.RuntimeException: You must first upgrade to Liferay Portal 7002
at com.liferay.portal.tools.DBUpgrader.checkRequiredBuildNumber(DBUpgrader.java:86)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:190)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:85)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1290)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:234)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1238)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1151)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4997)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5289)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:585)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1794)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Stopping the server due to unexpected startup errors

You seem to have pointed Liferay to a database with existing data. In that case you'll have to run the upgrade routines before starting Liferay. This is a separate tool starting with version 7.0 - it used to be bundled within the server in prior versions. The documentation should contain all required information.
Answering your comment: The line
10:23:40,097 ERROR [localhost-startStop-1][MainServlet:237] java.lang.RuntimeException:
You must first upgrade to Liferay Portal 7002
clearly indicates that Liferay found the tables and data structure from a previous version in the database that you're pointing to. Note that a portal-ext.properties file will also be picked up if it's in the current user's home directory - that might override the settings that you expect to set in the installation's private portal-ext.properties or portal-setup-wizard.properties.
In addition, I do recommend to explicitly use a mysql-driver version matching your mysql-server version. Otherwise Liferay will download a driver from the maven repositories and it might not match 100%. I've seen problems arise from that.

10:23:40,085 INFO [localhost-startStop-1][BaseDB:501] Database does not support case sensitive queries You must first upgrade to Liferay Portal 7002
Did you tried this previous advise from your stacktrace ?

MyFirstPortlet-portlet-6.1.1.1.war does not support this version of Liferay

I'm learning portlets and at the moment I'm not able to run my portlet in Liferay.
When I want to deploy my portlet on Liferay, in my console I receive this messages:
com.liferay.portal.deploy.auto.PortletAutoDeployListener.deploy(PortletAutoDeployListener.java:88)
at com.liferay.portal.kernel.deploy.auto.AutoDeployDir.deploy(AutoDeployDir.java:50)
at com.liferay.portal.kernel.deploy.auto.AutoDeployDir.processFile(AutoDeployDir.java:211)
at com.liferay.portal.kernel.deploy.auto.AutoDeployDir.scanDirectory(AutoDeployDir.java:275)
at com.liferay.portal.kernel.deploy.auto.AutoDeployScanner.run(AutoDeployScanner.java:58)
Caused by: com.liferay.portal.kernel.deploy.auto.AutoDeployException: MyFirstPortlet-portlet-6.1.1.1.war does not support this version of Liferay
at com.liferay.portal.tools.deploy.BaseDeployer.deployFile(BaseDeployer.java:902)
at com.liferay.portal.tools.deploy.BaseDeployer.autoDeploy(BaseDeployer.java:213)
... 6 more
07:16:25,174 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][AutoDeployDir:224] Add MyFirstPortlet-portlet-6.1.1.1.war to the blacklist
I'm using the bundle liferay-portal-tomcat-6.2-ce-ga4
Do I need another version of Liferay?

Just remove "liferay-versions" property from "liferay-versions=6.1.20.xml" file and restart the server.It will solve your problem

How to integrate JRebel with Mule ESB?

Has anybody sometime tried to use JRebel with Mule instead of a typical application server? If so, could you describe your experience?
As far as I know, currently, Mule is not officially supported by the JRebel team. However, I was wondering if there might be some workaround to this limitation.

Although Mule ESB is not officially supported by JRebel, we have found a workaround. First of all, let me start by stating that:
As of today, it is not possible to hot-deploy Mule XML flows by using JRebel. Mule, however, offers its own mechanisms for achieving this same thing. As such, the lack of JRebel support for this is no deal breaker.
So, the only thing we can hot-deploy are the Java classes, which is still very welcome. How do we do that?
Start by configuring the JRebel agent in $MULE_HOME/conf/wrapper.conf. The required lines, in our case, were:
wrapper.java.additional.13=-javaagent:{path to jrebel.jar}
wrapper.java.additional.14=-Xbootclasspath:{path to rebelboot.jar}
wrapper.java.additional.16=-Drebel.remoting_plugin=true
wrapper.java.additional.19=-Drebel.remoting_port={whatever}
These are the JVM paremeters required to launch JRebel along with Mule. The numbering of the parameters is arbitrary.
We want to use JRebel in remote mode. You can read about this mode in the docs. That's the reason for the wrapper.java.additional.16=-Drebel.remoting_plugin=true and wrapper.java.additional.19=-Drebel.remoting_port={whatever} paremeters.
Now go ahead and launch Mule by either executing mule.bat or mule.sh, depending on your environment (Windows or *nix). JRebel should start along with it.
Place your Mule applications inside $MULE_HOME/apps. They will be automatically deployed and, from now on, their .class files will be monitored by JRebel.
Inside your IDE, install the JRebel plugin and apply your license. Afterwards, add the JRebel nature to your project and configure its remote server URL using the port we previously defined inside wrapper.conf.
Do whatever changes you need to do to your code and sync. They should be successfully hot-deployed into the running Mule instance.

when I was testing, I noticed that you need to add in the file wrapper.conf the next attributes:
wrapper.java.additional.18=-Drebel.log=true
wrapper.java.additional.19=-Drebel.log.file=/MyPath/LogName.log
With these the JRebel runs correctly. In conclusion, when we´re using a specific port, is necessary to enable JRebel’s logging.
More information, check in Step 6:
https://zeroturnaround.com/software/jrebel/learn/remoting/setting-up-jrebel-remoting-with-intellij-idea-and-tomcat/

When I configured with the points indicated, I have the next exception in Mule´s console:
Launching a JVM...
2015-10-27 11:00:27 JRebel: WARN You are running JRebel using the -javaagent option on a system where -agentpath is supported.<br/>
2015-10-27 11:00:29 JRebel: Monitoring Log4j configuration in 'file:/C:/Dev/Mule%20-%2002-esb-mule-ee%20-%203.4/conf/log4j.properties'.<br/>
Exception in thread "main" java.lang.NoSuchMethodError: javax.xml.parsers.SecuritySupport$1: method <init>()V not found<br/>
at javax.xml.parsers.SecuritySupport.getContextClassLoader(Unknown Source)<br/>
at javax.xml.parsers.FactoryFinder.find(Unknown Source)<br/>
at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)<br/>
at com.opensymphony.module.propertyset.config.PropertySetConfig.<init>(PropertySetConfig.java:53)<br/>
at com.opensymphony.module.propertyset.config.PropertySetConfig.getConfig(PropertySetConfig.java:113)<br/>
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:32)<br/>
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:22)<br/>
at com.mulesource.licm.pref.MulePropertySetPreferences.loadPropertySet(MulePropertySetPreferences.java:208)<br/>
at com.mulesource.licm.pref.MulePropertySetPreferences.<clinit>(MulePropertySetPreferences.java:50)<br/>
at com.mulesource.licm.pref.MulePreferencesFactory.<clinit>(MulePreferencesFactory.java:19)<br/>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)<br/>
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)<br/>
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)<br/>
at java.lang.reflect.Constructor.newInstance(Unknown Source)<br/>
at java.lang.Class.newInstance(Unknown Source)<br/>
at java.util.prefs.Preferences.factoryOrig(Unknown Source)<br/>
at java.util.prefs.Preferences.userRoot(Unknown Source)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.createLicenseManagerParameters (TrueLicenseHelper.java:338)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.createLicenseManagerParameters(TrueLicenseHelper.java:330)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.<init>(TrueLicenseHelper.java:120)<br/>
at com.mulesource.licm.impl.MuleLicenseManager.<init>(MuleLicenseManager.java:25)<br/>
at com.mulesource.licm.LicenseManagementFactory.createLicenseManager(LicenseManagementFactory.java:48)<br/>
at org.mule.module.boot.LicenseKeyHandler.<init>(LicenseKeyHandler.java:43)<br/>
at org.mule.module.reboot.MuleContainerBootstrap.handleLicenseKey(MuleContainerBootstrap.java:192)<br/>
at org.mule.module.reboot.MuleContainerBootstrap.main(MuleContainerBootstrap.java:62)<br/>

Configuration JRebel in Mule is very similar to configuration in tc Server.
You need to add JRebel Agent as a wrapper.java.additional.* property in $MULE_HOME/conf/wrapper.conf:
wrapper.java.additional.10=-agentpath:[c:\path\to]lib\jrebel64.dll
If you use Java version 7 and newer you use agent:
Windows 64-bit JDK jrebel64.dll
Windows 32-bit JDK jrebel32.dll
Mac OS X 64-bit JDK libjrebel64.dylib
Mac OS X 32-bit JDK libjrebel32.dylib
Linux 64-bit JDK libjrebel64.so
Linux 32-bit JDK libjrebel32.so
If you use Java version 6 and below, you need to use legacy agent jrebel.jar file.

JDBC via JT400 works on local Apache Tomcat 8 install but fails on Apache Tomcat 8 running on server

I have a Java application running and tested on my development workstation running Apache Tomcat 8. I have an established IBM i (AS/400) database connection working locally using the JT400.jar file. When I build and deploy the application to our production server running Apache Tomcat 8 with the same JT400.jar file, the database connection seems to fail and I cannot figure out why.
I get the following "HTTP Status 500 - Servlet execution threw an exception" error:
<code>
java.lang.AbstractMethodError
org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.isValid(DelegatingConnection.java:913)
org.apache.tomcat.dbcp.dbcp2.PoolableConnection.validate(PoolableConnection.java:218)
org.apache.tomcat.dbcp.dbcp2.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:302)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.validateConnectionFactory(BasicDataSource.java:2164)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2147)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:1902)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412)
utilities.SerialSearch.doSearch(SerialSearch.java:81)
processes.ProcessScan.getSerialScreenDetail(ProcessScan.java:66)
processes.ProcessScan.ProcessScanRequest(ProcessScan.java:103)
controller.MetricServlet.performTask(MetricServlet.java:145)
controller.MetricServlet.doPost(MetricServlet.java:43)
javax.servlet.http.HttpServlet.service(HttpServlet.java:644)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
</code>
What is different and how do I resolve the issue?
Thanks!

I had the same error while using the current latest version (as of today 9.3).
The problem was that I was using the JDK 8, and using maven to fetch the package I received a version that was not appropriate for this JDK.
To solve this problem I used the proper maven qualifier:
<dependency>
<groupId>net.sf.jt400</groupId>
<artifactId>jt400</artifactId>
<version>9.3</version>
<classifier>jt400_jdk8</classifier>
</dependency>
Note that if you download the zip with the full suite, all version of the jar do have the same name (i.e. jt400.jar) which makes them hard to distinguish.

Problem solved. Rookie mistake. I inadvertently left the old jt400 jar files in the lib folder on the Apache Tomcat 8 server by renaming them. Once I deleted the old jar files my issues were solved with the new jt400 jar that I installed last week that started the conflict to begin with. Thanks!

Jetty + Derby No suitable driver found

I am working with Jetty + Derby in Eclipse. I got this error:
javax.servlet.jsp.JspException: Unable to get connection, DataSource invalid: "java.sql.SQLException: No suitable driver found for jdbc:derby://localhost:1527/airlinesDB;user=slc;password=slc;"
at org.apache.taglibs.standard.tag.common.sql.QueryTagSupport.getConnection(QueryTagSupport.java:314)
at org.apache.taglibs.standard.tag.common.sql.QueryTagSupport.doStartTag(QueryTagSupport.java:197)
at org.apache.jsp.Welcome_jsp._jspx_meth_sql_query_0(Welcome_jsp.java:433)
at org.apache.jsp.Welcome_jsp._jspService(Welcome_jsp.java:108)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:489)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:972)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:906)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:267)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at com.ibm.sample.LoginServlet.doPost(LoginServlet.java:61)
Looking at LoginServlet.java code, in line 61, it's:
getServletContext().getRequestDispatcher("/Welcome.jsp").forward(request, response);
Since I moved the whole project from Tomcat Server to Jetty Server, and the project can run successfully in Tomcat configuration. Thus I am sure the URL in web.xml is correct. I think the question is probably due to some incorrect configuration in Jetty.
I also exported the full project in WAR format, you can access it via:
https://drive.google.com/file/d/0B1EhxQ7GBJdsYUlzZ1UtTkIxQTg/edit?usp=sharing
To run this project( or you just want to view the source files), you can import this project in Eclipse. The java source files are under com.ibm.sample package. Also for software Prerequisites to run the project，you should install Derby and Jetty plugins in Eclipse.
To run it, you can first start Derby Network Server, then launch Jetty, and then open this url:
localhost:8080/Test/Welcome.jsp
Then type slc/slc as username and password to login.
Above is all steps you need to do if you want to run it.
Thanks very much for your suggestions or help!!

That url requires client driver found in derbyclient.jar Check that you can access the exact same url in ij, with derbyclient.jar on the classpath. If you can, it means that the Derby client driver recognizes the url. Then the only other explanation is that your jetty server does not have derbyclient.jar on the classpath when trying to get the connection.
Since I don't know how to configure jetty, I don't know where the error could be. But I would look for any place where jars are listed and make sure derbyclient.jar is included.