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.
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 django instance set up on pythonanywhere.
I have debug turned off in my settings
I have a STATIC_ROOT setting of os.path.join(BASE_DIR, "allstatic").
I have set up the static files mapping in the Web section of my pythonanywhere console
URL = /allstatic/
Directory = /home/username/project/allstatic
(I'm calling it allstatic so I can tell that the files are coming from the mapping)
I have run collectstatic and /allstatic has files in it.
I am using {% static 'folder/file' %} in my templates
And with all this - the static files were all being delivered. However, when I checked the page source HTML, they all appeared to be coming from '/static' So I wasn't sure if they were being delivered by the more efficient console driven mapping.
When I changed 'STATIC_URL' setting to 'allstatic' the html shows '/allstatic' and the files still load. BUt I'm not sure how to tell if my mapping is working.
To use a concrete example
I have an app called 'universal' in django, with the following structure
universal
static
universal
img
logo.png
In my local dev environment, with debugging on, this shows up as /static/universal/img/logo.png
However, in my prod environment with debugging off and all the above steps taken, this also shows up as /static/universal/img/logo.png - until I set the STATIC_URL to allstatic
How can I be sure I am using the allstatic mapping I set in the pythonanywhere console? And does STATIC_URL affect whether I am using it or not?
I figured it out.
In order to test that the web console static mapping is working on pythonanywhere, I made the following setting explicit and then commented out AppDirectoriesFinder
STATICFILES_FINDERS = [
'django.contrib.staticfiles.finders.FileSystemFinder',
#'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]
This ensures that app directories aren't being looked at to find static files - it will require the Web Console page mapping (or an entry in STATICFILES_DIRS which is empty by default) to be set up correctly to find files.
Doing this I was able to find that my previous STATIC_URL setting of 'static/' rather than 'allstatic/' had in fact been failing to use the mapping - something previously obscured by the fact that both /static/universal/img/logo.png and /allstatic/universal/img/logo.png seemed to work.
(It's interesting that the app level /static locations still work on pythonanywhere with debug turned off - I suspect this fact was muddling me a bit).
I cannot get this to work as stated in the UI5 documentation topic Troubleshooting for browser developer tools.
I already typed the code but I see no response.
myView=sap.ui.getCore().byId("HeapOfShards---app").
myView.byId("myButton").
Issue 1
When pasting code snippet from the documentation, you need to omit the full stop (.).
Otherwise, the console will think that the expression is not complete, hence, no response.
But just omitting the full stop will lead to an error that myView is undefined. See Issue 2.
Issue 2
Since UI5 1.61.0, the component in the sample code (id="HeapOfShards") gets an additional auto-prefixed ID from the parent ComponentContainer (id="container"). Therefore, when accessing the root view via the global ID like in the topic, the ID of the ComponentContainer needs to be prepended:
myView = sap.ui.getCore().byId("container-HeapOfShards---app");
myView.byId("myButton");
This is clearly a documentation issue that needs to be fixed. Update: It's fixed now.
Why it didn't work
In 1.61, the sample code for Troubleshooting moved from creating the ComponentContainer via inline-script to creating it declaratively via the module sap/ui/core/ComponentSupport.commit
The reason why .byId("HeapOfShards---app") suddenly failed is that ComponentSupport sets several settings beforehand when creating the ComponentContainer, among which the autoPrefixId gets true by default. src
When creating the ComponentContainer directly without the ComponentSupport, autoPrefixId is false by default which is why it was all fine in previous versions.
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.
It seems google cloud storage provides a different behavior whether a folder is access from a web client with or without a trailing /
A simple test shows a different behavior for the following link
http://gstest.tekartik.com/sub/dir (fail to load css - background is white)
http://gstest.tekartik.com/sub/dir/ (works ok - background is black)
Where the bucket has been configured using:
gsutil setwebcfg -m index.html -e 404.html gs://gstest.tekartik.com
For information it contains 3 simple files index.html/404.html/style.css where style.css only set the background to black.
They both correctly "redirect" to the url http://gstest.tekartik.com/sub/dir/index.html. However the relative path does not allow for style.css to be loaded properly in the first case.
What I would like is to have the 1st case to be redirected using a trailing / (which is what Amazon S3 does). What is needed for this to work propertly so that I can give a url to someone without worrying about whether the trailing / is entered?
as a side, this works fine as at the root level (http://gstest.tekartik.com/ got automatically renamed to http://gstest.tekartik.com as here the trailing / is not needed)
I've spoken with the engineering team and we agree this should work the way you expected. This will be fixed in the near term by adding a bucket configuration setting to enable the expected behavior (the extra config step is needed to avoid breaking any apps depending on the current behavior). We're also planning to make it easy to update the new config setting via gsutil. I can't say when exactly these changes will be available but tune into the gs-announce group to monitor these (and other) details about Google Cloud Storage. Thanks for bringing this to our attention.
Update (June 3, 2013): This has now been fixed in production.