问题标签 [jca]

我必须验证可能大至 2Gb 的文件上的签名，并且我希望以尽可能节省内存的方式进行验证。由于各种原因，该文件已经完全加载到内存中，InputStream并由应用程序使用访问。我想使用流接口验证签名，但是 JCASignature类的update方法只接受byte[]和相关的类。

我怎样才能有效地做到这一点？我不想将野兽加载到第二个字节数组中，否则我们会看到一些严重的高内存使用，但接口似乎不支持它。

更新

如果重要，签名算法是 SHA-1

我们的应用程序经常通过 Web 服务、MQ、JDBC、专有（直接通过套接字）和其他类型的传输连接到不同类型的后端。我们已经有许多实现可以让我们从应用程序连接到这些后端，虽然所有这些实现都实现了通用的 java 接口，但它们不共享任何其他内容。

我们已经意识到，对于所有这些特定的连接器实现来说，存在一些通用的代码部分，我们决定通过一个通用连接器来简化未来连接器的开发。此连接器将能够将消息格式化为后端预期的格式，并使用可用的传输机制发送它们。例如，通过 MQ 或通过套接字的固定长度消息格式。

我们面临的困境之一是最适合这种连接器的技术。到目前为止，我们的连接器是实现通用 java 接口的基本 java 类。由于我们通常将我们的应用程序托管在一些 Java EE 应用程序服务器中，因此 Java 连接器架构似乎是最适合该软件的技术。但是，实现符合 JCA 的连接器似乎相对复杂。采用标准 - JCA 有哪些明显的好处，这些好处是否证明了额外努力的合理性？

Eclipse WTP 中不同类型的 Java EE 项目有什么不同？

有：

• 应用客户端项目
• 连接器项目
• 企业应用项目
• 公用事业项目

我正在编写一个 JCA 资源适配器。我也在尝试完全理解 JCA 规范的连接管理部分。作为一个思想实验，假设这个适配器的唯一客户端是位于另一台机器上的 Swing Java 应用程序客户端。还假设资源适配器也将通过网络与其“企业信息系统”(EIS) 进行通信。

据我了解 JCA 规范，.rar 文件部署到应用程序服务器。应用程序服务器创建 .rar 文件的 ManagedConnectionFactory 接口实现。然后它要求它生成一个连接工厂，这是部署到 JNDI 的不透明对象，供用户用来获取到资源的连接。（对于 JDBC，连接工厂是 javax.sql.DataSource。）

要求连接工厂保留对应用程序服务器提供的 ConnectionManager 的引用，而后者又需要是可序列化的。这是有道理的——为了将连接工厂存储在 JNDI 中，它必须是可序列化的，并且为了保持对 ConnectionManager 的引用，ConnectionManager 也必须是可序列化的。很好，这个小对象图安装在应用程序客户端的 JNDI 树中。

这是我开始感到不安的地方。ConnectionManager——由应用程序服务器提供的应该处理连接管理、共享、池等的部分——此时是否完全存在于客户端上？它的工作之一是创建 ManagedConnection 实例，ManagedConnection 不需要是可序列化的，它提供的用户连接句柄也不需要是可序列化的。对我来说，这表明整个连接池机制被批发到应用程序客户端并填充到它的 JNDI 树中。

这是否意味着来自客户端的 JCA 交互绕过了应用程序服务器的服务器端组件？JCA API 中的网络边界在哪里？

对于我们当前基于 JBoss 的 J2EE 项目，我们需要使用消息驱动的 bean 和第三方作为 RAR 文件提供的 JCA 资源适配器与远程系统交互。我想将整个项目打包并部署为一个 EAR 文件到我们的 JBoss 服务器。最值得注意的是，RAR 文件应该嵌入到 EAR 文件中，而不是全局部署。

到目前为止，所有这些都运行良好，但我对 RAR 文件的引用方式并不特别满意。例如，与 MDB 一起打包的 jboss.xml 目前看起来像这样：

虽然这通常工作正常，但当 EAR 文件重命名为“test2.ear”时它会中断。有没有办法在不硬编码包含存档名称的情况下引用嵌入式 RAR 文件？

编辑：差不多两个月后，我仍然没有找到这个问题的真正答案。四处询问，我得到的只是这两个有用的建议：“使用 Maven 属性和过滤”和“不要在 EAR 中包含 RAR”。我强烈怀疑目前没有办法在 JBoss 中正确处理这个问题。所以我会放弃它，只接受我在这里得到的唯一答案。

我想知道是否可以在 jca 适配器中获取对 ejb3 本地业务接口的引用？

资源适配器和 ejb.jar被打包到同一个.ear. 应用程序在带有 ejb3 功能包的 WebSphere AS 6.1 下运行。

我曾尝试将其ejblocal:<full_class_name_of_local_interface>用作 JNDI 名称，但没有成功。

我们一直在使用 JCA 与 WebSphere 内部的低级网络资源进行交互，但是我们需要能够从 Tomcat 外部访问相同的网络资源（即不在托管环境中）。网络通信和协议布局非常冗长，所以我们宁愿不复制/粘贴几千行代码（然后必须单独维护它们）。

通过阅读 JCA 规范，应该可以支持在非托管环境（例如 Tomcat）中执行代码。不幸的是，我不知道接口应该做什么，或者如何从托管环境之外调用它们（规范非常模糊）。

是否有任何实现示例展示如何修改 JCA 以在非托管环境中使用？

谢谢！

是否有任何可用于 JBPM 的 JCA 资源适配器可以使用？JBPM 如何在我们没有 Jboss App 服务器的生产环境中使用？

我读到 JCA 用于遗留 EIS 集成。该规范是否面向供应商而不是应用程序开发人员？我很想知道开发人员编写 JCA 适配器来解决他们的技术或业务问题的用例。

我之前写过一个JCA 资源适配器。

然而，现在我发现自己不得不写一个仅仅为了访问BootstrapContext及其相关的WorkManager，并且没有其他原因有效。

如果我正确阅读规范——这是我的问题——看起来如果我希望有人能够以符合规范的方式使用ManagedConnectionFactory我的资源适配器，我仍然需要实现，因为看起来只有实现提供的用户连接工厂ManagedConnectionFactory有资格通过@Resource注释进行注入。

来吧，再读一遍；我会等。:-)

在一个完美的世界里，我想编写我的ResourceAdapter实现，用 注释它@Connector，指定所有@ConfigProperty位，将它打包到一个.rar文件中，然后完成它。

但是，在我看来，规范实际上要求消费者（在我的情况下为无状态 EJB）和资源适配器模块之间的所有通信都应该通过用户连接工厂来完成。

例如，第 6.10.1 节说：

资源适配器必须提供以下接口的实现：

• javax.resource.spi.ManagedConnectionFactory
• javax.resource.spi.ManagedConnection
• javax.resource.spi.ManagedConnectionMetaData

但是第 18 节——关于注释的部分——似乎并没有以任何有意义的方式强制执行这一点。

真的是这样吗？我想肯定是这样，但我很想听听那些组装了 1.6 资源适配器的人的来信。