We Keep Coding

JRuby warbler "compiled" command produces ClassCastException in Tomcat

I'm using warbler to package my JRuby web app into a war file and am deploying it to Apache Tomcat 8.0.21. This works well. However, I'm trying to run warbler using the "compiled" command instead:
warble compiled war
When I deploy the resulting war file, I'm getting the following exception :
org.jruby.rack.RackInitializationException: load error: /apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/config/boot -- java.lang.ClassCastException: java.lang.Object cannot be cast to java.lang.invoke.SwitchPoint
from org/jruby/RubyKernel.java:1054:in `require'
from jar:file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-stdlib-1.7.4.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36:in `require'
from file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-rack-1.1.13.3.jar!/jruby/rack/rails/environment3.rb:23:in `load_environment'
from file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-rack-1.1.13.3.jar!/jruby/rack/rails_booter.rb:79:in `load_environment'
from <script>:1:in `(root)'
at org.jruby.rack.RackInitializationException.wrap(RackInitializationException.java:29)
at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:98)
at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4728)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5166)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
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.deployWAR(HostConfig.java:940)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1738)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:724)
Caused by: org.jruby.exceptions.RaiseException: (LoadError) load error: /apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/config/boot -- java.lang.ClassCastException: java.lang.Object cannot be cast to java.lang.invoke.SwitchPoint
at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1054)
at RUBY.require(jar:file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-stdlib-1.7.4.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36)
at RUBY.load_environment(file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-rack-1.1.13.3.jar!/jruby/rack/rails/environment3.rb:23)
at RUBY.load_environment(file:/apache-tomcat-8.0.21/webapps/ROOT/WEB-INF/lib/jruby-rack-1.1.13.3.jar!/jruby/rack/rails_booter.rb:79)
at RUBY.(root)(<script>:1)
How come the compiled version is producing an exception? Any help is appreciated. Thanks!

I think this was a bug related to the warbler gem. I just upgraded my JRuby version from 1.7.4 to 1.7.5 and also upgraded warbler from 1.4.3 to 1.4.8 and that fixed this issue.

Placeholder not resolved in #PropertySource annotation in jar when warred up

I have a jvm arg, JAVA_OPTS=-Dblah.env=Something, set in the startUp.bat for the tomcat. The arg is used in a jar in the war, it's giving me an java.lang.IllegalArgumentException: Could not resolve placeholder. I don't have this issue when I run it via run-app.
Structure: run war in tomcat, the war has a jar that tries #PropertySource({"classpath:blahClient${blah.env}.properties"}) and gets the 'Could not resolve placeholder'
Note: I also have a line in my resources.groovy similar to:
blahClientConfig(BlahClientConfig) {
application.refresh()
}
Stack trace:
java.lang.IllegalArgumentException: Could not resolve placeholder 'blah.env' in string value "classpath:blahClient${blah.env}.properties"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:173)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:125)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:151)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:142)
at org.springframework.core.env.AbstractEnvironment.resolveRequiredPlaceholders(AbstractEnvironment.java:464)
at org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:186)
at org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:147)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:133)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:286)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:227)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:623)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:454)
at org.codehaus.groovy.grails.commons.spring.DefaultRuntimeSpringConfiguration.getApplicationContext(DefaultRuntimeSpringConfiguration.java:153)
at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:170)
at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:127)
at org.codehaus.groovy.grails.web.context.GrailsConfigUtils.configureWebApplicationContext(GrailsConfigUtils.java:121)
at org.codehaus.groovy.grails.web.context.GrailsContextLoader.initWebApplicationContext(GrailsContextLoader.java:107)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:5016)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5528)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1095)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1930)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
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:744)
Why doesn't the jar see the jvm arg blah.env?

Turns out to be a stupid question I had JAVA_OPTS=-Dblah.env=Something when I should have had set JAVA_OPTS=-Dblah.env=Something

Error in tomcat in creation of web service

I created simple addition of two number web services by using bottom up approach by using Axis 2 in eclipse juno.Web services working correctly and properly tested by soa client mozilla extension but there is error in tomcat.Please go through below error
he Calculator service, which is not valid, caused
java.lang.NoClassDefFoundError: javax/ws/rs/Produces
at org.apache.axis2.jaxrs.JAXRSUtils.getClassModel(JAXRSUtils.java:53)
at org.apache.axis2.description.java2wsdl.DefaultSchemaGenerator.generateSchema(DefaultSchemaGenerator.java:272)
at org.apache.axis2.deployment.util.Utils.fillAxisService(Utils.java:468)
at org.apache.axis2.deployment.ServiceBuilder.populateService(ServiceBuilder.java:388)
at org.apache.axis2.deployment.repository.util.ArchiveReader.buildServiceGroup(ArchiveReader.java:101)
at org.apache.axis2.deployment.repository.util.ArchiveReader.processServiceGroup(ArchiveReader.java:178)
at org.apache.axis2.deployment.ServiceDeployer.deploy(ServiceDeployer.java:82)
at org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136)
at org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:813)
at org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144)
at org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:377)
at org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:254)
at org.apache.axis2.deployment.DeploymentEngine.loadServices(DeploymentEngine.java:142)
at org.apache.axis2.deployment.WarBasedAxisConfigurator.loadServices(WarBasedAxisConfigurator.java:283)
at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:95)
at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:584)
at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:454)
at org.apache.axis2.webapp.AxisAdminServlet.init(AxisAdminServlet.java:60)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1280)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1193)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5176)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5460)
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:744)
Caused by: java.lang.ClassNotFoundException: javax.ws.rs.Produces
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1702)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
... 30 more
[INFO] org.apache.axis2.deployment.DeploymentException: java.lang.NoClassDefFoundError: javax/ws/rs/Produces
[INFO] Deploying Web service: version.aar - file:/M:/mahesh/work/javaws1/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Calc/WEB-INF/services/version.aar
[WARN] No transportReceiver for org.apache.axis2.transport.http.AxisServletListener found. An instance for HTTP will be configured automatically. Please update your axis2.xml file!

Tomcat is just a servlet container and AFAIK, it does not support any kind of webservices by default.
You have to have the required libraries in your WEB-INF/lib or add it to tomcat lib folder and make use of it.
you are getting ClassNotFoundException as javax/ws/rs/Produces is not found in the classpath.
Deploy the REST implementation (Ex: Jersey) to server lib and restart your server.

Try removing annotations in your Axis2 service class. In our case, removing #Deprecated solved the error.

How to use catalina.jar

I'm using websocket function of tomcat 7.0.39, so I have to include catalina.jar into my classpath. But when I deploy my project, if I deploy the jar files into WEB-INF/lib, I get the following exception:
java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml addServlet
and when catalina.jar is not deployed, I get ClassNotFoundException:
java.lang.ClassNotFoundException: org.apache.catalina.websocket.MessageInbound
Someone please help me.
StackTrace:
java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml addServlet
at org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:802)
at org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:201)
at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1057)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:604)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1759)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2915)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1543)
at org.apache.catalina.startup.ContextConfig.parseWebXml(ContextConfig.java:1694)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1197)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:882)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:317)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5081)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:774)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:727)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.startup.Catalina.start(Catalina.java:620)
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:616)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431)

The web socket support in 7.0.x is experiemental (and will soon be deprecated and replaced with a port of the JSR 356 implementation from Tomcat 8).
A side-effect of this is that the API can and does change between point releases. Therefore, you must compile your code againt the Tomcat JARs from the Tomcat version you intend to deploy on. There errors you are seeing are an indication of a version mis-match.
There is no need to package any Tomcat JARs in your web application.

Do you really need to put the catalina.jar in your classpath. Catalina.jar should already be present in tomcat/lib directory. Tomcat class loader will load the jar from its own lib directory and hence it is the parent class loader so your classpath or application catalina.jar will not picked. Hope you will be able to resolve your problem with this information.
You are getting NoSuchMethodDefinition error, which means the jar which you are using for compiling has that method but the jar, which is loaded for execution does not have that method definition. Check with replacing the catalina.jar in tomcat/lib with the jar that you are using for compiling your code.

How to backport a 6.1.1 jsf portlet to get it running on a 6.1.0 liferay portal?

I'm trying to get an 6.1.1 Portlet running on a 6.1.0 Liferay CE Portal. The JSF Portlet uses the ServiceBuilder and a lot of other Util API classes of Liferay.
I thought the best idea would be to recompile the portlet with the correct liferay-plugins-sdk.
After downloading the 6.1.0 SDK, replacing it in the eclipse project, and rebuild it, I get
a couple of exceptions. They occur immediately after starting the server.
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Bean class [com.liferay.portal.kernel.spring.util.SpringFactoryUtil] not found
Offending resource: ServletContext resource [/WEB-INF/classes/META-INF/cluster-spring.xml]
Bean ''; nested exception is java.lang.ClassNotFoundException: com.liferay.portal.kernel.spring.util.SpringFactoryUtil
at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:291)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:491)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:396)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:365)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.processBeanDefinition(DefaultBeanDefinitionDocumentReader.java:258)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:153)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:132)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
at com.liferay.portal.spring.context.PortletApplicationContext.loadBeanDefinitions(PortletApplicationContext.java:76)
at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:282)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:204)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
at com.liferay.portal.spring.context.PortletContextLoaderListener.contextInitialized(PortletContextLoaderListener.java:99)
at com.liferay.portal.kernel.servlet.PortalClassLoaderServletContextListener.doPortalInit(PortalClassLoaderServletContextListener.java:91)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:42)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:61)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:53)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:52)
at com.liferay.portal.kernel.servlet.PortalClassLoaderServletContextListener.contextInitialized(PortalClassLoaderServletContextListener.java:50)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5260)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1362)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1450)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:295)
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.ContainerBase.backgroundProcess(ContainerBase.java:1338)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1496)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1506)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1485)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: com.liferay.portal.kernel.spring.util.SpringFactoryUtil
at java.lang.ClassLoader.findClass(ClassLoader.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.liferay.portal.spring.util.FilterClassLoader.loadClass(FilterClassLoader.java:41)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:257)
at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:63)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.createBeanDefinition(BeanDefinitionParserDelegate.java:616)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:472)
... 41 more
Has someone a good idea? I also posted this issue on the official forum , but maybe here I reach more people...
Here is the link to the forum: http://www.liferay.com/community/forums/-/message_boards/message/19124222
==== Update 1====
To solve the above exception I ran the service-builder within the 6.1.0 portlet again.
Now it is possible to start the server with the portlet, buuut
the portlet is not visible/available in the portal for adding in a page and I get the
following ClassNotFoundException: PortletBeanLocatorUtil:
12:24:06,627 ERROR [PortletContextLoaderListener:132] java.lang.ClassNotFoundException: com.liferay.util.bean.PortletBeanLocatorUtil
java.lang.ClassNotFoundException: com.liferay.util.bean.PortletBeanLocatorUtil
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1533)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.liferay.portal.spring.context.PortletContextLoaderListener.contextInitialized(PortletContextLoaderListener.java:118)
at com.liferay.portal.kernel.servlet.PortalClassLoaderServletContextListener.doPortalInit(PortalClassLoaderServletContextListener.java:91)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:42)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.flushInits(PortalLifecycleUtil.java:45)
at com.liferay.portal.servlet.MainServlet.initPlugins(MainServlet.java:813)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:347)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5001)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5289)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:842)
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:439)
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:680)
Thanks for any suggestions!

It's probably easier to recompile the portlet in the 6.1.0 sdk. Especially when you use ServiceBuilder: you're running with a code generator that is probably relying on the runtime files that come matching runtime to generated code.
For pure JSR-286 portlets, they are easily compatible even across major versions. If you use more sophisticated code, e.g. ServiceBuilder or the API, lots of effort is taken to keep it compatible, but no guarantee can be given that it actually is binary compatible - sorry, that's life.
For Liferay's own plugins, you're asked to use matching versions - they're not tested between updates. And they most likely use ServiceBuilder and the API as well.