Hi Marek,
see inline-comments
On 10.03.2011, at 10:50, Marek Potociar wrote:
> Hi Adam,
>
> On 03/09/2011 06:35 PM, Adam Bien wrote:
>>
>> On 09.03.2011, at 16:41, Bill Burke wrote:
>>
>>> The problem is that he wants to inject information about the sub resource into the creation of the EJB.
>>
>> And this is a huge problem. It happens in every non-trivial application.
>
> So far we are discussing data (@PathParam) that can be injected directly into a subresource method. E.g.:
>
> @EJB SB sb;
>
> @Path("{id}")
> public SB getSb() {
> return sb;
> }
>
> ...
>
> SB {
> @GET
> public String getId(@PathParam("{id}") String id) { // id from parent gets injected
> return id;
> }
> }
>
> or:
>
> @EJB SB sb;
>
> @Path("{id}")
> public SB getSb(@PathParam("{id}") String id) {
> // do something with id ...
>
> return sb;
> }
>
> ...
>
> SB {
> @GET
> public String getId(@PathParam("{id}") String id) { // id from parent gets injected
> return id;
> }
> }
This goes already in the right direction. You could even inject the @PathParam to the instance as a "proxy" and get access to it in the current thread. It would work like SessionContext in EJB.
For me a @PathParam as a method parameter would also work.
>
> For more examples, see also:
> http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-tests/src/test/java/com/sun/jersey/impl/subresources/SubResourceDynamicWithDuplicateTemplateNamesTest.java
>
> I am looking for use cases where the above-mentioned method injection would not work so that we can assess the priority
> of this issue.
>
> Marek