Not sure what I did and I can't seem to see my RPC Services anymore. They are there and I can see them and get responses to their paths, but I can't see them through the Apigility/Admin screen.
The error is telling that either the config files are missing or may be even the code itself. When the code is missing normally you see "Unable to fetch code" or similar, so most probably you are missing config files.
It could also be a simple markup problem due to a strange char.
Since the Apigility GUI uses the Apigility API, you can use Firebug to check what is wrong.
Open Firefox and check the tab "Network". Now try to create a service and check the requests, you will probably find a dump with the Exception / Error that you are looking for.
Related
I'd like to output some data to the console or any other visible place to help with debugging. Apparently Logger.log() doesn't do that, or if it does, I have no idea where to see the results (at least in the preview mode).
Is there any functionality for debug output in the server scripts?
I strongly encourage you to check the official documentation to get to know the basics. Using console.log("test") will log anything to the server side logs, which you can access from the preview mode.
Sorry about the mishmash of words in the title, but that's how confused I am. I can't even summarize the error I'm getting in a simple sentence.
This flex/amfphp application works fine on my computer, even though it accesses an Oracle database on another server. However, when I try to access it from another computer, this is the error I get. I'll try and put the most relevant code in. (My browser tell me this is an ActionScript error).
Fault faultString="Send failed"
faultCode="Client.Error.MessageSend"
faultDetail="Channel.Security.Error error Error #2048: Security Area Violation..
Couldn't load data from http://localhost/.../amfphp/gateway.php
As I said before, it works on my machine for some reason. Now, when I try to access this remotely from other machines, it seems that the PHP engine is looking for gateway.php on the localhost of that machine?? Does this mean that PHP is looking for gateway.php on the client's localhost rather than on the server??
Correct me if I'm wrong, and thanks in advance
Your services-config.xml in Flex propably points to http://localhost/.../amfphp/gateway.php
You'll need to change the endpoint in that XML file and recompile the application.
You could also create your ChannelSet at runtime. In that case you don't need the services-config.xml anymore. Take a look at http://raghuonflex.wordpress.com/2008/06/05/endpointatruntime/ for some inspiration...
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I followed the instructions listed here. It worked the first time, but every since then, when I run my app, I don't get a "Profiled app started" message. Then when I click on the "Take snapshot" button, I get the following:
"Taking snapshot ...failed: The remote server returned an error: (404) Not Found."
Why can't it find my app?
If a profiled app encounters errors it will log these to the profiler.log file. By default you will find this in C:\Windows\Temp\EQATECProfilerLogs. Try to see if it holds some clues. You can also try to enable "Full logging" in the app options, which will at least output something to the log.
A profiled app is actually the "server" when talking to the profiler; it is the profiler that connects to the app, not the other way around. In your case it seems that the old app has stopped listening (otherwise the profiler's attempt to connect would simply be served by the old app), but the new app has not (could not?) started listening.
It seems strange, though, so my best suggestion is to examine the log-file. It will e.g. show if the app could not start its control-server and if so, why not.
1) Try rebuilding (in Equatec) your application. Make sure "enable runtime control" is enabled in the application options when you build.
1a) Try changing the port being used for runtime control.
2) Run your application through Equatec
3) Check if you have anything funny for firewall settings or similar. Some firewalls treat Equatec communication as traffic to be blocked.
4. If all else fails, just close your application normally. Even if taking snapshots fails, you can still see the profile once your application is closed.
Guess I should provide an update on this. The error was resolved once I downloaded the latest version.
I'm trying to debug some server-side JavaScript code running in Aptana Jaxer and I'm not having any success. I haven't even been able to find any tutorials or posts about this issue. Does anyone know if it's possible and if so, what am I missing?
You can set you Jaxer.Config.DEV_MODE = true; to get some error information in your browser.
Also use the Jaxer.Log to debug.
Hope this helps a bit.
Jaxer and Aptana Studio do not yet have the ability to debug remote scripts from the client side. That is, you can't single-step into a callback and have your code window show you the first line of code in the remote method. This is on their wishlist, of course, but it'd be pretty tricky to do well.
Personally, I use logging. Jaxer has strong facilities for this, in Jaxer.Log.*.
A lot of people sneer at "printf() debugging", but the fact is, it works, and it's often less trouble to set up than an interactive debugger, especially for server applications and remote method invocation. You just sprinkle logging messages wherever you want to know the state of the system at that point, then make your app try to do the thing that's failing. Study the logs, rinse, repeat.
tail -f /opt/AptanaJaxer/logs/jaxer.log
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.