Nestling of beans?
Zen
The default schema for pococapsule configuration allows for nestling
of beans:
<bean id="A" class="CompA">
<method-arg ref="B" />
<bean id="B" class="CompB">
<method-arg type="string" value"text" />
</bean>
</bean>
The proxy-generator does not complain.
The generated _refl.cc file even compiles.
However, the internal bean is not found in runtime. Invoking
getBean("A") will result in an error because B cannot be found.
Is this a bug or the intended behavior?
If nestled beans are not allowed, any plans on changing the schema so
that proxy-generator generates an error?
If nestled beans are allowed, any plans for fixing this bug?
The benefits of allowing nestled beans:
* nestling can be used to clearly mark exclusive use. In the example
above, only A will be using B.
* it becomes easier to group and manipulate beans that "belongs"
together.
* it allows for collapsing entire groups of beans in IDE:s such as VS
and Eclipse. Hence making large files easier to read.
Regards,
Zen
Bryan Raney
On Thu, Feb 11, 2010 at 12:23 PM, Zen <per.bo...@gmail.com> wrote:
> Hi,
>
> The default schema for pococapsule configuration allows for nestling
> of beans:
> <bean id="A" class="CompA">
> <method-arg ref="B" />
>
> <bean id="B" class="CompB">
> <method-arg type="string" value"text" />
> </bean>
> </bean>
> The proxy-generator does not complain.
>
> The generated _refl.cc file even compiles.
>
> However, the internal bean is not found in runtime. Invoking
> getBean("A") will result in an error because B cannot be found.
I do nesting of beans, but I nest the inner bean inside the outer
bean's <method-arg> tag, like this:
<bean id="A" class="CompA">
<method-arg>
<bean class="CompB">
<method-arg type="string" value"text" />
</bean>
</method-arg>
</bean>
This works really well for me. I don't think you need the id
attribute on the "B" bean.
-- Bryan
--
Dr. Bryan Raney
bra...@mad.scientist.com
http://bryan.raneydev.com/
Zen
Have to try that.
Thanks again for the tip.
// Zen
Ke Jin
> Hi,
>
> The default schema for pococapsule configuration allows for nestling
> of beans:
> <bean id="A" class="CompA">
> <method-arg ref="B" />
>
> <bean id="B" class="CompB">
> <method-arg type="string" value"text" />
> </bean>
> </bean>
> The proxy-generator does not complain.
>
> The generated _refl.cc file even compiles.
>
> However, the internal bean is not found in runtime. Invoking
> getBean("A") will result in an error because B cannot be found.
>
> Is this a bug or the intended behavior?
This (i.e. can't resolve the nested bean by getBean()) seems to be a
bug. However, a quick look at the code (resolve_all_bean_ids() in
appctxtimp.C) I can't spot a bug immediately. Need take a more close
look tonight.
> If nestled beans are not allowed, any plans on changing the schema so
> that proxy-generator generates an error?
Nested beans are not bug. They are intentionally supported and even
heavily used by pococapsule itself (e.g. in generated XML of DSM
mappings. It would be very inconvenient without nested beans).
> If nestled beans are allowed, any plans for fixing this bug?
>
Yes, that should be a trivial fix.
Thanks for reporting this issue!
Ke
Ke Jin
Bryan!
Ke
Zen
Bryan's answer only partially answers my questions. His solution
explains how to use nestled beans in a correct way.
However, it does not resolve the issue of the incorrect syntax not
generating an error.
For instance, I would suggest that the proxy generator returns an
error similar to:
"Nested beans are only allowed within <method-arg> tags"
That would be of great help to people (like my self) who are new to
pococapsule.
Thanks again for all the help, both Ke and Bryan.
// Zen
Ke Jin
As said previously, nested bean node (especially the one in your
original example) is not a schema error but valid in PocoCapsule. The
PocoCapsule schema, as defined in the poco-application-context.dtd,
allows two kinds of nested <bean>. The first kind of nesting is that
<bean> as subnode of <method-arg> (and <index-arg>) or <item>
elements. This kind of nesting can be seen in many PocoCapsule
examples and are also common used in other IoC containers (such as
Spring).
The second kind of nesting is that <bean> is a direct subnode of
another <bean> element. Your original example happens to use the 2nd
kind of nesting. This kind of nesting was introduced by PocoCapsule
largely for the convenience of DSM schema transformation stylesheets
(for example, the corba2poco.xsl). Using pxtransform on the setup.xml
of the corba/event or corba/event-classic, you could see the
transformed XML files include such kind of nested beans. In these
examples, these nested beans are all abstract. The purpose is to
generate their proxies needed by runtime reflection but do not bother
to instantiate these beans at runtime.
Due to this intention/assumption (i.e. direct sub <bean>s of a <bean>
are all abstract), these beans are not added to the bean instantiation
description list of PocoCapsule runtime. Hence, these beans are not
valid to be referred as runtime instantiable beans.
On Feb 11, 11:03 am, Zen <per.bohli...@gmail.com> wrote:
> Actually Ke, I don't think you misread my question.
>
> Bryan's answer only partially answers my questions. His solution
> explains how to use nestled beans in a correct way.
> However, it does not resolve the issue of the incorrect syntax not
> generating an error.
As said, the syntax is correct by the schema definition. Even if it
wasn't correct, it would be easy to catch such kind of error by simply
remove the bean as a subnode from <bean> element's definition in the
poco-application-context.dtd document.
> For instance, I would suggest that the proxy generator returns an
> error similar to:
> "Nested beans are only allowed within <method-arg> tags"
> That would be of great help to people (like my self) who are new to
> pococapsule.
>
If you want to prohibit your users to use this kind of nesting, you
can simply modify the <bean> element definition (in the poco-
application-context.dtd) from:
<!ELEMENT bean (method-arg*, on-error?, (ioc|bean|property)*)>
to
<!ELEMENT bean (method-arg*, on-error?, (ioc|property)*)>
Regards,
Ke