You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2008/08/05 06:10:40 UTC
Re: Singleton Container
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
Re: Singleton Container
Posted by Mohammad Nour El-Din <no...@gmail.com>.
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 <ka...@gmail.com> 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 <da...@visi.com>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
Re: Singleton Container
Posted by David Blevins <da...@visi.com>.
On Aug 5, 2008, at 2:41 AM, Karan Malhi wrote:
> What happens if the startup fails?
Right now I have it so that it fails the deployment.
> 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.
Well the only way a singleton startup can fail is if the bean itself
threw an exception from the @PostConstruct method. So best effort
responsibility is definitely within the bean developer's realm of
control.
> If we do not have something in the spec, do you think we could have
> something
> like these as custom openejb properties then.
I'm not sure. Might be better to let the developers take care of this
themselves.
-David
Re: Singleton Container
Posted by Karan Malhi <ka...@gmail.com>.
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 <da...@visi.com>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