Ian Clarke wrote:
> Thanks Craig,
>
> I've got to say though that this seems exceedingly complicated for
> something that one might imagine you'd need to do in every non-trivial
> Jersey app.
>
> By way of comparison, in the Restlet framework, you just do something
> like:
> router.getContext().getAttributes().put("databaseConn", dbConn);
>
>
>
> You can then access it within the resource with something like:
> Connection conn = (Connection) context.getAttributes().get("dbConn");
>
> Why is this so much more complicated with Jersey?
Because Jersey does not pretend to play in the IoC framework space. It
would much rather integrate with IoC frameworks, so you don't have to
choose one approach for your REST resource classes and some other
approach for your back end services.
If what you want is stored as a servlet context attribute (which you did
not state AFAICT in your initial problem description), you can inject a
ServletContext object already and have total access to it's
capabilities. No extra code required ... and it's independent of which
JAX-RS framework you choose also.
>
> I switched to Jersey from Restlet because on the surface it looked
> simpler and more elegant, I regret to say that I'm now having doubts
> about this decision :-/
>
> (I'm not attacking those who've been kind enough to respond to my
> questions, I'm grateful for that - I'm just hoping that someone can
> convince me that either this isn't as complicated as it appears, or
> that there is a good justification for the complexity).
Keep in mind that Jersey *explicitly* chooses not to be an IoC framework
itself -- instead, it would much prefer to integrate with an IoC
framework that provides that sort of capabilities. An earlier comment
in this thread pointed you at the Guice integration, which is not
completely polished but definitely going in the right direction.
Another avenue to consider is to use the Spring integration, which is
pretty well advanced even now.
From the long term standards perspective, keep an eye on JSR-299 (used
to be "Web Beans"), which is focused on defining a component
architecture that melds the front end and back end stuff in a standard
way. In a Java EE 6 world, this will be the approach that gives you the
most flexibility, albeit it doesn't actually exist yet :-).
But, for your requirements as described in this subsequent message, you
don't need to go this way just for getting access to servlet context
attributes.
> Ian.
>
Craig
> On Mon, Mar 23, 2009 at 9:48 PM, Craig McClanahan
> <Craig.McClanahan_at_sun.com <mailto:Craig.McClanahan_at_sun.com>> wrote:
>
> Ian Clarke wrote:
>> Thanks for that.
>>
>> Can you point me to a simple example of using the Injectable
>> annotations?
> One example is in the contribs/jersey-multipart project, where I
> wanted to be able to inject an instance of
> "com.sun.jersey.multipart.MultiPartConfig" into my resource
> classes. I wrote a provider for this in class
> "com.sun.jersey.multipart.impl.MultiPartConfigProvider" and
> configured it with a
> "src/main/java/META-INF/services/com.sun.jersey.multipart.impl.MultiPartImplProvider"
> file that has to end up in META-INF/services in your
> WEB-INF/classes directory or inside a jar in WEB-INF/lib.
>
> This lets me inject resources (using @Context, as you correctly
> surmised) into classes like
> com.sun.jersey.multipart.impl.MultiPartReader.
>
> In my case, I declared that MultiPartConfig was a singleton, and
> created it in the getInjectable() method (which will only get
> called once because of the scope value).
>
> For dealing with JDBC, here's what I would suggest:
>
> * Configure a JDBC DataSource in the JNDI environment for your
> application.
>
> * In the getInjectable() method of your provider, do a JNDI lookup
> to get the
> DataSource instance.
>
> * Make the class of the injected object have a getDataSource()
> method on it
> that returns this data source instance.
>
> * In a resource method that received the injected object, have it call
> getDataSource().getConnection() on the injected object to get a
> connection,
> and then call connection.close() when you are through to return
> that connection
> to the data source's pool. Be sure you do this close even if an
> exception
> gets thrown along the way.
>
> The last step ensures that you won't have two (or more)
> simultaneous requests fighting over the same JDBC Connection
> instance, which is not allowed.
>
> Craig
>
>>
>> Ian.
>>
>> On Mon, Mar 23, 2009 at 7:19 PM, Erdinc Yilmazel
>> <erdinc_at_yilmazel.com <mailto:erdinc_at_yilmazel.com>> wrote:
>>
>> Hi,
>>
>> You may write your own Injectables and InjectableProviders for
>> injecting custom objects. You may even define your own
>> annotations for
>> that. See :
>>
>> com.sun.jersey.spi.inject.Injectable
>> com.sun.jersey.spi.inject.InjectableProvider
>> com.sun.jersey.spi.inject.Inject
>>
>> After writing and InjectableProvider you must annotate it with
>> @Provider annotation to make Jersey aware of that class.
>>
>> The @Context annotation has also its InjectableProvider.
>>
>> The other choice is using a IOC framework like google guice.
>> Support
>> for google guice may be bundled with the upcoming 1.0.3
>> version of
>> Jersey, but you can find an example code in jersey subversion
>> repository.
>>
>> Erdinc
>>
>> On Mon, Mar 23, 2009 at 11:33 PM, Ian Clarke
>> <ian.clarke_at_gmail.com <mailto:ian.clarke_at_gmail.com>> wrote:
>> > I have an object, lets say a SQL connection, that I want my
>> Jersey resource
>> > classes to have access to, but I don't want to make the SQL
>> connection
>> > static (because some day there may be more than one of them).
>> >
>> > How do I inject an object like this into a resource class
>> so that it can use
>> > it? For that matter, how do I tell resource classes about
>> any objects
>> > without making them available statically?
>> >
>> > I have a feeling it may be something to do with the
>> @Context annotation, but
>> > I haven't been able to find clear documentation on this.
>> >
>> > Any help would be appreciated,
>> >
>> > Ian.
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> <mailto:users-unsubscribe_at_jersey.dev.java.net>
>> For additional commands, e-mail:
>> users-help_at_jersey.dev.java.net
>> <mailto:users-help_at_jersey.dev.java.net>
>>
>>
>>
>>
>> --
>> Ian Clarke
>> CEO, Uprizer Labs
>> Email: ian_at_uprizer.com <mailto:ian_at_uprizer.com>
>> Ph: +1 512 422 3588
>> Fax: +1 512 276 6674
>
>
>
>
> --
> Ian Clarke
> CEO, Uprizer Labs
> Email: ian_at_uprizer.com <mailto:ian_at_uprizer.com>
> Ph: +1 512 422 3588
> Fax: +1 512 276 6674