Support @Resouce injection for Datastore

It would be nice to be able to inject a reference to Datastore

@Resource DataStore datastore;

I think all injection helpers for main injection frameworks or libraries such as JEE, guice, Spring should be part of contrib rather than part of the core library. However core library should be able to support their basic needs.

@aozarov

Wait, why'd we close this? Seems like there was a bit more discussion needed? Thoughts @aozarov

I closed it because I responded and didn't get any feedback for 21 days.
@resource is a J2EE injection style and in general I think supporting any specific injection framework (including J2EE) is not the place of this core library but rather should come as an extension/contrib.

@jboynes

@jboynes Ping? Do you agree with @aozarov's opinion here? Is J2EE injection style pigeon-holing us into a single way of doing things? One that we wouldn't want to get stuck in?

The main thing to do is make the interfaces easily injectable, which is primarily about separating API functionality from configuration. We wouldn't need to integrate with any specific framework for this.

For an example, look at javax.sql.Datasource which separates the configuration of a JDBC connection from the methods used to interact with the database. The code that performs SQL operations is decoupled from the code used to establish the connection (or entry in the connection pool).

So unless there is something specific we do in the current APIs, we should
close the generic bug.
It will be addressed in layer above like dagger 2.x for servlets for
example.
On Jun 2, 2015 2:23 PM, "Jeremy Boynes" notifications@github.com wrote:

The main thing to do is make the interfaces easily injectable, which is
primarily about separating API functionality from configuration. We
wouldn't need to integrate with any specific framework for this.

For an example, look at javax.sql.Datasource which separates the
configuration of a JDBC connection from the methods used to interact with
the database. The code that performs SQL operations is decoupled from the
code used to establish the connection (or entry in the connection pool).

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

Let's keep the bug open until the issue is resolved and this can be done in an idiomatic way i.e. a simple Servlet with the code above works as is in Servlet 3.x container without needing additional frameworks like Dagger, Guice or Spring.

Which servlet container? The solution cannot be generic, right?

If it can let's keep the bug...otherwise...
On Jun 2, 2015 4:25 PM, "Jeremy Boynes" notifications@github.com wrote:

Let's keep the bug open until the issue is resolved and this can be done
in an idiomatic way i.e. a simple Servlet with the code above works as is
in Servlet 3.x container without needing additional frameworks like Dagger,
Guice or Spring.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

@jgeewax

I think it is very de-focusing having many long standing issues.
@jgeewax is there a method that you apply in the other Veneer projects for organizing issues based
on priority (and severity)? Do you use labels such as "nice to have"..?

Regardless, in this particular case core library should be lean and support the service's API in
an easy-to-use testable (which includes injectable) way but without any ties in its API level to
any framework including JEE. Users should be able to use gcloud-java from any application and
are not tied to be running in a servlet container.

@ludoch

@ludoch I think it can
@aozarov Seems plausible

Perhaps a PR is the best way to proceed

Perhaps a PR is the best way to proceed

I agree.

is there a method that you apply in the other Veneer projects for organizing issues based
on priority (and severity)

We just decided to start playing with these on gcloud-node, haven't decided whether they're the best option yet, but if we really feel like we need these here, we could go that route.

I think it is very de-focusing having many long standing issues.

I can't say I'm fully on-board with this, but I don't know if we should discuss these meta-issues here. Might be better (... ironically) to start a new issue to discuss this. We could decide which new labels to add and all that in that separate issue....

This commit contains a simple servlet that wants access to Datastore and the config file needed to enable that within Apache Tomcat. For other appservers the Servlet would be the same, just the configuration would be different.

Based on discussions I've had with the various parties, I think we are trending towards an agreement that it should be possible to inject a Datastore using @Resource or @Inject, but that the core API should not include that. Rather, we should have separate artifacts, which might include a Tomcat artifact containing Jeremy's servlet configuration. Or perhaps these cases are simple enough that they should just all be in example code.