Hi,
On 12/20/2012 12:47 PM, Sivakumar Thyagarajan wrote:
>> It would be 2 MCFs with their unique CF (SubInterface1 and SubInterface2)
>> -- SuperInterface would be an implementation detail. But the user would
>> use SuperInterface in their code.
>
> When a user uses SuperInterface, then I assume they inject the
> connection factory through a @Resource or a lookup. For example
>
> FooServlet {
> ...
> @Resource(name="...", mappedName="...")
> SuperInterface cf;
> ...
> }.
>
> In this case, it is the name and mappedName that is used by the
> container to choose the right CF in JNDI that had been created earlier
> through resource definition annotations.
>
> The resource definition annotations, OTOH, would have to specify the
> actual CF interface name because that is the unique part of the
> connection-definition. (Two connection-definitions with different CF
> interface names can share the same MCF class. In the example below, the
> MyEISRA could have had one MCF class MCF1 for both subinterface1 and
> subinterface2). So, to define CFs for subinterface1 and subinterface2,
> the annotations would look as follows:
>
> #1.
> @ConnectorConnectionFactoryDefinition(name="java:comp/eis/cf-subinterface1",
>
> className="subinterface1",
> resourceAdapterName="MyEISRA")
>
> and
>
> #2.
> @ConnectorConnectionFactoryDefinition(name="java:comp/eis/cf-subinterface2",
>
> className="subinterface2",
> resourceAdapterName="MyEISRA")
>
> In the above example, if the user wants to inject a CF of subinterface1
> but still refer to it as a superinterface, they would have the following
> resource declaration:
>
> #3.
> @Resource(name="...", mappedName="java:comp/eis/cf-subinterface2")
> SuperInterface cf;
>
> and to inject CF of subinterface2 and use it as subinterface2, they
> would have:
>
> #4.
> @Resource(name="...", mappedName="java:comp/eis/cf-subinterface1")
> SubInterface2 cf;
>
> This would all work. However, during the resource definition at #1 and
> #2 above, we would still need the user to specify the appropriate
> subinterface during resource definition.
>
And hence we are relying on them to make the correct definition.
But yes, it is probably best not to make changes to the type of
definition compared to the other areas of spec.
It can be solved in the deployment chain by throwing a deployment
exception if the user definition doesn't make any sense.
Best regards,
Jesper
P.S. You can't use :comp ;)