On 3/4/07, Bernhard Huemer <[EMAIL PROTECTED]> wrote:
Hello,
I understand that in some scenarios an application developer wants to
override the characteristics that are specified via annotations, but
what's the reason for overriding even the type of a managed bean?
Two common scenarios where you might want to override the
configuration information that was originally specified with
annotations:
* Third party beans where you don't have the ability
to modify the sources to meet your requirements.
* Use cases where the annotated configuration is
default values, but the bean is explicitly designed to
allow you to customize things (via configuration files).
This pattern is essentially universal across all of Java EE ...
everything you can specify with annotations can be overridden with
configuration files. Thus, it made sense to emulate this pattern with
Shale as well, because Shale users will likely expect the same sorts
of behaviors.
One key difference is that with Java EE overrides, you can use
*partial* configuration files that only contain enough information to
identify the element you are configuring, and just the settings you
are overriding. If/when JSF supports annotation based configuration,
I would expect to see it handled the same way. It didn't make sense,
in the mean time, to invent a completely new syntax for partial
configuration that would almost certainly not match whatever actually
happens.
It's quite cumbersome to maintain these managed beans, as you (or at
least I) normally don't know where to start looking for possible
annotations.
I don't understand quite what you are saying. Managed bean
annotations can only be in one place ... on the source code for bean
classes in your application.
For example, think of the test cases in the shale-tiger
project (I'm refering to VariableResolverImplTestCase#testBean3()). Even
though TestBean3 uses the Value annotations to specify dependencies, an
instance of TestBean will serve as actual injection target.
Note that the setUp() method of this test case processes four JSF
configuration files ... and /WEB-INF/test-config-3.xml defines a
"bean3" that totally replaces the annotated versions. That is exactly
in accordance with the documentation.
In my opinion it's also quite unreasonable that following modification
to TestBean3 causes an exception.
///
line #223:
+
+ @Value("arbitrary value")
+ private String anotherString;
+
+ public void setAnotherString(String anotherString) {
+ this.anotherString = anotherString;
+ }
+
+ public String getAnotherStringProperty() {
+ return anotherString;
+ }
}
\\\
javax.faces.el.EvaluationException: Managed bean definition bean3
specifies a managed property anotherString whose value expression
arbitrary value threw an exception when evaluated
at ....
Well, actually the exception is reasonable, as the class TestBean has no
property called "anotherString", but I guess you got the idea.
I'm afraid I do not get the idea. AFAICT, the correct behavior is
being performed because of the overridden definition of "bean3"
mentioned above.
Bernhard Huemer
Craig
