Spring:在 ID 中使用名称空间的 bean 与 SPeL 冲突

发布于 2024-12-15 01:06:42 字数 1396 浏览 3 评论 0原文

Dhanji 在他的有关依赖注入的书中鼓励在命名 spring bean 时使用命名空间。

书中引述:

我还强烈鼓励使用命名空间,例如“set.BinaryTree”和 “set.HashTable”,比“binaryTreeSet”更容易阅读和理解 和“哈希表集”。命名空间是一种更优雅、更自然的命名法 您的密钥空间,并且比分组大写的字符串更具可读性 话。

现在听起来很合理。但从 SPeL 开始,就会产生冲突。 Ozzy 曾经在 Black Sabbath 中演奏,所以对于每个乐队成员,我都会在 bean 名称中使用 bs 命名空间,如下所示:

<bean id="bs.ozzy"
    class="sk.spring.idol.annotation.Instrumentalist" 
    p:song="Sabbath Bloody Sabbath" />

现在我有黑色安息日的其他成员,他们将使用以下方式为歌曲名称注入值斯佩尔。无论奥兹播放什么歌曲,我的新成员(比如说托尼)也会播放:

public class Instrumentalist implements Performer {

@Value("#{bs.ozzy.song}")
private String song;

// blabla other stuff, getters setters and so on

}

现在我会得到的是...

Expression parsing failed; nested exception is org.springframework.expression.spel.SpelEvaluationException: EL1008E:(pos 0): Field or property 'bs' cannot be found on object

现在怎么办?是否有某种方法可以将文本转义为“这是 bean 名称,并且不将其评估为属性”?

注:

  • 代码示例的灵感来自 Dhanji 的书。
  • 我承认 - 我还没有阅读 SpEL 的完整文档,也许解决方案要简单得多

Dhanji in his book about Dependnecy Injection encourages usage of namespaces when naming spring beans.

Qutation from the book:

I also strongly encourage use of namespaces, for example, "set.BinaryTree" and
"set.HashTable," which are nicer to read and comprehend than "binaryTreeSet"
and "hashTableSet." Namespaces are a more elegant and natural nomenclature for
your key space and are eminently more readable than strings of grouped capitalized
words.

Now that sounds reasonable. But as of SPeL, the conflicts arises.
Ozzy used to play in Black Sabbath, so for every band member I'll use bs namespance in bean name like so:

<bean id="bs.ozzy"
    class="sk.spring.idol.annotation.Instrumentalist" 
    p:song="Sabbath Bloody Sabbath" />

Now I have other member of black sabbath, who will have injected value for song name using SpEL. Whatever song that ozzy plays will also play my new member (let's say Tony):

public class Instrumentalist implements Performer {

@Value("#{bs.ozzy.song}")
private String song;

// blabla other stuff, getters setters and so on

}

Now what will I get is ...

Expression parsing failed; nested exception is org.springframework.expression.spel.SpelEvaluationException: EL1008E:(pos 0): Field or property 'bs' cannot be found on object

Now what? Is there some way to escape text as "this is bean name and don't evaluate this as property"?

Notes:

  • The code sample is inspired by Dhanji's book.
  • I confess - I haven't read the whole documentation for SpEL, maybe solution is much much simpler

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

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

发布评论

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

评论(2

黑寡妇 2024-12-22 01:06:42

你可以这样做:

@Value("#{ #this.getObject('bs.ozzy').song }")

You can do this:

@Value("#{ #this.getObject('bs.ozzy').song }")
So要识趣 2024-12-22 01:06:42

我不确定上下文本身是否作为属性/引用公开。

如果不是(仍在寻找),您可以创建一个按名称查找 bean 的函数,因此它看起来像这样(或多或少):

@Value("#{byId('bs.ozzy').song}")

即使您可以通过方法或映射查找通过 id 获取 bean使用字符串键,我对这个想法有点“meh”,因为你可能会失去一些 IDE 功能。

我想我更喜欢使用 _ (下划线)命名空间。使用点会搞砸大多数希望点成为属性分隔符/方法调用的东西(这是很多东西)。

I'm not sure if the context itself is exposed as a property/reference.

If it's not (still looking), you could just create a function that looks up a bean by name, so it'd look like this (more or less):

@Value("#{byId('bs.ozzy').song}")

Even if you could get a bean by id via a method or map lookup with a string key, I'm kind of "meh" about the idea, because you'd potentially lose some IDE functionality.

I think I'd prefer namespacing with an _ (underscore). Using dots screws up most anything that expects dots to be a property separator/method call (which is a lot of stuff).

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