OSGi update site fails with "null" error - osgi

Sometimes, after server restart all applications fail because of missing ExtLib libraries. They should be installed during HTTP startup from NSF update site. Server log shows:
HTTP JVM: CLFAD0330I: NSF Based plugins are being
installed in the OSGi runtime. For more information please consult the
log
HTTP JVM: null. For more detailed information,
please consult error-log-0.xml located
in /data/domino/workspace/logs
... repeated ~30x
Content of the error-log-0.xml is no help - fails show only as empty line. Thankfully there is another log file startup.log containing stack trace of the problem:
!ENTRY org.eclipse.osgi 4 0 2015-04-24 09:20:02.450 !MESSAGE Error
installing bundle:
osginsf:update/extlib.nsf/E7D8A0430DEAFDF2C1257B4F003FF202/com.ibm.xsp.extlib.core_8.5.3.20130315-0724.jar
!STACK 0 java.io.IOException at
com.ibm.domino.internal.protocol.osginsf.OSGiNSFUrlConnection.getInputStream(OSGiNSFUrlConnection.java:133)
at java.net.URL.openStream(URL.java:1022) at
org.eclipse.core.runtime.adaptor.EclipseStarter.installBundles(EclipseStarter.java:1105)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.loadBasicBundles(EclipseStarter.java:646)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.access$1(EclipseStarter.java:623)
at
org.eclipse.core.runtime.adaptor.EclipseStarter$1.bundleChanged(EclipseStarter.java:308)
at
... stripped ...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611) at
com.ibm.domino.http.bootstrap.osgi.LaunchRCP.startRCP(LaunchRCP.java:342)
at
com.ibm.domino.http.bootstrap.osgi.LaunchRCP.launchOSGIFramework(LaunchRCP.java:172)
at
com.ibm.domino.http.bootstrap.BootstrapOSGIClassLoader.launchOSGIFramework(BootstrapOSGIClassLoader.java:79)
at
com.ibm.domino.http.bootstrap.BootstrapOSGIClassLoader.loadClass(BootstrapOSGIClassLoader.java:63)
at java.lang.ClassLoader.loadClass(ClassLoader.java:638) at
com.ibm.domino.http.bootstrap.BootstrapClassLoader.findClass(BootstrapClassLoader.java:79)
!ENTRY org.eclipse.update.configurator 4 0 2015-04-24 09:20:02.762
!MESSAGE
D:\Lotus\Domino\data\domino\workspace.config\domino\eclipse\plugins\plugins
is not a valid plugins directory.
What catched my eye is the last line - the mentioned plugin directory does not exist (one extra '/plugins' directory).
The only workaround is to recreate update site from scratch (delete all content and reimport local update site).
BTW, I have found very old discussion, with no solution on ExtLib project site.
What is the cause of failed update? I can't tell whether IO exception is caused by wrong file path or dead URL to update site (network misconfiguration).

Problem was solved by increasing disk size for Domino binaries - it went out of space (and nobody noticed) by growth of Windows directory (Windows updates). Data and translog directories use different drives, so server was running with no "out of space" errors.
It seems IO Exception was thrown during unsuccessful disk write.

Related

wso2 esb deploy failed on windows

