On 18 Dec 2013, at 22:37, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 18/12/2013 4:04 PM, Marek Potociar wrote:
>>
>> On 18 Dec 2013, at 21:15, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> On 18/12/2013 12:13 PM, Marek Potociar wrote:
>>>>
>>>> On 12 Dec 2013, at 17:43, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>>>
>>>>> There is something we can do. As proposed at https://java.net/jira/browse/JERSEY-1950?focusedCommentId=371416&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_371416 we can expose factories necessary for Guice to do 100% of the injection, and I'll provide the necessary Guice module to do the binding instead of HK2. I think Jersey core should depend exclusively on JSR-330 (only do injection) and delegate DI configuration to external/optional modules. There would be one such module for HK2, Guice and Spring. I suspect this will require a small number of changes on your end, the main one being that the DI will inject Application instead of Application instantiating the DI engine. Once we're over that hump, the rest should be easy.
>>>>>
>>>>> I'm going to need your help with these changes because I'm not sure how to implement DI injecting Application instead of Application creating the DI.
>>>>
>>>> Unfortunately, we do not have resources to invest into such a large piece of work at the moment. It is also not clear to me who would then write the bridge between Guice/Spring & CDI, Guice/Spring and EJB, necessary integration with JNDI and injection in GlassFish, WebLogic... etc. As a JAX-RS reference implementation, we MUST support CDI, EJB and GlassFish as Java EE RI in all our injection-provider configurations. We also MUST support WebLogic as Jersey is fully sponsored by Oracle.
>>>>
>>>> Also, if we would do what you are suggesting, rather than having to worry about integration with a single injection framework we would suddenly have to maintain:
>>>>
>>>> 1. Jersey proprietary injection provider SPI - something we wanted to get rid of in the first place
>>>> 2. HK2 injection provider implementation
>>>> 3. Guice injection provider implementation
>>>> 4. Spring injection provider implementation
>>>> 5. Integration between all the above and a combination of CDI, EJB, JNDI x GlassFish, WebLogic, OSGi, Jetty, Grizzly, Tomcat...
>>>
>>> The Jersey team wouldn't have to maintain any of this.
>>>
>>> #1: Why would we need such a thing? I never asked for this.
>>
>> Ok, I must have misunderstood. You want to provide implementations for Factory from Guice API. I get it now, sorry for the confusion. Well, good luck, fingers crossed. :)
>
> Just to be 100% sure we're on the same page: Right now you implement some Factory for (say) UriBuilder and bind it into HK2. I'm asking you to expose these factories in an SPI package. The Guice, Spring, Dagger extensions would then come in and provide a Guice, Spring, Dagger configuration that binds those factories in the Guice, Spring, Dagger-specific way. Jersey's commitment is two-fold:
> Expose Factory implementations (the ones that you already have for HK2).
> Use (only) JSR 330 to inject them.
> Where we might run into trouble is #2. Do you use any HK2-specific annotations/features at injection time?
>
Ok, so we do not understand each other in the end. I thought YOU are planning to create those factories yourself (even though I could not understand how, now I (hopefully) get it...).
The problem with the above is that:
1. we do not at the moment expose all of the injectable stuff via factories (for various reasons)
2. we do not want to expose all our internal injection related classes as APIs
3. we rely on HK2 dynamic injection bindings in Jersey core code - we e.g. bind application providers dynamically after application startup. Not sure if you considered at all the related challenges (introducing another APIs, significant core code changes etc.)
4. we directly leverage HK2 APIs all over the core code - yet another set of adapter APIs would have to be introduced and yet another massive refactoring would be necessary
5. our request scope implementation is also HK2-based (this is my least concern though)
Which brings me to reiterating my previous statement: we do not have the necessary resources to invest currently into a task of such a significant scope. We cannot commit to do this work any time soon.
If this is really the way you want to go, you should perhaps focus on working with HK2 folks on exposing their binding model and a fully pluggable "injection engine" SPI. This may sound similarly difficult, but we're in fact talking about exposing a handful of existing internal HK2 classes and interfaces as public APIs. Maybe even less - I'm talking mainly about Descritpors and InjectionResolvers here. You may also need to ask HK2 for a switch to delegate all the injection to the provided engine.
>>> #5: I don't understand what sort of integration you had in mind. Why would you ever need/want to integrate Guice and CDI?
>>
>> Why? To be compliant with JAX-RS spec. Or do you think that there are no users who use Spring or Guice with a Java EE application server? Well there are. Plenty.
>
> As far as I understand it, JAX-RS does not specify which DI implementation you must support under these platforms. I'm simply saying that you continue with the status quo (provide support for Hk2) and let the community provide add-on modules for other use-cases. The only thing they'd need from you is the DI factories mentioned above.
In Java EE we MUST support CDI and EJB bean discovery and injection. Your DI framework would have to guarantee that if used in a Java EE container, it will provide the necessary integration. Otherwise you would end up with a non-compliant implementation.
>>
>>> In any case, the only thing I'm asking you to do is ensure that the community can implement add-ons for other DIs (provide the descriptors/factories to bind to). The only integration you'd have to officially support is the one that you already do.
>>
>> How am I supposed to ensure that?? Sorry, but this is a little bit ridiculous. I do not have the community on my command ...as much as I would occasionally like to :)
>
> I suspect we're having a misunderstanding again. The only thing I'm asking you to do is release the aforementioned DI factories. Nothing else.
Please see the above - that will not help you. Regardless of the fact that we would need to expose around 60 private classes as public API, this is still not even close to all the direct class or instance-based bindings we define.
>>>> Once again, at the moment, we simply have other priorities and cannot afford allocate the necessary resources into such a big task that is not aligned with our priorities. You should consider HK2 to be our current injection layer and HK2 SPIs are our own SPIs. Using HK2 helps us focus on our core business and let specialized team deal with injection issues. The idea that exposing one more custom injection SPI will solve all the issues is naive. It will not. It will open other ones. We know that as we have been in that situation with Jersey 1.x.
>>>
>>> This view is problematic for two reasons:
>>> The top 2 most requested features involve Spring and Guice support. We're talking about 4-5x more votes than anything else.
>>> I feel that you are misconstruing or misunderstanding the amount of work that is involved. I am not asking you to do half the things you mentioned above. Let's make sure we're in agreement on the work items before deciding on this proposal.
>> Except for #5 where I simply cannot make guarantees on behalf of the Jersey community, I agree.
>
> So, I think we're in agreement.
No, unfortunately, we are not. You say you want only small changes but in fact you are requesting a major piece of refactoring and changes to make it all really work. We cannot commit to deliver on that promise.
Feel free to prove me wrong though - try checking out and patching Jersey in your local workspace and then port it to Guice. If you insist on the fact that you do not want a lot from us at all, you should be able to quickly do it yourself - looking up for all the implementations of org.glassfish.hk2.api.Factory in Jersey code and making them public should be pretty straightforward. Once it is proven that I'm wrong and that your approach really works we can consider making actual changes in the jersey repo.
Until then, I'm afraid that we have reached a dead end in this discussion.
Marek
>
> Gili