Tuesday, August 19, 2014

Tomcat fail to start if webservices-rt were declare as provided scope in Maven

Arrghhhh! Tomcat failed to start again! And I see the same error message again!

org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]

For this round was cause by the webservices-rt dependency has been declare as provided scope.
  
   org.glassfish.metro
   webservices-rt
   2.2
   provided
  
Interestingly if I declare provided scope to webservices-api, the Tomcat were just run fine.

Monday, August 11, 2014

Missing in tomcat7-maven-plugin causing Tomcat fail to start

I just felt the following stack trace very annoying and too hard to digest.
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[/MavenTest]]
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
 at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[/MavenTest]]
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
 ... 6 more
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/catalina/loader/WebappClassLoader) previously initiated loading for a different type with name "javax/servlet/ServletContext"
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
 at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
 at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1190)
 at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
 at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
 at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:61)
 at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5274)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 ... 6 more

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.045s
[INFO] Finished at: Mon Aug 11 17:16:16 SGT 2014
Aug 11, 2014 5:16:16 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
 at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at org.apache.catalina.startup.Tomcat.start(Tomcat.java:335)
 at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:1018)
 at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:478)
 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: A child container failed during start
 at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1131)
 at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 ... 6 more

In short, the key error message in this stack trace was Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]. What causes fail to start? I ask to myself. I check and re-check on my pom.xml, I'm sure it has nothing to do with the dependencies, but I just wonder whether the problem could be rise from the plugin as shown in the following code snippet:
    
     ${project.name}
     
     
          ...
          ...
     

        
            
                org.apache.tomcat.maven
                tomcat7-maven-plugin
                2.0
                
                    8086
                    ${project.basedir}/target/${project.name}
                
            

            
                org.apache.maven.plugins
                maven-compiler-plugin
                3.1
                
                    1.7
                    1.7
                    
                        ${endorsed.dir}
                    
                
            
        
    
Although I found the solution on similar problem on forum but it doesn’t really help me out. While struggling for a solution, I realize that missing <serverXml> tag may cause the rise of this error. The tag belongs to tomcat7-maven-plugin’s configuration telling Tomcat plugin where to locate server.xml, the master piece on how Tomcat should behave during runtime. If the tag went missing, Tomcat may gone wild. Try and error on this tag, I got the final piece on tomcat7-maven-plugin configuration. Now it should look like following code snippet:
    
        org.apache.tomcat.maven
        tomcat7-maven-plugin
        2.0
        
            8086
            ${project.basedir}/target/${project.name}
            ${project.basedir}/src/main/tomcatconf/server.xml
        
    

Tuesday, July 29, 2014

Using cocos to create a new project from scratch

cocos is a very useful command when creating a new Cocos2d-x project from scratch. However it has to be install before I can use it. But how? Due to the information on Cocos2d-x site were scatter around, I have overlook the very important piece where the manual did actually describe how it could be install. The article mention that I must first setup in order to use this tool by just run ./setup.py on console. This program can be found on Cocos2d-x root directory. I did it on Windows 8, and it works! After the setup, a new environment variable will be create on Windows. For my case, I'll see:

Variable name: COCOS_CONSOLE_ROOT
Variable value: D:\tool\cocos2d-x-3.2\tools\cocos2d-console\bin

And then I use following command to create a new project:

C:\Users\huahsin68>cocos new MyGame1 -p org.huahsin68.puzzle -l cpp -d D:\Cocos2
dxProject

Tada! A new game project is initialize for android, ios_mac, linux, win32, and wp8 platform.

Sunday, July 13, 2014

printf command could handle special character easily

Just found a better solution on handling special character in a string. In a given scenario where I have a loop to process each file from a given file list as shown below:
 while read file
 do
  newfile=$(echo "${file}" | sed 's, ,\\ ,g')
  ...
  ...

 done < ${TEMP_FILE}
Assuming ${TEMP_FILE} containing a list of files. The file is validate to see is there any space within the file name. If there is a space, prefix it with backslash. In this context, I was using sed command to handle this for me. But there is a problem where this command does not able to handle special character, such as single quote (‘) because this command only search for space and then prefix it with backslash.

I've been thinking to have all sed command for every single special characters but it seems not a wise move to me. The expert share me a though that printf command should help me out as shown in the code snippet below:

newfile=$(printf "%q" "${file}")

This solution not only fix the single quote but also space within a string. Really appreciate the help from expert.

Tuesday, July 8, 2014

Beware of -Dfile option when using mvn in Cygwin

Cygwin is my favorite tool that could allow me to execute Linux command on Windows. Sometimes I find it weird when I’m navigating to the root path of each partition where primary partition on Windows, which C:, were prefix with /cygdrive. At first I’m not so comfort with this approach but then later I started to adopt this culture in my daily routine job.