I'm using WSO2 ESB 4.8.1 with JDK 1.7.0_67 x64 on windows 7 x64.
I'm deploying carbon application(.car) using any method:
maven car deploy plugin
web admin console
CarbonAppUploader web service
First deployment succeeds but log file contains:
CarbonAppUploader temp file: C:\Java\WSO2ES~1.1\bin\..\tmp\carbonappsuploads\first-esb_1.0.0.car deletion failed, scheduled deletion on server exit.
Second deployment of same car (name and version) fails with exception in logs (see below)
I Apologize for localized error message but generally it says cant overwrite this file.
If you check, it's actually locked for deletion. Looks like CarbonAppUploader class didn't properly close InputStream.
Strangely enough this bug is not reproducible in unix (centos)
Question to WSO2: do you plan to fix that?
Question to all: Did you meet such bug and how did you solve it?
exception stack trace (partially)
TID: [0] [ESB] [2014-08-18 22:04:58,254] ERROR {org.wso2.carbon.application.upload.CarbonAppUploader} - Error occurred while uploading Carbon App artifacts {org.wso2.carbon.application.upload.CarbonAppUploader}
java.io.FileNotFoundException: C:\Java\WSO2ES~1.1\bin\..\tmp\carbonappsuploads\first-esb_1.0.0.car (Запрошенную операцию нельзя выполнить для файла с открытой пользователем сопоставленной секцией)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
at org.wso2.carbon.application.upload.CarbonAppUploader.writeResource(CarbonAppUploader.java:78)
at org.wso2.carbon.application.upload.CarbonAppUploader.uploadApp(CarbonAppUploader.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I checked out source code from svn, fixed bug myself. If anybody experiencing same issue, you may download sources and compiled jar from https://wso2.org/jira/browse/ESBJAVA-3272
Hopefully this bug fix will be included in next releases

Oracle Data Integrator (ODI - v11.1.1.3) "unable to load language: beanshell" Error

Following an install of Eclipse 3.7.2 on my Ubuntu 12.04 development machine, I have been unable to execute any ODI packages/interfaces/procedures. On execution (for both simulated and actual runs), an error is thrown (java trace below). I am not sure if it's anything to do with the Eclipse install, but it seems likely. Does anyone have an idea how to fix this?
Also, when launching ODI from the terminal using 'bash odi', the following error is displayed in the terminal:
2013-08-15 14:43:46.162 ERROR Error during RuntimeClassLoader initialization. ODI will start without RuntimeClassLoader
Error output:
oracle.odi.core.exception.OdiRuntimeException: Error during Code Interpretor creation
at com.sunopsis.dwg.codeinterpretor.SnpCodeInterpretor.getInstance(SnpCodeInterpretor.java:209)
at com.sunopsis.dwg.codeinterpretor.SnpGeneratorSQLCIT.<init>(SnpGeneratorSQLCIT.java:300)
at com.sunopsis.graphical.dialog.SnpsDialogExecution.doPackageExecuter(SnpsDialogExecution.java:907)
at oracle.odi.ui.action.SnpsPopupActionExecuteHandler.actionPerformed(SnpsPopupActionExecuteHandler.java:68)
at oracle.odi.ui.SnpsActionControler.handleEvent(SnpsActionControler.java:75)
at oracle.ide.controller.IdeAction.performAction(IdeAction.java:529)
at oracle.ide.controller.IdeAction.actionPerformedImpl(IdeAction.java:884)
at oracle.ide.controller.IdeAction.actionPerformed(IdeAction.java:501)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:809)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:850)
at java.awt.Component.processMouseEvent(Component.java:6297)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3275)
at java.awt.Component.processEvent(Component.java:6062)
at java.awt.Container.processEvent(Container.java:2039)
at java.awt.Component.dispatchEventImpl(Component.java:4660)
at java.awt.Container.dispatchEventImpl(Container.java:2097)
at java.awt.Component.dispatchEvent(Component.java:4488)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4575)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4236)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4166)
at java.awt.Container.dispatchEventImpl(Container.java:2083)
at java.awt.Window.dispatchEventImpl(Window.java:2489)
at java.awt.Component.dispatchEvent(Component.java:4488)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:674)
at java.awt.EventQueue.access$400(EventQueue.java:81)
at java.awt.EventQueue$2.run(EventQueue.java:633)
at java.awt.EventQueue$2.run(EventQueue.java:631)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:647)
at java.awt.EventQueue$3.run(EventQueue.java:645)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:644)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: org.apache.bsf.BSFException: unable to load language: beanshell
at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:718)
at com.sunopsis.dwg.codeinterpretor.SnpCodeInterpretor.loadEngine(SnpCodeInterpretor.java:85)
at com.sunopsis.dwg.codeinterpretor.SnpCodeInterpretor.<init>(SnpCodeInterpretor.java:75)
at com.sunopsis.dwg.codeinterpretor.SnpCodeInterpretor.getInstance(SnpCodeInterpretor.java:184)
... 45 more
After digging around for about a day on this issue, I brazenly tried running ODI as the root user on the off chance that this was a permissions issue. I started ODI from the command line (using 'bash odi') for greater verbosity, and it loaded without the error mentioned above. Something gave me the impression that this wasn't a permissions issue, but one related to the user settings.
To rectify the issue, I removed my user's odi settings folder (renaming it, for safety):
mv ~/.odi ~/.backup_odi
Then I started ODI from the terminal under my own user (i.e. not root) - there were no errors! None of my connections were available in the new settings folder though. This I fixed by closing ODI and entering the following:
cp ~/.backup_odi/oracledi/snps_login_work.xml ~/.odi/oracledi/
If anybody else encounters this issue, I hope you find this post quicker than it took me to fix it!
org.apache.bsf.BSFException: unable to load language: beanshell
The exception was thrown because bsh-2.Ob4.jar was not in the classpath and it is a dependent jar of bsf.jar

GWT causes Eclipse to fail to launch on Windows XP

