This might be a silly question but I'd like to know what exactly is the difference between structClear(session) and the sessionInvalidate() function added in ColdFusion 10?
According to Mister Dai, who has backported the SessionInvalidate function to previous versions, it performs more than just calling StructClear, and also calls onSessionEnd before this, and coldfusion.runtime.sessionTracker.cleanup afterwards.
Further details at: http://misterdai.wordpress.com/2012/03/12/coldfusion-10-backport-sessioninvalidate/
Something that neither of these methods do, which is worth being aware of, is that they do not invalidate the session if CF is set to "Use J2EE session variables" (since this is controlled by the underlying servlet engine, not by CF)
Related
This might sound strange, but I would like to alter my local Node.js version and modify the Promise implementation to add a new source instance property.
global.Promise = class SourcePromise extends Promise {
constructor(params) {
super(params)
this.source = new Error('This is where this promise was created').stack
}
}
This would be to help me debug an error occurring on my Nuxt app, but only on the server. I'm able to catch the error by listening to the unhandledRejection event, but the error returned is not an Error object, it is simply undefined so I have no clue where it's coming from. The callback of unhandledRejection also returns the promise so I tried to add the code snippet above at the very beginning of nuxt start script to be able to log the source like:
process.on('unhandledRejection', (error, promise) => {
console.log('Unhandled Rejection:', error?.stack)
console.log('Promise source:', promise.source)
})
but promise.source is also undefined. If I log console.log(Promise.resolve().source) from any script, it works and I get the source so the only explanation I have in mind would be that the promise is created in a child process where my Promise extension is not defined.
To sum up, since it's happening in a separate process and I can't identify which one, the only way I see of implementing my SourcePromise globally in all Node processes would be to change the Promise definition directly in my local version of Node. Is it even possible?
I'm on macOS Monterey 12.3.1 using nvm v0.38.0
EDIT
I ended up cloning Node.js from Github to be able to build it locally and use it to start my Nuxt server. The problem is: it's written in C++ which I don't understand. I think I found where the promise constructor is defined which calls NewJsPromise that seems to be defined here, but I'll need help from a C++ developer since I still don't know how or where to add the stack...
(V8 developer here.) Bad news up front: I don't know exactly how to do what you're asking, and I don't have the time to figure it out for you.
But since you're not getting other answers so far, I'll try to say a few things that might help you make progress:
I don't think this is a "separate process" issue. JS objects, including Promises, can't travel between processes. If you see it in one process, then it was created in that same process.
There's more than one piece of code in V8 that creates Promises, so to be sure that you'll catch the promise in question, you'll have to update all of them:
NewJSPromise in src/builtins/promise-misc.tq, which you've found, is the Torque (not C++!) implementation, used for both the JavaScript Promise constructor and several other builtins. Note that if you put your modifications only into the PromiseConstructor, that would skip the other uses of the helper, so be sure to update NewJSPromise.
There's the C++ version in Factory::NewJSPromise in src/heap/factory.cc (which is used, probably among other things, for V8's API, i.e. any case where Node itself or a custom Node add-on creates Promises).
There's inlining support in the optimizing compiler in PromiseBuiltinReducerAssembler::ReducePromiseConstructor in src/compiler/js-call-reducer.cc (which could potentially be dealt with by disabling compiler support for inlining Promise creation).
The general outline of what you'd do is:
Update the Promise object definition to include another field.
Look at how Error objects are created to see how to get the stack. Error objects employ some fancy "lazy creation" scheme for stack traces for performance reasons; it may be easier to follow that example (to minimize divergence), or it may be easier to simplify it (because you don't care about performance). Note that AFAICT Error objects are always created in C++; you'd have to figure out how to get stacks to Torque-created Promises (off the top of my head I don't have a good suggestion for that).
Update all places where Promises are created (see above) to initialize the new field accordingly.
I strongly suspect that there are less time consuming ways to debug your original problem. (I dunno, maybe just audit all places where you're dealing with promises, and check that they all have rejection handlers? That might take hours, but quite possibly fewer hours than the V8 modification project sketched above.)
Good luck with your investigation!
Can you please provide an example of a RESTful API call (using HTTP protocol) which is non-idempotent and safe, at the same time (does something like that even exist)?
To elaborate a little bit on this, while reading about the Hypermedia-Oriented Design, I've encountered the 4 affordance aspects that describe each transition: safety, idempotence, mutability and transclusion. Also, I've encountered a table which describes the HTTP verbs through those aspects and it goes like this:
---------------------------------
HTTP Method Idempotent Safe
---------------------------------
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no
---------------------------------
My intuition tells me that all of the safe methods are automatically idempotent too (but not vice versa). I would just like to either confirm or refute this once and for all.
Thanks in advance for the answers.
A safe method - one that does not modify anything - is by definition idempotent. Since it has not changed anything, it will have the same effect (that is, no effect whatsoever) no matter how many times you call it.
Yes. All safe methods are also idempotent, but they refer to two different (but related) qualities of a RESTful API.
A safe method call (one which does not modify the state of the resource on the server) may be issued multiple times by the client without affecting the state of the server (the definition of idempotency).
I need to design a application registry S/W component using C++. Basically, this needs to support addition and deletion of key/values. Dynamic updates need to be supported (for example, when a new application get installed).
Is there a design pattern which closely matches the given problem?
Though I have formulated a rough sketch of the APIs this component needs to support, it would be helpful to have a look at alternative (perhaps better) ways of design.
If there are some typical problems associated with registry design (may be some thread issues which I might have overlooked), I want to make sure I have circumvented those.
Is there a design pattern which closely matches the given problem?
You are probably looking at more than one: A proxy for the entire registry, iterator etc. comes to mind.
If there are some typical problems associated with registry design
You will probably need transactional semantics. Rollback too!
Do you need to save snapshots from time to time? Then you will need an archiving module.
Synchronization: Multiple writes to the registry need to be taken care of.
A similar question has already been asked, so I'm not going to waste time re-explaining it, an existing discussion can be found here:
ToAscii/ToUnicode in a keyboard hook destroys dead keys
The reason I'm posting a new question however is that I seem to have come across a 'solution', but I'm not quite sure how to implement it.
This blog post seems to propose a solution to the problem of ToUnicode killing dead-key support:
http://www.siao2.com/2005/01/19/355870.aspx
However I'm not sure how to implement the suggested solution. A push in the right direction would be greatly appreciated.
To be clear, the part I'm referring to is this:
There are two ways to work around this:
1) You can keep calling ToUnicode with the same info until it is cleared out and then call it one more time to put the state back where it was if you had never typed anything, or
2) You can load all of the keyboard info ahead of time and then when they type information you can look up in your own info cache what the keystrokes mean, without having to call APIs later.
I'm not quite sure how to do either of those things (keyboards and internationalization are far from my strong point), so any help would be greatly appreciated.
Thanks
The first part of the answer is entirely information-free. However, the second part does make sense. ToUnicode() should have been a pure function, which merely acts as a lookup. However, it isn't. But you can call it repeatedly for all expected inputs, store those in your own lookup table and access that.
I'd recommend that Microsoft adds a lookDontTouch flag to the wFlags parameter; that would be a trivial non-breaking API fix.
If you broaden your search to include key logging, you might get some answers. The method presented in the link is extremely cumbersome compared to ToUnicode, but it works. It evolves around finding the current active keyboard layout from the registry and then manually load and parse the proper DLL.
As a note of warning, I've seen the loading part fail miserably on 64-bit Windows.
What is the minimum set of HTTP verbs that a server should allow for a web service to be classed as RESTful?
What if my hoster doesn't permit PUT and DELETE?
Is this actually important, can I live happily ever after with just GET and POST ?
Update: Thanks for the answers folks, Roger's answer was probably best because of the link to the Bill Venners and Elliotte Rusty Harold interview. I now get it.
Yes, you can live without PUT and DELETE.
This article tells you why:
http://www.artima.com/lejava/articles/why_put_and_delete.html
While to true RESTafrians this may be heresy, in the real world you do what you can, with what you have. Be as rational as you can and as consistent with your own convention as you can, but you can definitely build a good RESTful system without P and D.
rp
You can also use X-Http-Verb-Override:DELETE inst. of HTTP DELETE. This is also usefull for Silverlight clients who cant change the HTTP verbs and only support GET and POST...
If you just use GET and POST, it's still RESTful. Your web service may only do things which only required GET or POST, so that's fine.
REST allows for breaking protocol convention if the implementations of the protocol are broken (so that the only non-standard things you do are to get around the broken parts of the implementation). So it is allowable within REST to use some other method to represent generally unsupported verbs like DELETE or PUT.
edit: Here is a quote from Fielding, who is the one that created and defined REST:
A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]
Today's web browsers only handle GETS + POSTS. In Rails, for example, PUTS + DELETES are "faked" through hidden form fields.
Unless your framework has some workaround to "support" PUTS + DELETES, don't worry about them for now.