VMware {code} Community
jybeip
Contributor
Contributor
‎11-05-2014 05:35 AM
Jump to solution

Unable to add a Configuration Tab

Hi everyone,

    I'm developing a vCO plug-in, using Eclipse and vCO SDK. I'm using the official documentation, which is based on the SolarSystem example plug-in. I have a problem when I try to add a Configuration Tab: when I try to access to the configuration page of my plug-in,

I get a HTTP 404 error with this message: "There is no Action mapped for namespace /config_general and action name Default.". It looks like it is a problem with Apache Struts, but I don't know what exactly. I've take a look again and again at the official documentation, it looks like I didn't do anything wrong ...

FIY, I'm using the struts.xml and web.xml from the SolarSystem plug-in.

Any help would be appreciated ...

0 Kudos
1 Solution

Accepted Solutions
sanchezs
VMware Employee
VMware Employee
‎11-06-2014 12:43 AM
Jump to solution

Hi jybeip,

I'd strongly recommend you to invest your time on enabling the configuration of your plug-in through simple vCO workflows instead of creating a web UI for the Configurator application.

The reasons are basically:

  • The Configurator application is reaching its end of live...
  • Implementing the configuration of a plug-in through workflows is easier at development time: no Struts!
  • Offering the configuration of a plug-in through workflows is more flexible: configuration workflows can be invoked as any other workflow, with all the benefits this has.
  • All the vCO core plug-ins are moving in that direction and you can see that most of them have a Configuration folder inside their out of the box workflow library.

I hope it helps.

Sergio

View solution in original post

0 Kudos
7 Replies
LudicrousSpeed
Contributor
Contributor
‎11-05-2014 06:46 AM
Jump to solution

jybeip,


There are a few possible causes to the error:


1. After install of the plugin, if the configuration service was not restarted this error will sometimes show. If you restart and the error persists then it is likely due to other issue.

2. Struts.xml has incorrect mapping. If you could share the file I can give it a read for any corrections.

3. There is an error in the underlying action:

example:

<action name="Default" class="com.opensymphony.xwork2.ActionSupport">
<result name="success" type="chain">List</result>
</action>
<action name="List" class="com.company.vco.plugx.core.HostListAction">
<result name="success">/WEB-INF/pages/list.jsp</result>
</action>

In this case, if the list.jsp and underlying code had issue you may see the error. You can check your configuration log for a more detailed output assuming that you have enabled logging in your underlying code.

You may also want to enable debug mode on Struts by adding the following to your struts.xml file:

<constant name="struts.devMode" value="true" />

0 Kudos
jybeip
Contributor
Contributor
‎11-05-2014 07:20 AM
Jump to solution

LudicrousSpeed


  Thanks a lot for your time!

1. I tried to restart the configuration service but I still get that error.

2. I uploaded my struts.xml, you'll see that it's quite the same as the SolarSystem's one.

3. Here's my "configuration.jsp":

<%@ page contentType="text/html; charset=UTF-8">

<%@ taglib prefix="s" uri="/struts-tags">

<html>

    <head><title>Hello</title></head>

    <body>

    </body>

</html>

Where can I get the logs after setting Struts in dev mode please?

By the way, I don't know if it's useful, I get that message in "Orchestrator/configuration/logs/wrapper-configuration.log": "Unable to load configuration adapter class 'com.eip.o11n.plugin.sds.config.sdsConfigurationAdaptor from the plug-in class loader".

Preview file
3 KB
0 Kudos
LudicrousSpeed
Contributor
Contributor
‎11-05-2014 08:40 AM
Jump to solution

jybeip,

It looks like in the struts.xml you define the default action to essentially call class="com.eip.o11n.plugin.sds.config.sdsConfigureAction"
Given the error it is saying that there is a problem with that java class being loaded.

In your class you can add logger capability such as ...

private static Logger log =  Logger.getLogger(<yourAdapter>.class);

Add in some log statements such as below to help determine where things are blowing up...

...} catch (Exception e) {
log.error("loadConfiguration() --> Unable to parse xml configuration content. Error [" +
e.getMessage() + "]");
}

And then add the logger via the log4j.xml to register the logger such as...

    <category additivity="true" name="<your class to log">

        <priority value="DEBUG" />

    </category>

As fyi, the struts debug is shown in the /var/lib/vco/configuration/logs/catalina.out so far as I'm aware.

sanchezs
VMware Employee
VMware Employee
‎11-06-2014 12:43 AM
Jump to solution

Hi jybeip,

I'd strongly recommend you to invest your time on enabling the configuration of your plug-in through simple vCO workflows instead of creating a web UI for the Configurator application.

The reasons are basically:

  • The Configurator application is reaching its end of live...
  • Implementing the configuration of a plug-in through workflows is easier at development time: no Struts!
  • Offering the configuration of a plug-in through workflows is more flexible: configuration workflows can be invoked as any other workflow, with all the benefits this has.
  • All the vCO core plug-ins are moving in that direction and you can see that most of them have a Configuration folder inside their out of the box workflow library.

I hope it helps.

Sergio

0 Kudos
jybeip
Contributor
Contributor
‎11-12-2014 01:46 AM
Jump to solution

Hi sanchezs,

Thanks for your advice! I will do that, it looks really simpler. Is there any official documentation about creating configuration workflows?

0 Kudos
jybeip
Contributor
Contributor
‎11-12-2014 01:47 AM
Jump to solution

Hi LudicrousSpeed,

   Thanks for your help and time, but I'm not going to use vCO Configuration anymore, like sanchezs recommends.

0 Kudos
sanchezs
VMware Employee
VMware Employee
‎12-09-2014 08:51 AM
Jump to solution

Hi jybeip,

Since the Configuration workflows are basically standard workflows, they have nothing special. You can check the code of configuration workflows from many plug-ins and you'll that basically you have:

  • One "add connection/host" workflow - which adds a new root element to your plug-in inventory, usually a connection or host item that represents an endpoint to a 3rd party system.
  • One "edit connection/host" workflow - which updates any existing connection/host.
  • One "delete connection/host" workflow - which deleted any existing connection/host.

And at the end, what those workflows do is more or less to use a singleton scripting object that you have to implement (e.g. MyPluginHostManager) which has the same methods implemented add/update/delete. Again, if you check any standard plug-in (e.g. SOAP, REST, AMQP, vCenter, vCloud, etc.) you will see that behavior.

Sergio

0 Kudos