This content has been marked as final. Show 9 replies
You will need flex data service (lifecycle data service). You have to deploy web.war in your servlet container.
This isn't the way to do things in FDS. We no longer connect to servlets
directly. Out of the box we want you to write a plain old java object
and compile it into /WEB-INF/classes (or jar it up and put it in
/WEB-INF/lib). You then create a remoting-service destination for your
class and then specify this destination in your <mx:RemoteObject> tag in
your client code. (Remember to restart the web application after making
any configuration changes).
From your POJO you can get to the session through the static
thread-local flex.messaging.FlexContext.getFlexSession(). This returns
an implementation of flex.messaging.FlexSession. If your request was
made over HTTP then the implementation will wrap the J2EE HttpSession
and delegate any calls to it (such as getting and setting attributes).
Alternatively, if you know your POJO is always going to be contacted
over HTTP you can ask the the HttpServletRequest through
flex.messaging.FlexContext.getHttpRequest() and then get the HttpSession
from that (via the usual getSession() method).
Remember that if you use flex.messaging.FlexContext etc... in your own
java object you'll need to add /WEB-INF/lib/flex-messaging.jar and
/WEB-INF/lib/flex-messaging-common.jar to your classpath.
Is there any way to make a new FlexSession if one doesn't exist (in java)?
I am having a problem integrating a flex app into an existing web app that has session variables set, but when I make a RemoteObject call it creates a __flexSession and deletes all my other session info. After making the RO call once, and the __flexSession is created, everything works fine . . . I have a work-around right now that involves making a RO call before entering the app, but I would like to start the session in java if possible. This seems to only happen on my Tomcat 6 (jdk 1.6) server. When I use JRun4 sp6 it seems to handle the addition of the __flexSession attribute into the session.
Which version of FDS or LCDS are you using?
If you're using J2EE sessions, then the Flash Player would have to send the
cookie via HTTP that contained the jsessionid along with your RemoteObject
request in order for you to be in the same session. Can you use an HTTP sniffer
to see whether this cookie is being sent?
> Is there any way to make a new FlexSession if one doesn't exist (in
> I am having a problem integrating a flex app into an existing web app
> that has session variables set, but when I make a RemoteObject call it
> creates a __flexSession and deletes all my other session info. After
> making the RO call once, and the __flexSession is created, everything
> works fine . . . I have a work-around right now that involves making a
> RO call before entering the app, but I would like to start the session
> in java if possible.
When I switch the protocol to http, so I can see it in the sniffer, everything works fine (tomcat and jrun).
So . . . maybe it has something to do with https ? ? ? (still not sure why it works in jrun but not in tomcat)
I tried adding the JSESSIONID to the response header of the jsp that has the swf, and as a parameter of the swf . . . neither worked.
It may be something more complicated than this, but let's cover the basics
for HTTPS first before we start tracking down session cookies...
1. If you need to make a secure connection from the Flash Player, then the
SWF should be loaded via HTTPS. If you're using an HTML wrapper be sure that
the movie url for the SWF is HTTPS - if it's a relative URL this would mean
that the HTML wrapper itself would have to be loaded via HTTPS.
2. MSIE has problems with certain HTTP response headers when using SSL -
various combinations of Pragma: no-cache, Cache-Control: no-cache, or Expires
response headers can cause problems depending on the version of HTTP, whether
chunked or gzip encoding is being used, and the version of MSIE (with the
most problems seem to occur with MSIE 6).
3. If you're using a crossdomain.xml policy file, watch out for a Firefox
only bug where by if the Flash Player requests a crossdomain.xml from a URL
that specifies a port and is challenged by Basic Auth the subsequent request
will not work.
In general, when debugging HTTP/HTTPS issues it pays to use a sniffer to
watch the traffic between the client and the server. Since you're having
issues with HTTPS, you'll probably need to use a client-side proxy to do
the sniffing for you. Paros Proxy is a good example of a simple sniffer that
you can easily configure MSIE to use as a proxy and thus watch the HTTP headers
and bodies for the request and response before they are sent encrypted via
> LCDS 25
> When I switch the protocol to http, so I can see it in the sniffer,
> everything works fine (tomcat and jrun).
> So . . . maybe it has something to do with https ? ? ? (still not
> sure why it works in jrun but not in tomcat)
> I tried adding the JSESSIONID to the response header of the jsp that
> has the swf, and as a parameter of the swf . . . neither worked.
NEVER MIND . . .
I switched my destination to the secureAMFChannel and everything is working.
SORRY FOR WASTING YOUR TIME
No worries, glad to hear that you tracked down the issue.
Since you are using secureAMFChannel, be mindful of the MSIE issues and HTTPS
as different web servers may add different headers based on their default
configurations. You may want to set the <add-no-cache-headers> property to
false for the endpoint configuration too to be sure that LCDS isn't adding
its own no-cache headers that may complicate the issue.
I am currently using the default channel-definition that came with lcds, which has the add-no-cache-headers property set to false (in services-config.xml).
Thanks for the warning, and your time.