UserSession null and PropertyProviderAdapter

[walkaboot]

I've been following the vsphere-wssdk-provider sample provided in the Web Client SDK.  Using the vsphere-client-library I'm trying to retrieve vCenter session information using vise.usersession.UserSession and vise.usersession.UserSessionService.  The sample sets up a PropertyProviderAdapter to pass session data between the client UI and the Java Service by creating a DataServiceExtensionRegistry.

   public VmDataProviderImpl(

            UserSessionService userSessionService,

            VimObjectReferenceService vimObjectReferenceService,

            DataServiceExtensionRegistry registry) {

      _userSessionService = userSessionService;

      _vimObjectReferenceService = vimObjectReferenceService;

      registry.registerDataAdapter(this, getProvidedTypeInfos());

   }

  I can make this work successfully but my goal is to eliminate the need to use the PropertyProviderAdapter to get session info.  I would like to be able to do something like:

private final UserSessionService _userSessionService;

   public ServiceImpl(

            UserSessionService userSessionService

            ) {

      _userSessionService = userSessionService;

   }

   private ServerInfo getServerInfoObject() {

      UserSession userSession = _userSessionService.getUserSession();

      ServerInfo[] sinfo = userSession.serversInfo;

      return sinfo[0];

   }

   private ServiceContent getServiceContent() {

      ServerInfo serverInfoObject = getServerInfoObject();

      String sessionCookie = serverInfoObject.sessionCookie;

      String serviceUrl = serverInfoObject.serviceUrl;

   }

The vsphere-wssdk-provider sample uses 'serverGuid' to return ServerInfo but without the using the PropertyProviderAdapter it looks like I won't be able to grab the serverGuid.

String serverGuid = _vimObjectReferenceService.getServerGuid(vmRef);  //vmRef is grabbed by the PropertyRequestSpec

I need to grab the IP of vCenter and cookie for the current session, which are both properties of a ServerInfo bbject but I would like to know how to achieve this without setting up the PPA.

Thanks for any help you can provide.

[laurentsd]

Sure, you can inject the UserSessionService in any java service code like you were showing.  What was not working when you tried?

Once you get a hold of the ServerInfo array userSession.serversInfo you will have to select which vCenter you are interested in.

In the case of the PPA sample we use the serverGuid of the context object passed to the adapter, but if you are not passing any information to your service you need another way to select the server you want to talk to since the Web client may be connected to multiple vCenter servers.

[walkaboot]

Actually I spoke too soon.  I can inject and the UserSessionService and the object is not null, however, when I try to get the ServerInfo object with

UserSession userSession = _userSessionService.getUserSession() I get an error:

'getUserSession called on an inactive session.'

I'm calling the method:

public String getServiceContent() {

      ServerInfo serverInfoObject = getServerInfoObject();

      String serviceUrl = serverInfoObject.serviceUrl;

      return serviceUrl;

   }

I'm testing this by triggering the call as a result of a button click inside of a view in the Datacenter Monitor View tab.

[laurentsd]

Can you reproduce the problem by injecting UserSessionService in the globalview or vmaction SDK sample?

Just to make sure there is nothing else wrong with your plugin.

[bobf201110141]

So, I have a similar problem to the original poster: I have a global view, which presents a set of vCenters in the UI extension from which the user selects. From this I can obtain the server name property, with the intention of selecting the correct ServerInfo on the service side, but this isn't the problem! The problem is:

On the service side, I have a constructor which injects the VimObjectReferenceService and the UserSessionService.

but although UserSessionService is non-null, getUserSession always returns null, and logs "getUserSession called on an inactive session" are reported by the O.P.

I have modified my bundle context as follows:

<bean name="MgntServiceImpl" class="com.mgnt.service.MgntServiceImpl">

<constructor-arg index="0" ref="userSessionService"/>

<constructor-arg index="1" ref="vimObjectReferenceService"/>

</bean>

Adding the explicit indices at the suggestion of a colleague, but to no avail.

The logs suggest that the UserSessionService has been created prior to invoking this constructor.

I've also tried lazily calling getUserSession on each subsequent call to our service methods, but all with the same results.

I've double-checked the various manifest and XML files, to check that dependencies and service definitions match up, but all to no avail.

Any pointers as to how to go about debugging the invalid user session very welcome!

Thanks

[laurentsd · Accepted solution]

An invalid user session on the java side usually means that your plugin didn't use the standard remote-config setup in war/src/main/webapp/WEB-INF/flex/remoting-config.xml and the session information wasn't passed correctly.  Check that you have something like that:

<?xml version="1.0" encoding="UTF-8"?>

<service id="remoting-service"

   class="flex.messaging.services.RemotingService">

  <adapters>

  <adapter-definition id="java-object"

   class="com.vmware.vise.messaging.remoting.JavaAdapterEx"

   default="true"/>

  </adapters>

  <default-channels>

  <channel ref="secure-amf"/>

  <channel ref="amf"/>

  </default-channels>

</service>

[bobf201110141]

Many thanks, Laurent. So, following modification of GlobalView to determine that UserSession could be obtained in that context, systematic diff on the various config files showed that:

1) services-config.xml was missing this entry:

<services>

      <service-include file-path="remoting-config.xml" />

      <default-channels>

         <channel ref="secure-amf"/>

      </default-channels>

   </services>

2) remoting-config was missing entirely.

Not sure why our plugin was in that state, perhaps never updated from very early PoC.

However, making these changes mean that UserSession can now be successfully injected.

Thanks again