In our production environment we encounter Error 500 with some XPage - using Java bean. I have traced the problem to this: when application is built/clean by one of our developers, we get this conflict in classes:
RESViewBean$Kocka(985FB00AF0EEE24BC1258028004C47FE).class
RESViewBean$Kocka.class
RESViewBean$Resource(34A92B0BA75D7267C1258028004C47FC).class
RESViewBean$Resource.class
Build/clean by other developers (including me) removes these conflicting two classes. My thought - something with source control. But said developer did not set it up, and removing application from his list of applications in Designer client (what would break such link) does not help.
What intrigues me the most is the fact, it has no influence on development server and test application on production server (in different path). But production copy of the application will result in this exception:
17.2.2017 9:38: Exception Thrown
javax.servlet.ServletException: java.lang.NoClassDefFoundError: sk/posam/iis/mrp/xsp/RESViewBean$Resource
at com.ibm.xsp.webapp.FacesServlet.handleError(FacesServlet.java:653)
at com.ibm.xsp.webapp.FacesServlet.renderErrorPage(FacesServlet.java:482)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:183)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:588)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1335)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:865)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:808)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:577)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1319)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:662)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:482)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:357)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:313)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
Caused by: java.lang.NoClassDefFoundError: sk/posam/iis/mrp/xsp/RESViewBean$Resource
at sk.posam.iis.mrp.xsp.RESViewBean.updateResources(RESViewBean.java:69)
at sk.posam.iis.mrp.xsp.RESViewBean.<init>(RESViewBean.java:28)
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1688)
at java.beans.Beans.instantiate(Beans.java:189)
at java.beans.Beans.instantiate(Beans.java:80)
at com.sun.faces.config.ManagedBeanFactory$1.run(ManagedBeanFactory.java:222)
at java.security.AccessController.doPrivileged(AccessController.java:413)
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:216)
at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:291)
at com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:135)
What can possibly create those duplicate class files?
Just a rough guess:
We had a similar issue with custom controls and Xpages. One of our developers was working from a remote location, and it turned out that multiplication of XSP elements (Xpages and custom controls but also their localised language properties) happened during replication. The tricky part in our case was, that those multiple versions where only visible in Package Explorer view.
We never really found the real cause but I tend to believe that this had to do with him having to sign elements before doing a local preview. Then during replication of any re-signed element a duplication occurred. Something like a replication conflict.
We stopped that by making our colleague transmit his design elements independent from our development dB (via mail or be replication of a separate db). Then one of us internal developers would copy the elements into our main db. Also we decided that no one in the team would work directly on the server but on a local replica instead.
A bit tedious but from then on there was no more duplication.
Related
I'm running into a strange behavior with my liferay 6.2 (build 6210). I was trying to install the latest fixpack portal-84 and cannot start my server since. Since I reverted all fixpacks etc. and still the startup doesn't work I doubt the update is the reason. I get the following message Permission conversion to algorithm 6 has not been completed. Up until this point the startup looks normal. Strange thing is my database schema was never used for anything else than liferay 6.2.
10:42:13,566 ERROR [localhost-startStop-1][MainServlet:212] java.lang.IllegalStateException: Permission conversion to algorithm 6 has not been completed. Please complete the conversion prior to starting the portal. The conversion process is available in portal versions starting with 5203 and prior to 6200.
java.lang.IllegalStateException: Permission conversion to algorithm 6 has not been completed. Please complete the conversion prior to starting the portal. The conversion process is available in portal versions starting with 5203 and prior to 6200.
at com.liferay.portal.tools.DBUpgrader._checkPermissionAlgorithm(DBUpgrader.java:297)
at com.liferay.portal.tools.DBUpgrader.upgrade(DBUpgrader.java:135)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:181)
at com.liferay.portal.ee.license.StartupAction.doRun(Unknown Source)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:74)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1245)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:209)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
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.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635)
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:745)
Stopping the server due to unexpected startup errors
Is assume that something is wrong within my database (although I have no idea how that happened). When I start liferay with the embedded memory DB the startup works. There are only some other messages in the log because there are lucene files in filesystem without entries in memory db. select * from RELEASE_; states the correct version portal 6210 and my configured database connection is correct as well (tried with jndi resource in tomcat and with conenction information in portal-ext.properties). But maybe there is some other location where a version is saved and is vital to portal startup.
Did anyone ever had this behavior or is this a completely special case that is (more or less) exclusive to me?
Thanks ans regards. Sebastian
The upgrade script checks if the ResourceCode table is empty. It was used prior to Liferay 6, Liferay 6 upgrade scripts usually remove all data from it or the whole table whatsoever.
To overcome this issue I did all the steps according to this tutorial from Liferay. The only difference to your situation is that I'm using Liferay CE.
I have developed Web Application using Struts2. When I host my web application in Windows OS Jasper Reports (PDF formats) are opening correctly. But same war file if I host in Linux (RHEL OS) it is neither opening report, nor writing any logs. It will be in fetching mode only. Only for reports it is happening. JSP pages are opening correctly. Is it a OS issue or any other issue.
Some one already has posted similar question i.e. JR report is not generating on Linux using Struts 2. But no relevant answers.
I tried a lot but nothing is working out.
One instance when i stopped the operation (only once i got this) then I got following stack trace
WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [XXXXX] is still processing a request that has yet to finish. This is very likely to create a memory leak. You can control the time allowed for requests to finish by using the unloadDelay attribute of the standard Context implementation. Stack trace of request processing thread:
java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
java.io.File.exists(File.java:819)
net.sf.jasperreports.engine.util.JRResourcesUtil.resolveFile(JRResourcesUtil.java:283)
net.sf.jasperreports.repo.DefaultRepositoryService.getInputStream(DefaultRepositoryService.java:135)
net.sf.jasperreports.repo.InputStreamPersistenceService.load(InputStreamPersistenceService.java:48)
net.sf.jasperreports.repo.DefaultRepositoryService.getResource(DefaultRepositoryService.java:187)
net.sf.jasperreports.repo.RepositoryUtil.findInputStream(RepositoryUtil.java:304)
net.sf.jasperreports.repo.RepositoryUtil.getInputStreamFromLocation(RepositoryUtil.java:275)
net.sf.jasperreports.engine.fonts.SimpleFontExtensionHelper.loadFontFamilies(SimpleFontExtensionHelper.java:183)
net.sf.jasperreports.engine.fonts.FontExtensionsRegistry.getExtensions(FontExtensionsRegistry.java:56)net.sf.jasperreports.extensions.DefaultExtensionsRegistry.getExtensions(DefaultExtensionsRegistry.java:110)
net.sf.jasperreports.engine.util.JRStyledTextParser.<clinit>(JRStyledTextParser.java:83)
net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:121)
net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:88)
net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:103)
net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:61)
net.sf.jasperreports.engine.fill.JRFiller.createFiller(JRFiller.java:179)
net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:108)
net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:653)
net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:569)
net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:915)
XYZJasperAction.execute(XYZJasperAction.java:1008)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:483)
We were using two Tomcat server instances for 2 different web applications. When I reinstalled Apache Tomcat with single instance it was working. May be we have not set the port properly.
This appears to be a common error for java. I searched for the error but could find nothing specific to domino and the ACL issue.
I have a couple of java classes in my database. One is a HttpServlet class, the other an IHttpServlet factory. I also added just a regular class to the db for testing.
Any time I make any change to the ACL, the servlet will no longer run. If any of the java source document are open, it shows Resource is out of sync with the file system: mydb.nsf Press F9 or Select File>Refresh to select the file. That test class also displays this message.
I need to refresh the document and rebuild to get the servlet to run.
I was going to submit this to tech support but thought I would ask here first. Hopefully it is an issue that can be easily resolved.
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.
Is it possible to successfully deploy an assembly containing event handlers for a custom SharePoint list feature (thus, classes that depend on the Microsoft.SharePoint assembly) to a web application's bin instead of the GAC?
The option to do so certainly appears to be present in the XML markup in my feature's manifest.xml file. However, I've seen several references that deploying CAS policies for the assembly are a must with little instruction on how to successfully achieve this for an assembly that requires privileges like access to the SharePoint object model. I've also seen discussion suggesting that the GAC is nearly a requirement because of difficulties/issues with CAS.
I have been able to actually deploy the assembly to the folder. The security issues however, have been a big impediment. The only way I've been able to get my assembly to run (instead of simply erroring out with exceptions) is by elevating the web.config's trust level to <trust level="Full" originUrl=""> which won't fly in my environment. I'm hoping to verify that what I'm trying to do is possible before I continue to further wrestle with CAS.
If this is possible, if anyone has guidance or resources that would assist me in modifying my feature to deploy my event handlers in this fashion, I'd appreciate it.
Don't elevate the web.config's trust level - pretty large hammer for a tiny problem. You must package up a custom CAS policy in your WSP to grant your assembly higher privileges that the web.config bestows on it.
-Oisin
One way to approach this is to crank up the logging, record the various exceptions that are thrown and then write a CAS policy manually. This is a very probabalistic approach and rather painful.
It seems likely that all of the permission demands for any given method or class are known up front. If so, it should be possible to write a tool to statically analyse your code and dependant assemblies and compose the required CAS file. Unfortunately, I'm not aware of any tool that does this.
For what it's worth, GAC'ing your assembly seems much "lighter" than upping the trust level.
If I got your question right, you want to deploy a list event receiver to the web application's BIN directory.
This is not possible within SharePoint 2010, but I don't know if it was supported on MOSS 2007 (i guess it wasn't supported either).
This behavior is by design, because SharePoint internally uses the System.Reflection.Assembly.Load() Method to load the event receiver assembly. The Load() method does only work with fully qualified assembly names, thus requiring the assembly to reside in the global assembly cache.