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