Here come to a problem when I was using Maven to install a third party dependency into my local Maven repository. When the following command was fired:

mvn install:install-file -Dfile=/cygdrive/c/Users/kok.hoe.loh/workspace/ProjectA/lib/AuditUtil.jar -DgroupId=org.huahsin.eai -DartifactId=AuditUtil -Dversion=0.0.1 -Dpackaging=jar
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ProjectA 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ ProjectA ---
[INFO] Installing C:\cygdrive\c\Users\kok.hoe.loh\workspace\ProjectA\lib\AuditUtil.jar to C:\Users\kok.hoe.loh\.m2\repository\org\huahsin\eai\AuditUtil\0.0.1\AuditUtil-0.0.1.jar
[INFO] Installing C:\Users\kok.hoe.loh\tool\Cygwin\tmp\mvninstall6980818442128433518.pom to C:\Users\kok.hoe.loh\.m2\repository\org\huahsin\eai\AuditUtil\0.0.1\AuditUtil-0.0.1.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.764s
[INFO] Finished at: Tue Jul 08 18:00:24 SGT 2014
[INFO] Final Memory: 5M/76M
[INFO] ------------------------------------------------------------------------
The build was success but the dependency was not install in my local Maven repository. There trace information has already show me the problem but I have overlook it. Notice that the dependency was install to C:\cygdrive\c\..., which is not what I want. It seems to me -Dfile option doesn't recognize Cygwin file system.

This fix was easy, just ignore the root when dealing with -Dfile, which is /cygdrive/c for my case. Following sample shows the real work.

mvn install:install-file -Dfile=/Users/kok.hoe.loh/workspace/ProjectA/lib/AuditUtil.jar -DgroupId=org.huahsin.eai -DartifactId=AuditUtil -Dversion=0.0.1 -Dpackaging=jar

Sunday, July 6, 2014

Resolving GLEW library when compile Cocos2d-x in Windows 8

This is my second try on compiling Cocos2d-x on Windows platform. Since I have successfully compile for Linux, I'm so eager to try it on Windows. Unfortunately the build were failed. This was happened in few months ago.

In my previous attempt to compile Cocos2d-x on Windows platform happened in few months ago, I was so frustrate that I'm not able to resolve the GLEW library during run-time. I know the root cause, it is either:

  1. the GLEW DLL wasn't there, or
  2. an incompatible GLEW version has been loaded.

A check on the build directory, found out there already have the GLEW DLL, so option 1 is invalid. I downloaded the GLEW library and replace the existing GLEW library and my fate still the same. Failed! Thus option 2 wasn't out. I was running out of clue after many times of try and error, ever wonder which GLEW library did Cocos2d-x were using?

Now a few months later, when I'm looking back on the same problem, I think I'm almost there, just that I have miss out some steps left to be done. As of this writing, I'm using Cocos2d-x 3.1.1 and VS Desktop 2012 Express Edition on Windows 8. This is what I did:

  1. Right click on the project > Properties > Linker tab > General tab > Add the new GLEW library path where the library is downloaded into Additional Library Directories field.
  2. On Linker page again > Input tab > Add glew32.lib into Additional Dependencies field. (Never pick x64 version as it doesn't work.)
  3. Replace the new GLEW DLL with the one located in build path.

Remember not to make a clean build as this will wipe off all the stuff in build directory. If a clean build has accidentally been fired, just replace the GLEW DLL will do.

Thursday, July 3, 2014

Hacking on LibreOffice to bypass proxy during build

It was a relax week for me while having all my tasks commit. Since I’m quite free at the moment, I grab a copy of LibreOffice source code to play around with. When I just started to build on it, the make command return me error due to the build process unable to proceed. The reason being is wget command which require the proxy information is not provided. I know that I’m require to provide proxy information but where? Do a deep search in the source code, found out Makefile.fetch contain following code:

&& $(WGET) --progress=dot:mega -Q 0 -P "." -l 0 -nd -nH -N $1/$2 2>&1 | tee -a  $(fetch_LOGFILE) && [ $$PIPESTATUS -eq 0 ]

I think this should be the one that cause the build failed. I wasn't sure whether it works or not if I pass in the proxy information? Just give it a try:

&& $(WGET) -e use_proxy=yes -e http_proxy=xxx.xxx.xxx.xx:8080 --proxy-user=username --proxy-password=password --progress=dot:mega -Q 0 -P "." -l 0 -nd -nH -N $1/$2 2>&1 | tee -a $(fetch_LOGFILE) && [ $$PIPESTATUS -eq 0 ]

Yes! I’m rite. The build able proceed as usual.