I guess an even simpler approach is to use a Singleton bean with @Startup
declared... like the example here
http://download.oracle.com/javaee/6/tutorial/doc/gipvi.html
<
http://download.oracle.com/javaee/6/tutorial/doc/gipvi.html>
On Wed, Mar 9, 2011 at 7:20 PM, Arthur Yeo <artyyeo_at_gmail.com> wrote:
> Thanks Martin, for opening my eyes to Singletons and Context.
>
> I found something in *The Java EE 6 Tutorial (*PartNo: 821–1841–11, August
> 2010) on these topics and a simple prototype seems to prove it is working.
> However, I found that even without the presence of
>
> 1. @ApplicationScoped or
> 2. @Singleton
>
> declared, the lifetime of my Java object is still spanning across HTTP
> service calls in Jersey. I am not complaining, just wondering if things have
> been changed since the tutorial was released.
>
> Here's the code I have prototyped:
>
> ---------------------
> @Stateless
> @Path("/BlahRsrc")
> public class TransRsrc {
> @Context
> private UriInfo context;
>
> @Inject MyCachedData mcache;
>
> @GET
> @Produces("text/html")
> @ApplicationScoped // <<---- does not seem to make a difference
> @Path("/test")
> public String Getdbo(){
> System.out.println("Entering Getdbo()...");
> if (mcache == null) {
> mcache = new MyCachedData();
> }
> return ("AccId ==" + mcache.TellMeAccId().toString());
> }
>
> }
> -------------------
> @Default
> @Singleton // <<---- does not seem to make a difference
> public class MyCachedData {
> private dbObj dbo;
>
> public MyCachedData(){
> System.out.println("Entering ctor of MyCachedData...");
> if (dbo == null) {
> dbo = new dbObj();
> }
> }
>
> public Integer TellMeAccId(){
> return dbo.getAccId();
> }
> }
> ---------------------
> public class dbObj {
> private Integer accId;
>
> public dbObj(){
> System.out.println("Instantiating dbObj and accId is populated.");
> accId = new Integer(50);
> }
>
> public Integer getAccId(){
> return accId;
> }
> }
>
> ========================
>
>
>
>
> On Wed, Mar 9, 2011 at 10:01 AM, Martin Matula <martin.matula_at_oracle.com>wrote:
>
>> You can create your own provider class which can be a singleton and can
>> be injected on your resources.
>> See
>> http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/inject/SingletonTypeInjectableProvider.html
>>
>> Something like:
>> @Provider
>> public class MyCacheProvider extends
>> SingletonTypeInjectableProvider<Context, MyCache> {
>> public MyCacheProvider() {
>> super(MyCache.class, new MyCache());
>> }
>> }
>>
>> Then in your resources you can do:
>>
>> @Context MyCache cache;
>>
>> @GET
>> public String get() {
>> return cache.getCachedItem();
>> }
>>
>> Hope you get the idea.
>> Martin
>>
>>
>> On 9.3.2011 18:15, Arthur Yeo wrote:
>>
>> Martin,
>>
>> May be I should ask if there is "global" place in Jersey where I can
>> store something that's accessible by all RESTful services answering to
>> incoming requests?
>>
>>
>> On Wed, Mar 2, 2011 at 11:52 AM, Arthur Yeo <artyyeo_at_gmail.com> wrote:
>>
>>> Hi Martin,
>>>
>>> Jersey is beautiful and I love it.
>>>
>>> Since RESTful services are event-driven, what's the best practices to
>>> cache a bunch of static data (mainly configs stuffs) from the Db when my GF
>>> webapp *initially starts up*?
>>> I ask this because this operation is not exactly an HTTP event to
>>> response to incoming requests --- it's an internal startup op. How do you
>>> kick off something with no external events driving it?
>>>
>>> --
>>> Arthur Y.
>>>
>>
>>
>>
>> --
>> Arthur Y.
>>
>>
>
>
> --
> Arthur Y.
>
--
Arthur Y.