change applicationcontext from in code - apache-flex

I have a little problem. I hope someone can help me.
I'm developping an application for my thesis.
Now I have an application-context.properties.txt where I define:
host= (ip address)
port=8080
Now this is static and I change the ip address to the server I want to connect to.
But this isn't verry usefull for the user because he can't access that file.
Now is my question can I change this host ip address from in my flex code? And how do I do that.
Hope someone can help me.
Kind regards,
Thibault Heylen

Usually Configurations i.e services.xml embeds at compile time, this blog
Externalizing Service Configuration using BlazeDS and LCDS
pointed towards way to Externalizing Service Configuration,
hopes that works,

Looking at the documentation, the FlexXMLApplicationContext is just one example of an application context. Possibly, you can derive from it or the XMLApplicationContext to allow for runtime changes to configuration variables, if the context class doesn't support it already?
You won't be able to change the value in the XML file itself, since it is a compiled resource, but you should be able to extend SpringAS to do what you want at runtime.

Related

How to deploy SWF file to Websphere application server?

I want to deploy my application coded in FLEX to my WAS 7.0.0.4 on localhost. The application is exported as a SWF file. But I don't have got any experience with WAS and I didn't find any tutorial how to do that and that whole system looks really confuzing to me. Could somebody write step-by-step solution or give me any advice how to reach my object?
If I understand you correctly, you'd probably be better off just using an HTTP server like Apache or IBM HTTP Server (which is much the same thing). It sounds like you're deploying static content (from the server's perspective), so an application server will only add complexity and use more resources without providing you with any additional functionality. On an HTTP server, all you need to do is place the files you want to deliver to the browser in a specific directory.

Why do I need to set up the aspNetCompatibilityEnabled twice?

Could anyone please explain why when creating a WCF webservice in which you want to use HttpContext.Current.Items you need to add some code in 2 places?
One in the webservice itself ([AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]) and one in the web.config file (<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />)?
A colleague of mine just had all his webservice calls failing. He had the web.config setup missing and asked me why. I tried to explain, but I'm not sure if I was able to :)
I think it has to do with the separation of the webservice code and the place where the webservice gets hosted. The webservice itself says that it needs that compatibility mode. It is then also needed to setup the hosting environment to say that it should run in that compatibility mode.
Isn't this basically the point?
He still had a question: "but, if the service uses that attribute, should it not be automaticly ?"
The first tells WCF that aspcompat must be enabled and the second enables it. You should be able to do without the first.
This forces the person configuring the WCF service to use the right config.
MS designed this with the idea that the person configuring the service might be someone else that the person that made it.
To answer his last question. When you add attributes to your service you're not configuring the host, you're demanding how the host should be configured. The configuring happens on the host.

Web application configuration settings - Which is the better place to store

I came across a case study few days early. It is related to a web application architecture.
Here is the scenario,
There is a single web service used by say 1000 web applications. This web service is hosted on a particular server. If web service hosting location is changed, how the other applications come to know about this change ?
Keeping it in web.config doesn't seems to be a feasible solution as we need to modify web.config files for all the applications.
Keeping these settings in a common repository and let all the applications use it for web-service address was came in my mind, but again there is a question of storing this common repository.
I am just curious to know about how this could be achieved with better performance.
Thanks in advance for any kind of suggestions.
do you have full access or control over all those web applications consuming that web service? if so, you could have a script or some custom code which updates all their web.config(s) at once. it seems too much work but in fact in this way you have more control and you could also, eventually, point to the new url only some applications and leave some others on another url.
the idea with the setting in a centralized database gives you faster update propagation which could also be bad in case of errors and then you have all applications referring to the same place and no way to split this. Then you have anyway to connect to a centralized database from all of them and maybe you should add a key to their web.config(s) with the connection string to that database, then, in case that database is not reachable or is down, the web applications will not be able to consume the web service simply because they cannot get the url of it.
I would go for the web config, eventually you could have a settings helper class that abstract the retrieval of that url so the UI or front end does not know from where that url comes from.
anyway, do you plan to change the url of a web service often? wouldn't be better to copy it to a new url but to also keep it available on the current url for a while?
another advantage of web.config approach is that everytime you update and save it the application is restarted while a change in a database might take a while to be detected in case you have some caching mechanism,
hope this helps.
Davide.

wrong protocol for crossdomain.xml in flex app

I've changed the protocol for my flex app from https to http and flashplayer still wants to download the crossdomain.xml using https though with the port for http.
the app is accessed at http://domain01:8080/flex and it wants to get https:..samedomain..:8080/crossdomain.xml (at https:..samedomain..no_port/flex it works fine).
Anyone any idea why?
Thanks a lot,
Daniel
No direct answer as I haven't tried this scenario of specifying a non-default port but a couple of piece of info that might lead you to an answer:
http://learn.adobe.com/wiki/download/attachments/64389123/CrossDomain_PolicyFile_Specification.pdf?version=1
This might be of interest:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" to-ports="507,516-523"/>
</cross-domain-policy>
or this:
10,0,12,0 site-control's permitted-cross-domain-policies default for non-socket policy files is "master-only"
Maybe try an older version of Flash Player to see if something in the changes from 9->10 is causing the issue then finding the change in the change logs might be easier or perhaps it's a bug in the new version.
Good luck
Shaun
Flex (Atleast 3.5 AFAIK..) gets some identify crisis when you change port and use Https... The security model depends on the port.. I do not know the exact reason for the problem, but my solution was to load the crossdomain file in your app explicitly..
System.security.loadPolicyFile('https://mydomain:port/crossdomain.xml');
When you run into crossdomain issues, it's worth remembering that by using the Security class, you can always take explicit control over what crossdomain.xml file is loaded (in fact, the policy file can have any name you want). The default behavior of loading the policy file from the root of a server can often be too restrictive when dealing with more complex, real-world cases (with load-balancing or reverse proxies, for instance).
Try using:
Security.loadPolicyFile(<URI to the policy file goes here>);
The ASDocs are here and explain it quite well.
By taking control of how policies are loaded, you can gain more freedom and take a lot of the guesswork out of what can otherwise be a painful, frustrating experience. The Flash Player allows you to load multiple policy files which is handy if you need to integrate with more than one service layer (e.g. on one host through HTTPS and another through HTTP).
Good luck,
Taylor

Does an ASP.NET Web Service Namespace subdomain matter?

meaning is there a difference between
<WebService(Namespace:="http://theurl.com/")>
and
<WebService(Namespace:="http://www.theurl.com/")>
?
Don't know if you're asking one of two things so I'll mention both.
1. What's the namespace for?
The reasons all derive from the W3C standards.
Very short answer: If you're doing some simple ASP.NET web services, all connecting through .NET you'll probably never know any difference. In fact, a lot of web services I've seen I see are still using tempuri.org ;-) Shame. If you're doing interop or are publishing a number of web services, a proper namespace guarantees uniqueness for similarly named services.
2. Does the subdomain matter?
Yes, different subdomain, therefore, while semantically equivalent, they're different namespaces. A namespace can look like a Url, but it's not. You could just as easily use something like "urn:org.tempuri" as a valid namespace.
This indicates the XML Namespace of the web service, and has nothing to with an actual address.
So yes, the namespaces mentioned are different. Just as the System.Data and the System namespaces in C# are different namespaces.
Does it matter which one you choose when creating the service? No, just pick one...
Does it matter which one you choose when consuming the service? Yes, use the one that the creator picked. (Which is described in the WSDL)
Short answer: No.
Long answer: Maybe.
If you are going to use the SOAP protocol yourself. The name space of the XML return might be required to be "www.*" in the code (a security "feature").
If you can type both into a browser and they work, then there's no difference. A lot of it depends on how the site is set up at the host. The option for the non "www" URL is simply a DNS entry.

Resources