tc Server 2.6.4 Now Available

[rmorgan]

I'm pleased to announce that tc Server 2.6.4 is now available on vmware.com. This is a maintenance release that updates the Tomcat 7 runtime to be based off Apache Tomcat 7.0.25. Included in this update is a backport of Bugzilla #52444 from Tomcat 7.0.26 to address issues with @HandlesTypes processing. This bug could cause long startup times or excessive memory consumption for some Spring 3.1 applications.

Please see the release notes on vmware.com for more information.

tc Server 2.6.4 may be downloaded from the following locations:

Standard Edition: http://downloads.vmware.com/d/info/a..._tc_server/2_6

Developer Edition: http://downloads.vmware.com/d/info/a...er_edition/2_6

These packages are also available in RPM format, see the vFabric 5 Documentation Center for details.

[jmohseni]

That bugzilla report also had a simple mention of another bug at the bottom of the thread. The fix was in reference to code that references classes not on the classpath and as a result it throws an NPE (fix was simple null check). That fix is NOT in tcserver 2.6.4 and as a result I cannot deploy my spring app. Not sure why things are not on the classpath because the error reveals nothing and I have been able to deploy on 3 other servers (Jetty 7.5.x, Tomcat 7.0.25, and Tomcat 7.0.26) but not in tcserver 2.6.4.

As a result I have decomposed my webapp to nothing more than a web.xml, empty /WEB-INF/classes folder, and my entire /WEB-INF/lib directory. I took out libs one by one and I definitively narrowed it down to 2 JARS (jersey-servlet-1.12.jar and spring-web-3.1.1.RELEASE.jar). With these 2 jars removed my app finally deploys (now runtime errors occur due to missing jars). I also noted that if I used (spring-web-3.0.6.RELEASE.jar) my app deploys (still no jersey-servlet) so not sure what changed there either. The Bugzilla #52444 report says the bug is due to references to classes/interfaces not on the classpath and their fix is a simple null check before trying to access the resource. This fix is purported to be in tcserver 2.6.4 but I decompiled the ContextConfig.class and it is not there.


I need to some guidance and clarification with this issue. My prototype (when all the resources are in the war) is a simple restful webapp that queries a single table using jdbc/hibernate/spring-data.

As it stands now I cannot use tcserver 2.6.4 because it is not starting up. I would also appreciate help in locating the tcserver source tree as I cannot find it on the site and a list of bugs that are backported, a list that is easily searchable?

Thanks for the help in advance!
Johnny


Here is the code in Tomcat 7.0.26 with the patch. This patch if (is == null) { return; } is the missing piece
apache-tomcat-7.0.26-src\java\org\apache\catalina\startup\ContextConfig .java (line 2146 start of method)

private void populateJavaClassCache(String className) {
        if (!javaClassCache.containsKey(className)) {
            String name = className.replace('.', '/') + ".class";
            InputStream is =
                    context.getLoader().getClassLoader().getResourceAsStream(name);
           if (is == null) {
                return;
            }
            ClassParser parser = new ClassParser(is, null);
            try {
                JavaClass clazz = parser.parse();
                populateJavaClassCache(clazz.getClassName(), clazz);
            } catch (ClassFormatException e) {
                log.debug(sm.getString("contextConfig.invalidSciHandlesTypes",
                        className), e);
            } catch (IOException e) {
                log.debug(sm.getString("contextConfig.invalidSciHandlesTypes",
                        className), e);
            }
        }
    }

Here is the stacktrace. Look at the NPE halfway down

02-Apr-2012 18:48:56.541 SEVERE [pool-3-thread-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: 
 org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/playbook]]
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:897)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
	at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1581)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
	at org.apache.tomcat.util.bcel.classfile.ClassParser.<init>(ClassParser.java:72)
	at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2120)
	at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2111)
	at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2046)
	at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2003)
	at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1892)
	at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1860)
	at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1846)
	at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1239)
	at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:846)
	at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:321)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5161)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	... 11 more

02-Apr-2012 18:48:56.541 SEVERE [pool-3-thread-1] org.apache.catalina.startup.HostConfig.deployDescriptor Error deploying configuration descriptor C:\apps\servers\vfabric-tc-server-developer-2.6.4.RELEASE\playbook-stable\conf\Catalina\localhost\playbook.xml
 java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/playbook]]
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:900)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
	at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1581)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

[rmorgan]

This is indeed an issue with tc Server 2.6.4 and is due to an incomplete backport of that fix. We are releasing tc Server 2.6.5 in late April which will fix this. In the meantime I'd suggest you work off tc Server 2.6.3 where this bug does not exist.

Sorry for the inconvenience,
-Ryan

[jmohseni]

Ryan thanks for the quick response. I will do your workaround for now.

One question: When applying your backports do you have different lifecycles for the different tc Servers (dev/standard/spring) editions? More specifically, do the Standard/Spring editions get higher priority for this correction or is everything on equal footing?

Cheers

[rmorgan]

Standard, Spring and Dev Edition all get equal treatment, the runtimes between the editions are identical.

Cheers,
-Ryan

[jmohseni]

Ryan thanks again. I hope this is my last post about this issue. I am having issues finding v2.6.3
I follow this link download 2.6.3 but once I click Download it routes me to v2.6.4. Please assist me with this.

Also my first post asks if there is a Spring tcServer patch/bug tracker (JIRA or Bugzilla etc) to see what is in/out.
Also I would like to know where to download the source for tcServer packages? The links I see don't take me there.

Thanks
Johnny

[rmorgan]

Hi Johnny,

I see the same issue, the 2.6.3 and 2.6.4 links point to the same location. I'm checking with some folks here to see if we can get that corrected.

-ryan

[rmorgan]

Hi Johnny,

tc Server 2.6.5 has been released which includes a fix for the issue you were seeing. Details are here.

Johnny