I'm very new to Apigee.
I'm adding an existing WSDL service as a API proxy.
When fetching the SOAP functions, all looks good. Every single one is imported and are setup correctly.
When i then hit the save button the proxy is created, but are never submitting the revision to the server.
When looking into the problem I see that i get a 502 error back from a file named https://enterprise.apigee.com/gw/upload/[NAME]/tradetracker-api/?validate=true
Also a TypeError: 'undefined' is not an object (evaluating 'b.then') are thrown from a file named 24efdbdd.proxy-editor.js
As i'm using Apigee's own website to add the proxy, so there's not much i can do about it.
This is happening in both Chrome 32, Safari 7 and Firefox 25 and the error has been there for at least a week.
I can't be the only one using Apigee's which keep's getting this error!?
There appears to be an issue with the WSDL file format -- not entirely sure what it is as one WSDL validator I used said it was okay, and another one choked on it saying it wasn't able to parse the file.
I've opened an issue with the Apigee product team to see if A) we can identify the issue with this WSDL and B) improve the product to throw a proper error rather than timing out.
This is fixed in the next release that is scheduled for release on 2/5/2014.
Related
I need to update a javaEE application (still in java 1.7) that provides a SOAP web service. And I'd like to disable the TIMESTAMP_CACHE that wss4j (v2.0.2) uses to control reply attacks. It creates too many files and the OS reaches the maximum open files allowed, repeatedly. The files start to appear, one for each request that has been made and are named in the following way:
wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data
The documentation states that the TIMESTAMP_CACHE can be changed (or so I understand):
ConfigurationConstants.ENABLE_TIMESTAMP_CACHE ("enableTimestampCache"): Whether to cache Timestamp Created Strings (these are only cached in conjunction with a message Signature). The default value is "true".
I've found many examples to change some of these ConfigurationConstants when a client application creates the Call object. See an example to change the PASSWORD_TYPE constant:
Service service = new Service();
Call call = (Call) service.createCall();
...
call.setProperty(UsernameToken.PASSWORD_TYPE, WSConstants.PASSWORD_TEXT);
call.setProperty(WSHandlerConstants.USER,"werner");
However, my application is not on the client side but on the server side and I haven't found so far the way to change the ENABLE_TIMESTAMP_CACHE constant.
Any idea?
I couldn't find a way to disable the timestamp cache. However, the wss4j behaviour described above happened to be a bug that not only resulted in lots of open files but in lots of open threads. It has already been fixed in version 2.0.9. Upgrading to the "newer" version did the trick.
You can find here the discussion in full that drove to the bug discovery and here the fix in wss4j's jira
I have a c# console application which post .csv content to a web service. If I run my solution through VS, it runs perfectly fine but after deploying web service on IIS I keep getting Multiple Choice Status Code 300 error. Not sure how to resolve that. Any pointers would be appreciated.
Thanks
These are relatively simple but I cannot think of other possibilities based on your description.
One of my recent designs had a literal in the code that when I deployed it ended up using a different port which I had forgotten to change to a relative reference.
If not that then the other problem I had with it was because I used JSON to link to the web service. While it worked when viewing in VS when deployed my JSON reference was actually incorrect. specifically it had to do with code in my web.config file, which would be the app.config file for your console application. I had used the code
standardEndpoint helpEnabled="true" automaticFormatSelectionEnabled="false" crossDomainScriptAccessEnabled="true"
when I should have also added
defaultOutgoingResponseFormat="Json"
to make the code work
When trying to update a service reference in a class library (VS2013), i get the following error.
"The configuration for the service reference could not be updated due to the following issue: An error occurred creating the configuration section handler for system.serviceModel/bindings: AssemblyResolveEvent handlers cannot return Assemblies loaded for reflection only."
This same error happens when i try to delete the reference as well.
Any help in sorting would be greatly appreciated.
I've had the same issue after updating to VS2013 Update 2.
I've solved the issue by temporarily cutting the whole system.serviceModel section out of web.config, pasting it somewhere else like Notepad. Then, I've saved the web.config without the service model section. Then, I was able to update the service reference successfully. After updating the service reference, I've pasted the service model section back to web.config and it worked successfully.
I was able to work around this similarly to Can by temporarily removing the extensions element of the system.serviceModel section and any associated extension elements. In my case the extensions were Azure Service Bus extensions.
In my experience it has been as simple as to delete the service reference and re-adding it. For example, last time it happened it was on a WebService (not WCF, the old one), and the error started appearing after we changed one of the classes that was being sent as a return from different routines/functions. After adding one more property to the class, it started going crazy and prompting errors everywhere.
Just a simple Delete and re-Add Service Reference did the trick.
Only need to one time remove <system.serviceModel> section from web.config. After Create first service refrence , this section rebuild by Vs.
Symptoms:
PumaLocator is unusable, every findXXX-method returns empty results or throws an exception because nothing was found.
Analysis:
The problem seems that, due to the ICEfaces specific architecture, the method GenericPortlet.doView is invoked only for the first time the Portlet is loaded, and not for the following (AJAX) page updates, e.g. in case of a called ActionListener.
If I use PumaLocator inside the doView-method, everything works fine.
I tried the following attempts yet:
Get the PumaLocator in doView, put it into Session and use it later - didn't work
Get the RenderRequest in doView, put it into Session and use it later to get a PumaLocator by passing that request - didn't work
I would be very glad to have any hints. Thank you!
PUMA checks the authorization for results by using information found in the Context. You must add JavaEE security roles in the deployment descriptor for the AJAX backend servlets the ICEFaces uses. As a thumb of rule if request.getRemoteUser() and request.getUserPrincipal() return something besides null you know PUMA will work. Otherwise it will NOT work and that is intended behaviour.
Alternatively you can attempt to disable the security checks of PUMA like this.
I need to use ZendAMF on a symfony project and I'm currently working on integrating the two.
I have a frontend app with two modules, one of which is 'gateway' - the AMF gateway. In my frontend app config, I have the following in the configure function:
// load symfony autoloading first
parent::initialize();
// Integrate Zend Framework
require_once('[MY PATH TO ZEND]\Loader.php');
spl_autoload_register(array('Zend_Loader', 'autoload'));
The executeIndex function my the gateway actions.class.php looks like this
// No Layout
$this->setLayout(false);
// Set MIME Type
$this->getResponse()->setContentType('application/x-amf; charset='.sfConfig::get('sf_charset'));
// Disable cause this is a non-html page
sfConfig::set('sf_web_debug', false);
// Create AMF Server
$server = new Zend_Amf_Server();
$server->setClass('MYCLASS');
echo $server->handle();
return sfView::NONE;
Now when I try to visit the url for the gateway module, or even the other module which was working perfectly fine until this attempt, I only see a blank screen, with not even the symfony dev bar loaded. Oddly enough, my symfony logs are not being updated as well, which suggests that Synfony is not even being 'reached'.
So presumably the error has something to do with Zend, but I have no idea how to figure out what the error could be. One thing I do know for sure is that this is not a file path error, because if I change the path in the following line (a part of frontendConfiguration as shown above), I get a Zend_Amf_Server not found error. So the path must be correct. Also if I comment out this very same line, the second module resumes to normality, and my gateway broadcasts a blank x-amf stream.
spl_autoload_register(array('Zend_Loader', 'autoload'));
Does anyone have any tips on how I could attach this problem?
Thanks
P.S. I'm currently running an older version of Zend, which is why I am using Zend_Loader instead of Zend_autoLoader (I think). But I've tried switching to the new lib, but the error still remains. So it's not a version problem as well.
got it...
I was not using
set_include_path()
while loading Zend. It's still odd that it would give such a cryptic error, but this was the missing piece indeed.