Clicking on eclipse causes the splash screen to show then the application is killed silently with no error message. The .log file has the following information ( summarized)
!ENTRY org.eclipse.ui 4 4 2012-11-09 11:33:45.323
!MESSAGE Class load Failure: 'com.google.gdt.eclipse.login.ui.LoginTrimContribution'
!ENTRY org.eclipse.ui 4 0 2012-11-09 11:33:45.323
!MESSAGE Class load Failure: 'com.google.gdt.eclipse.login.ui.LoginTrimContribution'
!STACK 1
org.eclipse.core.runtime.CoreException: Plug-in "com.google.gdt.eclipse.login" was
unable to instantiate class "com.google.gdt.eclipse.login.ui.LoginTrimContribution".
Caused by: java.lang.ExceptionInInitializerError
at com.google.gdt.eclipse.login.ui.LoginTrimContribution.<init>(LoginTrimContribution.java:129)
...
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:184)
... 51 more
Caused by: java.lang.NullPointerException
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187)
at com.google.api.client.auth.oauth2.draft10.AccessProtectedResource.<init>(AccessProtectedResource.java:184)
at com.google.api.client.googleapis.auth.oauth2.draft10.GoogleAccessProtectedResource.<init>(GoogleAccessProtectedResource.java:87)
at com.google.gdt.eclipse.login.GoogleLogin.loadLogin(GoogleLogin.java:628)
at com.google.gdt.eclipse.login.GoogleLogin.<clinit>(GoogleLogin.java:98)
and a bunch of other error messages revolving around com.google.gdt.eclipse.login
A google searched yielded nothing about eclipse.login. The package is not in the .metadata/.plugins directory and deleting other google packages or .properties did nothing.
Hoping someone encountered this before and has a work around. Nothing major changes to system or eclipse or Java before this error occurred other than I hadn't launched in a few weeks.
Eclipse EE Indigo
in the Eclipse software plugin folder I found that the com.google.gdt.eclipse.login package file had a version number attached to the end of the file name something like 3.03_v1 etc. I renamed this to just com.google.gdt.eclipse.login.jar and eclipse launched.
I am not sure how the file name changed and why it suddenly stopped working but that solved the issue.

Configuring Teamcity's logging behaviour

I'm using Teamcity 5 for our CI environment. It's a great tool, but I've been struggling with one thing: the stdout_yyyyMMdd.log file in the \TeamCity\logs folder grows to ridiculous sizes. Is there a way to turn it off?
Places I've looked so far:
Jetbrains: Nothing on stdout;
Google for "tomcat stdout logs": the first few links don't really address the issue.
Edit:
At KIR's suggestion, I actually looked to see what's in stdout. It's the same exception message repeated over and over again:
[2010-12-01 08:57:21,268] WARN - jetbrains.buildServer.SERVER - java.io.FileNotFoundException: <...Path...>\.BuildServer\system\caches\search\_8p.prx (The system cannot find the file specified)
[2010-12-01 08:57:21,315] ERROR - erverSide.search.SearchService - SearchService.enqueueHistory
java.io.FileNotFoundException: <...Path...>\.BuildServer\system\caches\search\_8p.prx (The system cannot find the file specified)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(Unknown Source)
at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput$Descriptor.<init>(SimpleFSDirectory.java:78)
at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.<init>(SimpleFSDirectory.java:108)
at org.apache.lucene.store.SimpleFSDirectory.openInput(SimpleFSDirectory.java:65)
at org.apache.lucene.index.SegmentReader$CoreReaders.<init>(SegmentReader.java:132)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:638)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:599)
at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:104)
at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:27)
at org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:476)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:314)
at jetbrains.buildServer.serverSide.search.SearchService.getIndexSearcher(SearchService.java:451)
at jetbrains.buildServer.serverSide.search.SearchService.enqueueHistory(SearchService.java:515)
at jetbrains.buildServer.serverSide.search.BackgroundIndexer.run(BackgroundIndexer.java:32)
at java.lang.Thread.run(Unknown Source)
Any idea what this file is?
If you're running TC on unix you could use logrotate: http://linuxcommand.org/man_pages/logrotate8.html (Obviously, this is a workaround but it should be effective.)
This guy has a windows equivalent that may do the trick too: http://www.datori.org/?p=7
Remove .BuildServer\system\caches\search directory and restart TeamCity. May be this would help.
The problem is caused by someone or something deleting the Lucene Index in Team city.
Everytime you hit a page after this it will log in stdout that it couldnt find the file.
If you clear out the whole folder which should be
%USERPROFILE%.BuildServer\system\caches\search\
See http://confluence.jetbrains.net/display/TCD5/TeamCity+Data+Directory for more information on where to find the folder.
And restart Teamcity it will recreate the index on start up and stop logging the error message.
Oh and search should start working again too.

OC4J 10.1.3.3 unable to find ojms.rar setting up database persistences

