nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OpenAPI server startup failed

System

We've upgraded to SP3 and are now getting the following error in the servletd_err.log file. Has anyone seen this before?

Exception: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at com.interwoven.api.service.IWServiceServer.startService(IWServiceServer.java:384)
at com.interwoven.api.service.IWServiceServer.startServiceList(IWServiceServer.java:312)
at com.interwoven.api.service.IWServiceServer.server(IWServiceServer.java:136)
at com.interwoven.teamsite.auth.TicketAuthenticator.startOpenAPIServer(TicketAuthenticator.java:95)
at com.interwoven.teamsite.auth.TicketAuthenticator.loadOpenAPISession(TicketAuthenticator.java:52)
at com.interwoven.framework.auth.openapi.OpenAPIAuthenticator.<init>(OpenAPIAuthenticator.java:57)
at com.interwoven.teamsite.auth.TicketAuthenticator.<init>(TicketAuthenticator.java:39)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at com.interwoven.framework.auth.openapi.OpenAPIAuthenticatorBuilder.instantiateAuthenticator(OpenAPIAuthenticatorBuilder.java:62)
at com.interwoven.framework.auth.openapi.OpenAPIAuthenticatorBuilder.load(OpenAPIAuthenticatorBuilder.java:43)
at com.interwoven.framework.auth.BaseServlet$1.onStartup(BaseServlet.java:102)
at com.interwoven.framework.base.Application$1.fireEvent(Application.java:123)
at com.interwoven.framework.base.Application.addApplicationListener(Application.java:361)
at com.interwoven.framework.auth.BaseServlet.init(BaseServlet.java:36)
at com.interwoven.framework.auth.LoginServlet.init(LoginServlet.java:79)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317)
at org.apache.tomcat.core.Handler.init(Handler.java:215)
at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296)
at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartupInterceptor.java:130)
at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491)
at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
Caused by: java.lang.NoSuchFieldError: workFlowCreatorName
at com.interwoven.api.ui.IWUIServiceRemoterImpl.initJNI(Native Method)
at com.interwoven.api.ui.IWUIServiceRemoterImpl.<init>(IWUIServiceRemoterImpl.java:72)
... 31 more
OpenAPI server startup failed. Trying OpenAPI server on localhost:1099

Find more posts tagged with

Comments

Migrateduser

Dude that's pretty self-explanatory.

Migrateduser

maybe for a guru like you....please explain.

Migrateduser

No I was just kidding, that looks like a mess.

I am totally guessing here but from the bottom part of the stack trace (Caused by: java.lang.NoSuchFieldError: workFlowCreatorName) it looks like this is getting generated when your .jsp tries to call the OpenAPI function to invoke a workflow. I think the root cause may be the XML you are passing to the IW method that creates the job. I think Interwoven is requiring some kind of "creator" attribute that is not in the XML you are passing which was not required in the previous version (but I am pretty sure you are passing creator, maybe the DTD has changed or something, or it's a bug in the IW method). I would add debugging to the .jsp (log to a file the XML you are passing to the method) if it is not already there. Then try iwjobc on that file and see if it gives you more detail (you may have to remove the duplicate files element from the XML file before calling iwjobc).

Let me know if that helps at all.

How is Dudley doing?

Migrateduser

We're actually getting that error when the server starts up. No workflowing is involved. Another error appears when a user tries to save a DCR, the window that comes up to list the folders to save in doesn't actually fully load. It doesn't list any folders. Then in the servletd_err.log the following shows up:

Retrying OpenAPI call IWService.locate(rmi://localhost:1099/IWUIService)

Dudley is doing ok....loving Iowa I'm sure...

Migrateduser

I think we had a similar problem once before - something else may have been running on the port that OpenAPI was trying to use? I'm sure you've rebooted several times by now? I think there was some feedback from Interwoven about configuring OpenAPI to use a range of ports, I don't remember the details. Unfortunately I can only suggest filing a case with them - this is way beyond my experience. Hopefully this patch hasn't been applied in production. I wonder if going straight to SP4 might help?

Migrateduser

I've already opened a case....havn't heard anything back as of yet.

Many reboots already....

SP3 was only installed on development. Actually we had some fun with that. The version of java in the <iw-home>\tools\java1.3\ was odd and when the SP was applied it updated several files in that tree which then screwed things up. Servlet engine wouldn't start, and several other things. We ended up having to do some funky stuff to get around it. I'm wondering if this problem isn't actually related to the weird java1.3 version problem.

Edited by chad_till on 09/26/03 12:59 PM (server time).

sajiddc

Chad_till,

could you please check and see if rmiregistry is running or not? If not, start rmiregistry first, and then try to start servletd

Migrateduser

chad_till,
Your problem seems to be that the upgrade did not go through well. The openapi_client.jar and openapi_server.jar are mismatched. Please verify whether the openapi_client.jar and openapi_server.jar in <iw-home>/iwopenapi and <iw-home>/httpd/webapps/webdesk/WEB-INF/lib match in size and timestamp. In case they do not, the jar files in <-iw-home>/iwopenapi are the correct jar files and they should be used in both the locations.

Hope this helps you.

Best Regards,
Narendra

Migrateduser

Narendra,

The .jar files did not match in size or date time stamp. I copied the versions from <-iw-home>/iwopenapi to both places and rebooted. I'm still seeing the same errors.

Thanks,
Chad

Migrateduser

Try this.
1. Shut down Interwoven.
2. Do a ps -ef and grep for "rmi"
3. See if there is a process like
/apps/iw-home/tools/java1.3/bin/../bin/sparc/native_threads/rmiregistry -J-Xrs
4. Kill this process.
5. Do a "netstat -a and grep for "1099", check if there is a process waiting on port 1099. Wait till you do not find any such process.
6. Restart interwoven.
If this does not work, then there is a workaround. Follow steps 1-5 as above, then start openapi manually:
nohup `iwgethome`/iwopenapi/iwopenapi &
and then restart Interwoven.

With SP3, openapi service should NOT be running as a seperate process. We have seen atleast on one of our boxes that this does not seem to work and we have to start open api as a seperate process.

Hope it works for you.

Regards,
Rajiv

Migrateduser

I think we've got this figured out. Our upgrade to SP3 didn't go well AT ALL and this is what caused our problems. We believe our problems stem from customizations done to our environment. We had to build a new instance without our customizations then copy over many core folders and directories.

Thanks for all the ideas.

Chad

Migrateduser

For some reason there was an inflated copy of the OpenAPI jar file. When we installed SP3 that inflated version caused problems. We removed this inflated version and the OpenAPI started without error.

Lesson for the day - Don't inflate vendor jar files.

Chad