Spring-AOP @Inject 和 Maven 只能在发布版本中工作

发布于 2024-11-29 11:37:48 字数 1071 浏览 1 评论 0原文

我使用 Spring-AOP 支持通过 @Inject 将引用注入到不由 Spring beanfactory 管理的对象中。例如:

@Configurable(preConstruction=true)
class DefaultContent implements Content 
  {
    @Inject @Nonnull
    private Site site;

    @Inject @Nonnull
    private ModelFactory modelFactory;

    public DefaultContent (final @Nonnull FileObject file)
      {
        resource = modelFactory.createResource(file);   // <--here
      }

我正在使用静态代码编织。

我想我很了解所有相关技术,这确实工作得很好......在正常的开发周期(使用 Maven)。昨天我准备了一个版本(使用 Maven 版本插件),并且版本中的二进制文件似乎注入失败,因为我在标有“此处”的行处得到了 NPE。

为了更好地解释,直到昨天我的项目都处于快照模式(1.0-ALPHA-2-SNAPSHOT)。快照中的二进制文件可以工作。 1.0-ALPHA-2 的二进制文件,发布模式,不需要。下一个快照 1.0-ALPHA-3-SNAPSHOT 中的二进制文件将再次工作。唯一的黑洞是释放的二进制文件。通过 diff 查看,SNAPSHOT 和版本之间没有其他差异,但模块的版本标签不同。

到目前为止,我已经排除了该问题是由于 Maven 发布过程中的一些奇怪的事情造成的,因为即使我在“普通”构建中从标记源重新创建 1.0-ALPHA-2(即,只需 mvn 全新安装)。我还使用 Java 反编译器来查看错误类的有效源(后波),比较 1.0-ALPHA-2 和 1.0-ALPHA-3-SNAPSHOT 中的代码。它们看起来一模一样。最后,我比较了二进制文件(在 Jetty 中运行的 .war 文件),它们包含相同的项目(即,没有缺少依赖项,唯一的区别是我的 jar 文件具有不同的版本)。

我需要一些建议来更好地理解这个错误,因为目前我不知道还能尝试什么。

I'm using Spring-AOP support to inject references via @Inject into objects not managed by the Spring beanfactory. For instance:

@Configurable(preConstruction=true)
class DefaultContent implements Content 
  {
    @Inject @Nonnull
    private Site site;

    @Inject @Nonnull
    private ModelFactory modelFactory;

    public DefaultContent (final @Nonnull FileObject file)
      {
        resource = modelFactory.createResource(file);   // <--here
      }

I'm using static code weaving.

I think I know all the related technologies well and this indeed works fine... during the normal development cycle (with Maven). Yesterday I prepared a release (with the Maven release plugin) and the binaries in the release seem to fail injection, since I get a NPE at the line marked with 'here'.

To explain better, until yesterday my project was in SNAPSHOT mode (1.0-ALPHA-2-SNAPSHOT). Binaries from the snapshot work. Binaries from 1.0-ALPHA-2, release mode, don't. Binaries in the next snapshot, 1.0-ALPHA-3-SNAPSHOT, work again. The only black hole are the released binaries. Looking with diff, there are no other differences among the SNAPSHOTs and the release but the version labels of the modules.

So far I've excluded that the problem is due to some strange thing during the Maven release process, since the binaries are buggy even when I re-create 1.0-ALPHA-2 from tagged sources in a "plain" build (that is, just mvn clean install). I've also used a Java decompiler to look at the effective source (post-waving) of the faulty class, comparing the code from 1.0-ALPHA-2 and 1.0-ALPHA-3-SNAPSHOT. They look identical. At last, I've compared the binaries (a .war file running within Jetty) and they contain the same items (that is, no missing dependencies, the only difference being my jar files with a different version).

I need some suggestion to understand better this bug because at the moment I don't know what else to try.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

幽梦紫曦~ 2024-12-06 11:37:48

我能够通过将列出的依赖项(以及其他一些依赖项)更改为:

@Inject @Nonnull
private Provider<Site> site;

Provider 是一种注入“惰性”依赖项的方法,必须将其推迟为

site.get()

注意,我已经使用了一些 Provider<>过去我的项目中存在依赖关系,因为我发现自己存在一些无法解析的循环依赖关系 - 通常 Spring 会明确给出有关它们的错误通知。因此,这不是我的帖子的完整答案 - 请考虑在运行快照时不需要进行此更改;当项目的不相关细节(例如 SNAPSHOT/release 版本)发生更改时,无法解析的循环依赖关系不能是无法解析或可解析的……

所以我想我在 Spring AOP 中触发了一些错误。尽管如此,提供者还是可以的。事情对我来说是完全可以接受的。

I was able to work around it by changing the listed dependency (as well as a few others) into:

@Inject @Nonnull
private Provider<Site> site;

Provider is a way to inject "lazy" dependencies, that must be deferred as

site.get()

Note that I had already used some Provider<> dependencies in my project in the past as I detected myself some unresolvable circular dependency - usually Spring explicitly gives an error notification about them. So this is not a complete answer to my post - consider that when running a SNAPSHOT this change is not required; an unresolvable circular dependency can't be unresolvable or resolvable when an unrelated detail of the project, such as the SNAPSHOT/release version, is changed...

So I suppose I've triggered some bug in Spring AOP. Still, the Provider<> thing is totally acceptable to me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文