I'm running into problems with JMS in Oracle AS 10.1.3.3.
The error I am getting is 'connectors\ojms.rar (The system cannot find the path specified)' from EM.
Below are a few bullets on the environment.
This is on a Windows XP SP3 machine.
All configuration is through EM.
The EM is a local instance that has been used for over a year.
This instance has existing db connection management exposed through JNDI.
Oracle_home is set to the directory where I unzip the OC4J zip file. c:\oc4j_10.1.3.3.
ojms.rar file is in %ORACLE_HOME%\j2ee\home\connectors
Configuring OC4J for JMS with Database Persistence
I've create a new data connection for Oracle AQ and exposed the connection through JNDI as jms/flexc
When creating the Resource Adapter through EM, I'm providing the following information:
Resource Name: JMS on FlexC
Adding a new resource
Name : jmsFlexc
Datasource JNDI : jms/flexc (selected from dropdown box)
Very quickly, I get the error below:
An error has occurred.
connectors\ojms.rar (The system cannot find the path specified)
connectors\ojms.rar (The system cannot find the path specified)
[Select to hide information] Hide Additional Trace Information
oracle.sysman.ias.studio.j2ee.deploy.DeployUtil$DeploymentFailureException at
oracle.sysman.ias.studio.j2ee.deploy.DeployUtil.deployArchive(DeployUtil.java:211) at
oracle.sysman.ias.studio.j2ee.deploy.DeployUtil.deployArchive(DeployUtil.java:85) at
oracle.sysman.ias.studio.oc4j.jms.JMXDeployDbProviderAdminBean.deployDBProviderAndConfigure(JMXDeployDbProviderAdminBean.java:121) at
oracle.sysman.ias.studio.oc4j.jms.DeployDbProviderHelper.deployDBProvider(DeployDbProviderHelper.java:242) at
oracle.sysman.ias.studio.oc4j.jms.DeployDbProviderHelper.handleEvent(DeployDbProviderHelper.java:127) at
oracle.sysman.ias.studio.sdk.AbstractController.handleEvent(AbstractController.java:769) at
oracle.sysman.emSDK.svlt.PageHandler.handleRequest(PageHandler.java:378) at
oracle.sysman.emSDK.svlt.EMServlet.myDoGet(EMServlet.java:765) at
oracle.sysman.emSDK.svlt.EMServlet.doGet(EMServlet.java:283) at
oracle.sysman.ias.studio.app.StudioConsole.doGet(StudioConsole.java:385) at
oracle.cabo.servlet.UIXServlet.doPost(Unknown Source) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at
oracle.sysman.ias.studio.app.BrowserVersionFilter.doFilter(BrowserVersionFilter.java:75) at
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:15) at
oracle.sysman.ias.studio.app.MultipleJVMFilter.doFilter(MultipleJVMFilter.java:85) at
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:17) at
oracle.sysman.ias.studio.app.PostLogonFilter.doFilter(PostLogonFilter.java:80) at
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:17) at
oracle.sysman.ias.studio.app.ShortHostnameRedirectFilter.doFilter(ShortHostnameRedirectFilter.java:68) at
com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621) at
com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at
com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871) at
com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453) at
com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:221) at
com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:122) at
com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:111) at
oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at
oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:239) at
oracle.oc4j.network.ServerSocketAcceptHandler.access$700(ServerSocketAcceptHandler.java:34) at
oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:880) at
com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at
java.lang.Thread.run(Thread.java:619) Caused by: oracle.oc4j.admin.jmx.shared.exceptions.JMXRuntimeException: connectors\ojms.rar (The system cannot find the path specified) at
oracle.oc4j.admin.jmx.shared.util.JarTool.(JarTool.java:122) at
oracle.sysman.ias.studio.j2ee.deploy.DeployPageUtil.getArchiveType(DeployPageUtil.java:105) at
oracle.sysman.ias.studio.j2ee.deploy.DeployUtil.deployArchive(DeployUtil.java:133) ... 33 more Caused by: java.io.FileNotFoundException: connectors\ojms.rar (The system cannot find the path specified) at
java.util.zip.ZipFile.open(Native Method) at
java.util.zip.ZipFile.(ZipFile.java:114) at
java.util.jar.JarFile.(JarFile.java:135) at
java.util.jar.JarFile.(JarFile.java:99) at
oracle.oc4j.admin.jmx.shared.util.JarTool.(JarTool.java:119) ... 35 more
Discovered that this is a bug in OC4J.
The solution was found by a colleague as a comment made to this blog
I also got an error when deploying the
resource adapter. I found that this
was a bug in Oracle Standalone
10.1.3.3.0 (bug 6786060 on Metalink) and can be solved either by using
10.1.3.2.0 or by starting Oracle standalone without the ORACLE_HOME
environment variable. This is made by
the command "java -jar oc4j.jar". I
used the last solution and it worked
fine for me.

Resources