On Apr 9, 2006, at 12:23 AM, David Jencks wrote:
There seems to be a problem with collection valued references in
1.1. Normally we want a collection valued reference to determine
its members based on the target gbeans implementing an interface.
This works great for single valued references but currently there
is no way to specify an interface that is actually used for a
collection valued reference. I was under the impression that the
interface declared in GBeanInfo was used for this purpose but this
is not currently the case. There is also no way to specify an
interface in the xml for a plan.
As I see it, the desired interface is not something a user should
be able to change, and it should be supplied in the gbean metadata,
currently GBeanInfo. I think requiring a user to specify the
target interface in a plan is an undue burden. However, if
metadata is the only source this would make it difficult to, in the
future, deploy services with collection valued references that lack
metadata entirely.
I think the best solution might be to use metadata if present (from
GBeanInfo, annotations, or java 1.5 generics) and allow specifying
the interface in the plan as well for when metadata is lacking.
Comments?
I would prefer that we explicitly list the interfaces if the goal it
to query by interface. As an experienced user I find it confusing
myself when I see a reference in a plan that contains no data. I am
left wondering what we expected to get in the query. I guess I could
take the extra step to open my ID, open the file in an editor, and
then scan for the GBeanInfo.
Anyway, I think my biggest dislike of this, it that it will make it
extremely difficult to remove the much hated GBeanInfos from our
services.
I believe this is currently causing a problem with the
JettyModuleBuilder and default servlets: the default servlet gbeans
implement org.apache.geronimo.jetty.JettyDefaultServletHolder
rather than org.apache.geronimo.jetty.JettyServletHolder but since
there is no way to specify the desired target interface all
servlets end up getting treated as default servlets, causing severe
problems when hot deploying a web app.
I fixed this by just listing the two default servelts by name. I
believe this is much less error prone.
-cain
