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
Related
We have been using the following library for months:
https://unpkg.com/react#15.3.0/dist/react.min.js
Yes - I know we can just reference 15.3 and get the URL rewrite to the latest, but they released a breaking change. That's another issue for another day. Don't get distracted.
Yesterday this simply stopped working. You'll notice that if you load the URL mentioned, that the file is TRUNCATED. Simply cuts off. This made everything we use react with break. Interestingly, if you go to the following URL (without the .js extension) - things work.
https://unpkg.com/react#15.3.0/dist/react.min
My question is - what the heck happened? Why did the URL we've been using for 8 months suddenly stop working, and who can we get to fix it. In the interim, we had a copy locally that we've started referencing (which we probably should have been doing to begin with, since we don't want the automatic upgrade). When things like this happen, who do you inform?
I'm not sure you'll find the answer as to why this file is no longer working here but based off of the website you could reached out to the creator on twitter: https://twitter.com/mjackson
On the website it says:
SUPPORT
unpkg is a free, best-effort service and cannot provide any uptime or
support guarantees.
i.e. you should probably only use this link if you are messing around with a small project and shouldn't be used for any website where you actually care about the uptime of the site.
Following the steps mentioned at mybatis-ignite integration page # mybatis-ignite with Ignite 2.0, i see that the call to the mapper hangs & never returns. This is after working around several other issues like requiring ignite-cache configuration to be placed in IGNITE_HOME/config/default-config.xml which still doesn't get picked up unless i place it in a physical location in the project dir (otherwise i see the error in the log "Initializing the default cache. Consider properly configuring 'config/default-config.xml' instead.") which again also seems to have no effect.
Since the integration seems to have several issues i am not sure if it is still supported..any thoughts from any one who has successfully done this or from the mybatis-ignite team would be great.
Edit: If it helps, i have placed a small self contained project # https://github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC that can be used to reproduce the issues i have mentioned.
I missed mentioning in the repo..but only the Ports table & schema is used for the purposes of the demo the other tables are not used. What happens is that in the file (github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC/blob/master/domain/src/main/java/com/brocade/dcm/domain/xml/PostsMapper.xml) if i remove the line "cache type="org.mybatis.caches.ignite.IgniteCacheAdapter" />" then everything will work fine without ignite caching. But the moment i add that line as shown in the uploaded file the mapper method calls just hangs.
I have an Eclipse RAP 2.3 application with two entry points, say /first and /second.
In the GUI of the first entry point, there is a button with which I would like to open the second entry point in a new browser tab. The event handler of that button is currently
UrlLauncher launcher = RWT.getClient().getService( UrlLauncher.class );
launcher.openURL( "/second");
This already doesn't work when the application is deployed as myapp.war in a Tomcat web server (should then be /myapp/second).
My questions:
What's the best way to determine the URL to open within the event handler?
Do I have to fetch the HttpServletRequest, get the context path and so some string manipulation?
Is it actually safe to call RWT.getRequest() at this point?
Update
According to Rüdiger's comment I can acquire the context path in two different ways.
The first approach is
RWT.getRequest().getContextPath();
where RWT.getRequest() is documented with
This method is not recommended
Secondly, I could obtain it with
ApplicationContextImpl ac = (ApplicationContextImpl) RWT.getApplicationContext();
String contextPath = ac.getServletContext().getContextPath();
where the IDE displays the warning
Discouraged access: The type ApplicationContextImpl is not accessible due to restriction on required library ...\org.eclipse.rap.rwt_2.3.2.20150128-1013.jar
Despite the warning, it still works when deploying a WAR file with OSGi bundles to Tomcat.
So, in both cases there is some kind of warning, which makes the solutions look rather like workarounds.
Using RWT.getRequest() is not recommended because usually RWT would shield you from the lower-level servlet API and certain direct interactions with the request could even interfere with RWTs life cycle and yield funny responses.
While in your case it would be safe to access the ServletContext via RWT.getRequest(), I recommend to use
RWT.getUISession( display ).getHttpSession().getServletContext();
to access the servlet context.
The second approach accesses internal classes that aren't part of the public API and therefore shouldn't be use. The accessed classes may change or be (re)moved in the future without further notice and break your application.
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.
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.