Extending JSR 330

[Gili]

Hi,

Do the Guice authors plan to extend JSR 330 in the near future? If not, are you willing to relinquish control of this JSR to others who have expressed a willingness to do so? The teams behind Jersey, HK2 and Glassfish have expressed a willingness to pick up this ball.

Thanks,

Gili

[Sam Berlin]

AFAIK, the JSR isn't owned by Guice or its authors.  The correct place to ask this question would be on the JSR 330 lists.

 sam

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

[cowwoc]

Hi Sam,

I have forwarded this question to Bob Lee and Rod Johnson. Tellingly, VMWare bounced my mail :)

    <rodjo...@vmware.com>: mail forwarding loop for rodjo...@vmware.com

I hope that Bob replies.

Gili

You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/2ipw6CAJc1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice...@googlegroups.com.

[Sam Berlin]

I suggest emailing the actual JSR lists instead of individual people.

 sam

[Christopher Currie]

The JSR list appears to be atin...@googlegroups.com.

https://groups.google.com/forum/#!forum/atinject

[Christopher Currie]

There is also an observer group that has less string membership requirements: https://groups.google.com/forum/#!forum/atinject-observer

[cowwoc]

The only mailing list I found off https://code.google.com/p/atinject/ is https://groups.google.com/forum/#!newtopic/atinject-observer

I posted the question there but it is awaiting moderation. Are you aware of any other list?

I tried https://groups.google.com/forum/#!forum/atinject but was denied permission (I believe membership is limited to the expert group).

Thanks,
Gili

[Stuart McCulloch]

On 2 Dec 2013, at 19:28, Gili <cow...@bbs.darktech.org> wrote:

> Hi,
>
> Do the Guice authors plan to extend JSR 330 in the near future? If not, are you willing to relinquish control of this JSR to others who have expressed a willingness to do so? The teams behind Jersey, HK2 and Glassfish have expressed a willingness to pick up this ball.

Sounds interesting, is there a link to the Jersey/HK2/GlassFish discussion?

> Thanks,
> Gili

[cowwoc]

Hi Stuart,

The discussion was scattered across multiple threads, but it
more-or-less started here:
https://java.net/projects/jersey/lists/users/archive/2013-11/message/74
(see the bottom of the message)

In short, we need Jersey to code against some portable mechanism so you
can swap in Guice, Spring or HK2 at configuration time but JSR 330
doesn't go this far. CDI 1.x is seen as bloated but the only possible
solution because JSR 330 is not being maintained.

Jersey made the incorrect assumption that they could code directly
against HK2 (a DI implementation) and it would "bridge" calls to
Guice/Spring/etc at runtime. In practice, Guice/Spring/etc don't provide
the necessary functionality to co-exist with another DI framework (e.g.
delegating injection). I'd like JSR 330 to be extended so that users may
use at most one DI at a time, but the actual implementation be chosen at
runtime.

The remaining alternative is to add injection delegation into Guice and
Spring, in which we'd be able to run multiple DIs at runtime. We don't
really need this if JSR 330 is fixed, but this might be quicker to
implement (less bureaucracy).

Gili

[Bob Lee]

I plan to continue to lead JSR-330 for the foreseeable future.

If you have specific feature requests, please file them here: https://code.google.com/p/atinject/issues/list

FWIW, I think it's too early to standardize on a single configuration approach, but Dagger represents the direction I'd probably take in 330 when the time is right.

Bob

--

[cowwoc]

Hi Bob,

I haven't seen any activity on the list (https://groups.google.com/forum/#!forum/atinject-observer) for over 3 years. Where is this activity taking place? Who is actively working on it?

There are many ways to solve the problem at hand, but first we need to agree on the use-case: the ability to code a library against some interface and have the user plug in a DI implementation at runtime. Do you plan to support this use-case?

I believe Guice is typically hidden under the hood of APIs. This problem only arises when an API chooses to expose a DI framework to the end-user (as Jersey does).

Note, you don't necessary to mandate a configuration interface to implement this. Instead of having the library code against a DI interface, it could code against one specific DI implementation and JSR 330 would need to mandate a mechanism for delegating injection from one implementation to another (i.e. "I don't know how to inject this, do you?").

Another interesting approach to investigate is SLF4J. SLF4J mandates a logging interface but not logger configuration. Library authors expose SLF4J but end-users are free to plug in a logger implementation (or multiple implementations) of their choice. I wonder what this model would look like when applied to Jersey.

Gili

You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/2ipw6CAJc1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice...@googlegroups.com.

[jwells...@gmail.com]

We have had a lot of discussion about configuration and DI systems.  To me the one that works best is the one from the OSGi DI system, but there is a long way to go to get to that kind of level (the Blueprint specification by Spring also tried to leverage it, but did not do as successful a job IMO).  There is a configuration subsystem in HK2 right now, but we are soon going to push that over into GlassFish because it is very specific to glassfish and has some other issues that make it very inflexible.