Question

好的，为标题道歉，但我不知道怎么说这个。基本上我通过XPagesToolkit和XPageAgents遇到了sessionCloning，我假设它是使用这里描述的技术实现的http://www.wissel.net/blog/d6plinks/SHWL-99U64Q

我最初用它来运行由xpage触发的现有java代码，但可能需要一段时间才能运行。麻烦是我以这种或那种方式拥有的大多数现有代码依赖于FacesContext，以便访问公共bean以进行设置或仅用于基本日志记录。这会在通过XPagesAgent触发时导致错误，因为我认为没有facescontext。我真的不想最终复制代码并创建不同版本的业务逻辑。

所以我想我有两个问题..

1）要从java代码中引用bean，我可以使用这里描述的Factory方法，而不是直接通过variableResolver ... http://www.wissel.net/blog/d6plinks/SHWL-98U9EK但是我不知道如何手动创建bean对象，仍然可以获取可能已在faces config中设置的自定义属性。有没有办法以某种方式阅读这些？例如如果你手动创建一个dBar对象，你将如何从faces-config中获取logdb路径？

2）人们如何以一种无论在何种情况下始终有效的方式进行登录？我收集大多数人现在使用debugToolbar或XPagesOpenLogger，但这两者似乎都依赖于facescontext。我不想停止使用它们，但必须为了使我的java代码在xpage之外兼容。目前，大多数方法都有某种try / catch来调用dBar.error（e）。也许答案是创建一个连接dBarToolbar和原始prexpages openlogger java类的接口，然后通过工厂访问日志对象，该工厂将返回dbbar实例或openlogger，具体取决于是否存在faces上下文。或者人们在较低级别的方法中抛出错误，只是让更高级别的调用函数处理并记录它们？

谢谢！

解决方案 使用引导依赖注入我最终破坏了dBar以使其在两个方面都起作用。我的商业bean仍然在顶部包含这个以便于记录

private final static DebugToolbar log = DebugToolbar.get();

但已经破解了一点，以使dBar也充当单身......

private static DebugToolbar instance;

// retrieve an instance of this toolbar class
public static DebugToolbar get() {
    if (null == instance) {
        return (DebugToolbar) resolveVariable(BEAN_NAME);
    } else {
        return instance;
    }
}

public static void setInstance(Session session, Database database) {
    instance = new DebugToolbar(session, database);
}
public static void clearInstance() {
    instance = null;
}

然后我可以像以前一样继续使用它来形成Xpage，但是当运行XPagesAgent时，我可以在开始时调用它来传递所需的引用，允许业务bean像以前一样使用相同的日志记录“工作”。

DebugToolbar.setInstance(session, database);

这是在XPagesAgent的末尾

DebugToolbar.clearInstance();

我不知道是否有必要，但如果单身人士比代理人持续时间更长，我认为他们会出错，我明白这样做

显然对dBar代码本身进行了一些调整，以跳过与FacesContext相关的任何内容（如果它不可用）。

这可能是一个可怕的反模式，但似乎有用...... :)

Answer 1

简答：declutter和依赖注入。

答案很长：
试着看看MVC模式。将通过EL直接与XPage交互的bean限制为外观模式。从那里调用您的业务bean并移交Java对象或Notes对象，如视图，文档或会话等。

当您想要将业务bean打包到（junit）测试工具中时，这是绝对必要的。所以而不是：

 BusinessBean.makeInvoices();

你会得到：

 BusinessBean.makeInvoices(session, NotesView, OutputStream);

可以从XPage，代理或独立的Java程序（想想JUnit，Jenkins）调用后面的函数。因此，不是在bean中找出依赖关系，而是在调用中提供它们。

这也称为关注点分离。你的豆子没有打扰周围的东西。

希望有所帮助

Answer 2

正如斯图威尔先生所说，依赖注入是走向这里的方式。

但是对于日志记录，我更喜欢使用Log4j方式并避免将记录器传递给params。

按Log4j方式，我的意思是通过静态工厂方法（如Logger.getLogger（'some.class'））获取对logger对象的引用，并将配置加载到log4j框架。

不幸的是，我不知道OpenLog记录器是否可以这样配置，它会自动从给定的配置文件（faces-config或其他）中读取设置。

您总是可以为log4j编写自定义appender，将日志路由到OpenLogger（这应该非常简单）

Answer 3

从为OpenNTF Domino API开发日志记录的经验来看，最大的问题是Java安全异常。这包括定义不同的记录器和日志记录级别，以及动态加载不同的配置。您可以使用插件处理大部分内容，但我不确定您是否想要走得那么远。

Log4J是一种标准的Java日志记录机制，但它也会遇到安全选项。我认为log4j的自定义appender会遇到相同的安全异常，除非它在插件中。有人建议使用匿名记录器，但我还没试过。

OpenNTF Domino API在核心插件中有各种日志选项，而不是Xsp插件。 BaseOpenLogItem是IOpenLogItem的核心实现，不对facesContext有任何依赖。还有一个记录器可以记录到IBM_TECHNICAL_SUPPORT中的文件。 DominoUtils.handleException（Throwable）或（Throwable，String）将执行该日志记录。挑战在于确定触发异常的代码。

在不依赖FacesContext的情况下为业务逻辑创建Java类

3 个答案: