For some reason, i can not invoke java method deployed under Tomcat/Weborb application. When i run weborb console and invoke the method from there, there is no problem. However when i tried to call from Silverlight 3 client, it does not response at all. There is one possibility which is incorrect service gateway. But i have checked the server path to make sure it is correct. I also tried different approaches to invoke server call such as proxy and class interface mentioned inside weborb documentation. I'm stuck with this problem for two days already and can not progress any further. Is there any common mistake when it comes to this problem? Any help would appreciate.
Cheers,
Khoa Nguyen
I found the solution. This is because the gateway mapping is incorrect. For instance, When deploy under weborb, the client use localhost:8080/weborb.wo. However when you deploy underworb, the gateway mapping is now change to something like localhost:8080/weborb/console/weborb.wo something like that. You can see how your request mapped to by run the weborb console and look at the server status as you invoke your java methods.
Hope this help.
Cheers,
Khoa Nguyen
There is a new WebORB for Java 4.1 release available that fixes this mapping issue. In addition, the new code generator creates a complete client class library with complex types, enums, bindable model and proxy class for the remote Java service. The release is available here:http://www.themidnightcoders.com/products.html
Related
Currently I'm connecting to my meteor project using http://localhost:3000 which uses my meteorApp.html file.
How could I make Meteor respond to the following url:
http://localhost:3000/otherPath ?
To be more explicit, I do have a file on the server side I just would like to be able to retrieve on the client side using http://localhost:3000/nameOfTheFile.sufix
I think you can just put nameOfTheFile.sufix under public directory.
See http://docs.meteor.com/#structuringyourapp
If you want otherPath to be within meteor app, public won't do.
There are several ways to do that, http://multi-page-config.meteor.com is one way to create what looks like a traditional multipage site within one meteor process.
I did this a while ago and have since perfected it a bit but haven't updated it.. this at least might give you some ideas... you can look at the source here: https://github.com/bolora/multi-page-config
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.
I am in the process of evaluating several service frameworks and one of them is OpenRasta.
Despite being taken a bit aback for the lack of organization (multiple source code repositories, lack of binary downloads, outdated build instructions and the end result of the build, OpenRasta.dll, has version 0.0.0.0 after building the openrasta-core repository), I managed my way to start building a site with a service that serves a bit of Xml (I did include OpenRasta.Hosting.AspNet and configured the handlers and modules as per IIS or Cassini).
But the very first time I hit the site (both IIS Express and VS Dev Server) I get a ArgumentNullException coming from the PipelineStage.cs. Apparently the pipeline.CallGraph property is null.
My configuration source is a mere:
ResourceSpace.Has
.ResourcesOfType<CatalogCollection>()
.AtUri("/catalogs")
.HandledBy<CatalogsHandler>()
.AsXmlDataContract();
As I mentioned I am using the code I cloned from the openrasta-core repository as of yesterday.
Thanks in advance
try wrapping resource registrations in
using (OpenRastaConfiguration.Manual)
{
//code
}
Also check this out;
https://github.com/openrasta/openrasta-stable/wiki/Building-Your-First-OpenRasta-Website
Hope this helps
We've recently setup out own webservice using SOAP and it all works like a charm.
Because the service is only used from within our own applications, I usually don't allow for a WSDL to be generated.
Today i started some tests with SoapUI and needed a WSDL of our own service. So I enabled the Default action of the TWSDLHTMLPublish component and tried to get the WSDL exported. All I got was an access violaton in WebServExp.GenerateXMLSchema, line 1636:
if (ParentInfo = nil) and ((GetTypeData(ATypeInfo).ParentInfo)^ <> nil) then
Debugging this, reveiled that GetTypeData(ATypeInfo).ParentInforeturned a nil, so of course using ^ on nil raises an access violation.
After removing the carret i had no problems generating the WSDL.
So did I find myself a bug here or am I missing something?
BTW: We have created our own SOAP.bpl, containing all original Delphi soap sources, to correct it for a known problem with exception derived from TRemotableException
So did I find myself a bug here or am I missing something?
Yes, that's a bug. And Subversion reveals it's been like that for many years - for as long as we've been on Subversion:(. [I am not setup to access the previous Starteam repository anymore].
I'm making to a note to remedy and check in unit tests for this. Please feel free to file a QC if time allows. And I'd like to hear more about the issue with TRemotableException-derived types.
Cheers,
Bruneau
I have a CORBA server that makes a twoway call to another server from a notification thread that is created in the servant. This works fine normally. I have just modified the server to be co-located with its client (both are DLLs in a host app), and now it deadlocks waiting for the reply. The offending call is to outside the colocated servers (to the naming service in fact). I am using TAO 1.6 with default policies.
The problem appears to be related to the leader-follower implementation; it is blocking waiting for the existing leader, whereas when it works there is no leader.
Thanks
Pete.
For the record, I got round it by using thread-per-connection configuration, following the advice here http://www.theaceorb.com/faq/index.html#configure_tpc and putting the optoins in a service configuration file as described here http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/Options.html#SVC (what that doesn't make entirely clear is that all you need is a file called svc.conf in the working directory). Not surprisingly, all those options are necessary to fix the problem I had.