After I set the Yang node through NETCONF in a feature project of opendaylight, I got the following error when I read this node. The data feels like it has been set, but there is this error when reading it. What is the possible problem? Thanks!
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="13">
<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message>Unexpected error</error-message>
<error-info>
<ERROR>java.lang.ClassCastException: org.opendaylight.yangtools.yang.data.impl.schema.builder.impl.ImmutableMapNodeBuilder$ImmutableMapNode cannot be cast to org.opendaylight.yangtools.yang.data.api.schema.ContainerNode</ERROR>
</error-info>
</rpc-error>
</rpc-reply>
does "set the node" mean that you are mounting a netconf device? when you do
that, do you see any errors in karaf.log? You may see extra info, as well, in
karaf.log when you read the node. Not quite enough information in your question
for me to help much more. Oh, you could search opendaylight's jira for other
reported problems with ClassCastException
Related
I'm trying to get the Watson Visual Recognition to run client side by using express-browserify with reference to the node-sdk for watson-developer-cloud. The VisualRecognitionV3 makes use of the fs package hence I get the fs.existsSync error when I'm trying to call it from the client-side as the browser doesn't know which filesystem to use. My question is how do I go about creating a so called 'abstraction layer' as I am restricted to using the express-browserify package for cross origin calls.
This thread is pretty helpful in shedding some light but I'm not sure where to start regarding the 'abstraction layer' or if there are any other solutions. Also, would something like socket.io work for this? I've linked a clone of the directory here as it seems less clunky than pasting the multiple portions below.
The repository can be cloned and just requires a personal iam_apikey with relevant launch configuration. Appreciate any pointers. Thanks!
I didn't manage to sort this out with express-browserify due to the require(fs) from browser issue but I was able to get it running using the express-ws package
The following message can be found in the server log in the file system on the Domino server:
java.lang.NullPointerException
at com.ibm.xsp.component.UIDataPanelBase.encodeEnd(UIDataPanelBase.java:280)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:856)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.component.UIViewRootEx._renderView(UIViewRootEx.java:1317)
at com.ibm.xsp.component.UIViewRootEx.renderView(UIViewRootEx.java:1255)
at com.ibm.xsp.application.ViewHandlerExImpl.doRender(ViewHandlerExImpl.java:641)
at com.ibm.xsp.application.ViewHandlerExImpl._renderView(ViewHandlerExImpl.java:320)
at com.ibm.xsp.application.ViewHandlerExImpl.renderView(ViewHandlerExImpl.java:335)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:103)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:210)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
at com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:219)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
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:583)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
Is there any way to get more info about the error? If there is, how to get more details?
First, I would suggest that you install the LogReader from OpenNTF.org by Jakob Majkilde (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Log%20File%20Reader). It will give you easy access to the various logfiles on the server. You may need to look at different log files for specific issues - sometimes they land in the not so obvious place ;-)
When you have installed the log reader then look at messages just after (or perhaps before) the message above. In many cases several exceptions will be thrown - and you should look for the ones that refer to your own code. Changes are that you have missed initialization of an object in your own code. If you code in Java then the logs will be even more helpful.
In addition you could (should) consider using some kind of logging mechanism in your own code to tell you how far in loading/processing a page you are before failing. You could use the XPages OpenLog Logger: http://www.openntf.org/main.nsf/project.xsp?r=project/XPages%20OpenLog%20Logger
/John
I can access this API/WS through
http://localhost:8080/ode/processes/ProcessManagement?wsdl.
I would like to get the Process Info of a Process through this service and active it.
The serivce has the matching operations getProcessInfo and activate.
With listAllProcesses I get all Processes of a delpoyed package.
For getProcessInfo/activate I need the Process pid.
I get a <ns:pid>, using this gets me a load of Exceptions.
Using the name of the process and other stuff I receive earlier doesn't work either.
The pid is of type QName, perhaps thats the root of the problem.
However I don't now how to typecast here.
(Tried all with the eclipse Web Services Explorer and soapUI)
question: How does a proper request for both Operations look like?
When I try to consume the webservice with axi2 via eclipse, there is a undeclared variable local in the AnySimpleType class. I'm not keen on using the service this way.
But since I'm already writing a Client for the DeploymentService I thought about this approach.
question: How do I properly access the ProcessManagement?
EDIT: I have a simular problem with the DeploymentService and the undeploy Operation.
EDIT2: I figured the Problem with the DeploymentService undeploy out.
I had to get the Packagename as String. Then a made a javax.xml.namespace.QName out of it. Then I used the setPackageName of said undeploy operation.
Answer to question number 1:
soapUI with listAllProcesses returns
<ns:pid>{ode/bpel/unit-test}HelloWorld2-1</ns:pid>
getProcessInfo wants
<pmap:getProcessInfo>
<pid>?</pid>
</pmap:getProcessInfo>
Now I replaced <pid>?</pid> with
<pid xmlns:odetest="http://ode/bpel/unit-test">odetest:HelloWorld2-1</pid>
and it worked like a charm.
I remember that there was an issue with parameter ordering when using the Axis2 generated WSDL. Could you try if building a request against the original WSDL located at http://localhost:8080/ode/deployment/services/ProcessManagement works?
EDIT: Now that I got the question correctly, the problem is that ODE expects the QName to be serialized differently, i.e. in the XML way instead of the Java way. Thus, instead of <ns:pid>{ode/bpel/unit-test}HelloWorld2-1</ns:pid> the correct notation is <ns:pid xmlns:odetest="ode/bpel/unit-test">odetest:HelloWorld2-1</ns:pid>.
We have a custom exception handling behaviour (implementing IErrorHandler) in our solution which essentially uses Automapper to convert exceptions to faults.
This has been working well since day 1. However we have just noticed while browsing ServiceTraceViewer (looking at server logs - not client) on our shared development server that any faults returned from our services omit the detail element.
Running exactly the same code and configuration on my development machine, the detail element is correctly populated. As I say configuration files (behaviours, bindings) are identical on both machines. Both configurations do specify includeExceptiondetailsInFaults = true.
I've also added a bunch of log statements that seem to indicate that the same code path is followed on both machines with the same values for various things like fault code, fault reason etc.
My dev machine is 2008R2 standard (64bit). The server in question is also 2008R2 Standard (64 bit).
I can post extracts of the code if required, but in the first instance is there anything environmental that could allow for what we're seeing?
Extract from problem file:
<s:Body u:Id="_1">
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-NZ">An error occured during the request to the ...</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
Not 100% sure about etiquette here. This is an answer I guess to my specific brand of stupidity. Maybe somebody else will be as stupid, then the answer applies to them...
I was sure I had compared everything (I stated exactly the same code / configuration). But the behaviour configuration file I just gave a quick visual. After another developer approached me I realised that the local files were NOT the same as the server files. Doh!
In fact the server files had one extra line added by a post build step - triggering another custom behaviour which implemented IErrorHandler in addition to the IErrorHandler behaviour we already use for logging etc.
I guess I'm going to open another question now which seeks an answer to the approach on having multiple behaviours implementing the same interface and not polluting eachothers functionality (like returning Faults).
I checked out the latest SVN trunk of qooxdoo and now i have the following problems:
Some events seems that they are not comming through
Virtual Lists are not filled anymore (the _createWidget() method of the extension from qx.ui.virtual.cell.AbstractWidget is not called)
My original version was QX 1.0.1-pre and the problems appeared also when i tried to migrate to 1.2
Just to get the obvious stuff out of the way, did you follow the steps of the migration guide and make any necessary changes outlined in migration.log?
Aside from that, the virtual widgets are still experimental and no migration path is provided, meaning you'll have to go over your code and check if the parts of the ui.virtual API you're using have changed since 1.0.1.
For the missing events, please provide some more information: What events are you listening for?
The problem with the event seems to be a bug in Qooxdoo