This document was generated from CDN thread
Created by: James Heffernan on 21-08-2009 12:49:31 AM
Hi,
I'm having problems with my app. I have a bunch of configuration (I would like to have used IoC, Spring, to load that but found the ClassLoader issues too overwhelming to continue with that, but that's another story) which I only need to load up when the application is started. In fact it would help greatly as the loading of that takes a few seconds to complete and I don't want to have to do that for every call unnecessarily.
So I thought I'd give the ApplicationStartAPI a go, so I've created an instance of the StartApplicationInterface which sets a Map of objects up in the ApplicationAPI. The objects used are my own class, basically just a simple POJO with some config settings which can be used later in the application. When I call the app one of my customised elements then obtains the ApplicationAPI from the ActionElementData (aed.getApplicationAPI()) and I can then obtain the Map of objects from that.
However when I then try to access one of the values in that Map I just get ClassCastExceptions happening. If however I just "print" the object the correct toString() is being used and the representation looks correct.
Has anyone managed to use the Application(Start)API and if so what trick is there to being able to retrieve and cast objects?
Thanks
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 26-08-2009 03:44:28 AM
Hello again,
so as an update the CallStartInterface
implementation class now does a little check after loading the Map of
objects into the Application Data. What I have done is obtain that Map
back from the ApplicationData, then I iterate across it, I can then
cast each resulting value to the correct Class type and I can confirm
the getClass().getName() is the correct class type.
In my Call
Action element implementation class, where I then obtain the Map from
the application data and do likewise the Map is obtained OK, I can cast
that to a Map, I can obtain the key set, and I can even use the
getClass().getName() construct to confirm that the POJO held in the Map
is the correct class. However, when I then try to cast that to that
Class I am getting the ClassCastException. It is most odd, almost as
if there is some dissociation between the ClassLoader for the
application start and that for the call instances. It is also odd that
I can obtain a Map instance correctly and cast it (a Java core class)
but when trying to use my own classes it fails, which suggests an issue
with the classpath in some way.
Has anyone at all used the Application data mechanism with their
own class instances and successfully reused those within an actual
call? Any help gratefully accepted.
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 27-08-2009 04:46:51 AM
I'll just talk amongst myself for a while eh?
Just a bit more information on this, it is definitely related to the classpath. I used a real simple class (from the same package, one of my "own") with a couple of string members, and that did the same. So then I actually just set a String to the ApplicationData, and lo and behold that I could re-cast from my customised Action element within a call. So although I can use the class within the customised action element (in fact that element is within the same jar file) something between the load in the ApplicationData and the load of the call element means the class is not castable. It's really very odd. I've raised a TAC case with Cisco on this, so if and when I get a response on this I'll update this thread accordingly. In the meantime I'm open to reasonable suggestions....
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: Ranjana Narayan on 31-08-2009 09:44:59 AM
James,
Try placing a copy of your POJO class that you are storing in the ApplicationData in the <CVP_Home>/common/classes (or lib), and redeploy your application. This should solve your ClassCastException.
This is a workaround we suggest when pojos are stored in sessiondata or appdata, custom structures accessible globally.
Hope this helps,
Ranjana.
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 01-09-2009 10:19:10 PM
Hi,
thanks for that I will give it a whirl. These apps are running in a shared environment, so theoretically (when we sign them) multiple customer apps. Obviously with the different package names there's no crossover but it's a bit clunky, I can live with it as long as I'm the only one doing the builds. I quite like having the compartmentisation of apps the application../ paths bring, particularly as there are dependencies in my custom classes to other libs, notably jdom. So things can get a bit ugly very quickly if I then have to start putting those jars under the common/lib path for example. I'll see how much effort is involved anyway.
I've now got a more pressing requirement for assistance, which I'll be posting in a minute, around some "even more fundamental" functionality which is not working as I'd expect.
Thanks again
James
Created by: James Heffernan on 21-08-2009 12:49:31 AM
Hi,
I'm having problems with my app. I have a bunch of configuration (I would like to have used IoC, Spring, to load that but found the ClassLoader issues too overwhelming to continue with that, but that's another story) which I only need to load up when the application is started. In fact it would help greatly as the loading of that takes a few seconds to complete and I don't want to have to do that for every call unnecessarily.
So I thought I'd give the ApplicationStartAPI a go, so I've created an instance of the StartApplicationInterface which sets a Map of objects up in the ApplicationAPI. The objects used are my own class, basically just a simple POJO with some config settings which can be used later in the application. When I call the app one of my customised elements then obtains the ApplicationAPI from the ActionElementData (aed.getApplicationAPI()) and I can then obtain the Map of objects from that.
However when I then try to access one of the values in that Map I just get ClassCastExceptions happening. If however I just "print" the object the correct toString() is being used and the representation looks correct.
Has anyone managed to use the Application(Start)API and if so what trick is there to being able to retrieve and cast objects?
Thanks
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 26-08-2009 03:44:28 AM
Hello again,
so as an update the CallStartInterface
implementation class now does a little check after loading the Map of
objects into the Application Data. What I have done is obtain that Map
back from the ApplicationData, then I iterate across it, I can then
cast each resulting value to the correct Class type and I can confirm
the getClass().getName() is the correct class type.
In my Call
Action element implementation class, where I then obtain the Map from
the application data and do likewise the Map is obtained OK, I can cast
that to a Map, I can obtain the key set, and I can even use the
getClass().getName() construct to confirm that the POJO held in the Map
is the correct class. However, when I then try to cast that to that
Class I am getting the ClassCastException. It is most odd, almost as
if there is some dissociation between the ClassLoader for the
application start and that for the call instances. It is also odd that
I can obtain a Map instance correctly and cast it (a Java core class)
but when trying to use my own classes it fails, which suggests an issue
with the classpath in some way.
Has anyone at all used the Application data mechanism with their
own class instances and successfully reused those within an actual
call? Any help gratefully accepted.
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 27-08-2009 04:46:51 AM
I'll just talk amongst myself for a while eh?
Just a bit more information on this, it is definitely related to the classpath. I used a real simple class (from the same package, one of my "own") with a couple of string members, and that did the same. So then I actually just set a String to the ApplicationData, and lo and behold that I could re-cast from my customised Action element within a call. So although I can use the class within the customised action element (in fact that element is within the same jar file) something between the load in the ApplicationData and the load of the call element means the class is not castable. It's really very odd. I've raised a TAC case with Cisco on this, so if and when I get a response on this I'll update this thread accordingly. In the meantime I'm open to reasonable suggestions....
James
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: Ranjana Narayan on 31-08-2009 09:44:59 AM
James,
Try placing a copy of your POJO class that you are storing in the ApplicationData in the <CVP_Home>/common/classes (or lib), and redeploy your application. This should solve your ClassCastException.
This is a workaround we suggest when pojos are stored in sessiondata or appdata, custom structures accessible globally.
Hope this helps,
Ranjana.
Subject: RE: CVP 7 ApplicationAPI Usage
Replied by: James Heffernan on 01-09-2009 10:19:10 PM
Hi,
thanks for that I will give it a whirl. These apps are running in a shared environment, so theoretically (when we sign them) multiple customer apps. Obviously with the different package names there's no crossover but it's a bit clunky, I can live with it as long as I'm the only one doing the builds. I quite like having the compartmentisation of apps the application../ paths bring, particularly as there are dependencies in my custom classes to other libs, notably jdom. So things can get a bit ugly very quickly if I then have to start putting those jars under the common/lib path for example. I'll see how much effort is involved anyway.
I've now got a more pressing requirement for assistance, which I'll be posting in a minute, around some "even more fundamental" functionality which is not working as I'd expect.
Thanks again
James
