BTW and as Karan say Singletons should be loaded in a separate thread
? cause if not the container will have to wait for the specified
retries or interval till the load succeeds or fails, right ?
On Tue, Aug 5, 2008 at 12:41 PM, Karan Malhi <[EMAIL PROTECTED]> wrote:
> What happens if the startup fails? Could we specify something like
> max-retries = 5, retry-interval = 10ms . It would be nice if the container
> makes the "best effort" to startup an EJB and that "best effort strategy"
> could be specified by the user in the form of the above two attributes. If
> we do not have something in the spec, do you think we could have something
> like these as custom openejb properties then.
>
> On Tue, Aug 5, 2008 at 12:10 AM, David Blevins <[EMAIL PROTECTED]>wrote:
>
>> More notes on the evolving javax.ejb.Singleton (aka @Singleton)
>> functionality.
>>
>> On Jun 28, 2008, at 2:10 PM, David Blevins wrote:
>>
>> -----------------------------------
>>> STARTUP
>>> -----------------------------------
>>>
>>> - @Startup
>>>
>>> Right now, the instances are created lazily when you first look them up.
>>> Startup could be easily supported by just instantiating the bean when the
>>> Container's deploy(DeploymentInfo) method is called.
>>>
>>> We could add an option on the container so people can control which they'd
>>> like to do by default. Any thoughts on what the default default should be?
>>> I.e. first access (lazy) or at startup?
>>>
>>> Again the spec group hasn't determined the ejb-jar.xml xml for specifying
>>> if the singleton bean should be loaded on startup. Any ideas?
>>>
>>
>>
>> For this I went for:
>>
>> <load-on-startup>true</load-on-startup>
>> <load-on-startup>false</load-on-startup>
>>
>> For a while I was thinking to have...
>>
>> <load-on-startup/>
>>
>> imply you wanted the singleton to be loaded on startup. But then it
>> occurred to me that if the bean was annotated @Startup and you wanted to use
>> xml to override that value, you pretty much need an explicit way to say
>> "false" via xml.
>>
>> As for our default, I think the default should be to *not* load the bean on
>> startup as there is only an @Startup annotation to turn on load-on-startup
>> and there is no @DontStartup or @Startup(false) annotation.
>>
>> -----------------------------------
>>> ORDERING
>>> -----------------------------------
>>>
>>> - @DependsOn(String[])
>>>
>>> Right now, we just load the beans in the order they are declared in the
>>> ejb-jar.xml or discovered in the jar. The @DependsOn allows you to list the
>>> ejbs that should be loaded before the bean in question. You can list beans
>>> by ejb-name.
>>>
>>> There are no real configurable options for this functionality that I see.
>>>
>>> Again the spec group hasn't determined the ejb-jar.xml xml for specifying
>>> if the "@DependsOn" data in the deployment descriptor. Any ideas?
>>>
>>
>> For this I went for:
>>
>> <depends-on>
>> <ejb-name>FooEJb</ejb-name>
>> <ejb-name>BarEjb</ejb-name>
>> </depends-on>
>>
>> I was tempted to use:
>> <depends-on>FooEjb</depends-on>
>> <depends-on>BarEjb</depends-on>
>>
>> But again, with that approach there is no explicit xml way to say "depends
>> on nothing" which you would need for annotation overriding. So the value of
>> <depends-on> is not considered additive, but definitive. With the
>> <depends-on> being definitive and a wrapper element, it's possible to
>> explicitly say:
>>
>> <depends-on/>
>>
>> As a way of overriding an @DependsOn({"FooEjb", "BarEjb"}) declaration in
>> the bean class.
>>
>> Code is still in progress.... Hopefully I can wrap this up this week.
>>
>> -David
>>
>>
>>
>>
>
>
> --
> Karan Singh Malhi
>
--
Thanks
- Mohammad Nour
