Xpages 在nsf中使用javascript原型后，如何清理Domino服务器中的SSJS？

有人在nsf中使用Javascript原型后，如何清理Domino服务器中的SSJS（服务器端Javascript）

Mark Roden在XPages SSJS中发现了一个错误：（感谢David Leedy告诉我这一点并给我看这篇文章）

如果您有以下SSJS代码：

var dummyObj = {}
dummyObj.prototype.NAME = "Johann"

XPages SSJS不关心您是否使用var（var意味着变量必须是本地的），它使用值Johann在整个服务器中显示dummyObj.NAME。因此，如果同一服务器中的另一个nsf使用具有相同名称的var，它将继承整个原型：

var dummyObj = {}
println(dummyObj.NAME) /*prints "Johann" */ 

这是一个巨大的bug（导致不可靠的XPages-SSJS-IMO）。即使您根本不使用prototype，如果应用程序中的其他人执行以下操作：

String.prototype.split = function(){ return "I broke this method" }

它将断开使用Innomysplit（）的同一服务器中的所有应用程序

因此，问题是：如果有人“错误地”在NSF中编写了以下SSJS（XPages服务器端Javascript）：

String.prototype.split = function(){ return "I broke this method" }

如何将String.prototype.split（）修复为其原始值

正如MarkRoden所说，重新启动HTTP任务并不能解决这个问题

///////////////////////////////////////////////////////////

编辑1：为什么我认为这是一个巨大的错误：

我是一个Javascript爱好者，但IMHO@MarkyRoden在SSJS中发现了一个巨大的bug。填隙片和多边形填充并不是真正的主要问题。Eval被认为是一种不好的做法，但prototype对象是基本Javascript的基本元素。这是向Javascript类添加方法的标准和首选方法，也是继承和所有类型的应用程序所需的方法。因此，为了避免冲突，您需要在服务器级别使用某种名称空间。所有这些都非常糟糕，但最大的问题是，一个应用程序中的一行代码可能会破坏服务器中的所有应用程序。是的，您可以信任您的开发人员，但是其中一个开发人员可能会错误地编写一行错误的代码，而且Domino服务器可能有来自不同软件供应商的数百个应用程序。在代码评审中设置责任并不是一个可靠的足够程序。也许是时候在SSJS中使用真正的javascript引擎了，比如V8、Spidermonkey、Chakra或Rhino。作为一个解决办法，我在想汤米·瓦兰德的

编辑2：更糟。你可以这样做：

prototype.importPackage = null

或

正如您在@SvenHasselbach的文章中所看到的：

---

编辑3:IBM：你告诉我我可以使用SSJS。来吧！请把这个修好，太可怕了。请让我们正式向IBM报告此问题。

尝试执行重新启动任务

---

告诉http restart不会完全重新启动http任务

您可以使用以下Java代码重置SSJS解释器：

FacesContextExImpl fc = (FacesContextExImpl) FacesContextExImpl.getCurrentInstance();
UIViewRootEx2 uiRoot = (UIViewRootEx2) fc.getViewRoot();
JSContext jsContext = uiRoot.getJSInterpreter().getJSContext();
jsContext.getRegistry().init(jsContext);

这将重新初始化注册表和所有原型函数

编辑：将fc的声明更改为正确的类型

编辑2: 以下是SSJS版本：

var uiRoot = facesContext.getViewRoot();
var jsContext = uiRoot.getJSInterpreter().getJSContext();
var reg = jsContext.getRegistry();
reg.init( jsContext );

---

我是否正确地理解您，您希望清理SSJS解释器以避免与您自己的原型扩展冲突？ 为了澄清上面的答案：这将重新初始化SSJS解释器一次。而且只有一次。 您必须一次又一次地这样做，因为在重新初始化之后，服务器上的另一个应用程序可以再次覆盖原型功能。这就是为什么这不是一个真正的解决方案，这是对你最初问题的回答

---

如果另一个应用程序在您的代码尝试使用您的扩展时执行相同的操作，则会产生有趣的后果。

Restart Task Http会清除所有原型。美好的但是，当再次执行带有错误原型代码的错误应用程序时，该怎么办？如何保护我的XPage应用程序不受此影响？我对此非常担心。这是一个巨大的错误。IBM真的应该修复它。如果没有解决这个问题的方法，怎么会有人继续相信XPages SSJS呢？这不是一个bug，而是SSJS实现方式的一个不幸特性。我信任SSJS，而不是开发者。因此，我不鼓励您使用垫片，也不鼓励其他人使用prototype，我恐怕-对不起：（@JohannEchavarria:您不能信任SSJS。出于安全原因，当查看它时，它会被设计破坏。但这并不意味着您不能在“受信任的环境”中使用它：管理员必须查看不好的片段，必须射击重写内部函数的开发人员（这不仅仅是“原型”的事情）。使用“eval”也是不行的。@MarkyRoden&Sven:我编辑了我的问题，并添加了为什么我认为这是一个巨大的错误。管理员怎么能真正检测到有人在使用它呢“prototype”？他们应该专门做一个代码扫描吗？我会在这里冒险，并建议这可能是另一个在XPages业务逻辑中更喜欢Java而不是SSJS的好理由……关于你的编辑评论。我认为关键是SSJS不是“真正的JavaScript”"。因此，您需要相应地管理您对SSJS的期望。特别是在OOP中。您无法在SSJS中真正执行对象。如果您将代码放入函数中，那么它们就不可序列化。老实说，我相信真正的解决方法是使用Java而不是SSJS。这是在XPages开发中尽可能多地使用Java和EL的另一个原因我同意Knut和戴维的观点。也考虑Jesse Gallagher几年前做的一些事情，让你可以在RXPEX中编写Ruby代码：XPoST是一个基于JSF的平台，运行在java虚拟机中，所以为了让人们编写Ruby，杰西必须编写一个解析引擎来允许java解析Ruby。Ryo解析器也在做同样的事情。它使用Java类来告诉Java如何解析Rhino。因此，除非我有误解，否则在SSJS中不能有真正的javascript引擎，因为您将使用Java解析器来解析该javascript引擎。调试可能也是一个挑战。我强烈反对任何人尝试使用String.prototype来修复缺陷

var uiRoot = facesContext.getViewRoot();
var jsContext = uiRoot.getJSInterpreter().getJSContext();
var reg = jsContext.getRegistry();
reg.init( jsContext );