Ok. So... what's there is basically the stateless container with a
couple tweaks so that it doesn't remove instances and only allows one
instance per bean.
Here's what we don't yet support. Will be making more jiras for these.
-----------------------------------
CONCURRENCY
-----------------------------------
- @BeanManagedConcurrency
- @ContainerManagedConcurrency
- @ReadOnly (shared access)
- @ReadWrite (exclussive access), the default
- ConcurrentAccessTimeoutException
The functionality we have now in regards to concurrency is compliant
with Container-Managed Concurrency and method default of ReadWrite.
I.e. only one person can use the singleton at a time. It'll be a bit
of work to break that up to support locking on a per method basis.
That'll be doable with the
java.util.concurrent.locks.ReentrantReadWriteLock class.
When we add that functionality we'll want to make an option on the
container to control how long a calling thread should wait till
timeout occurs and a ConcurrentAccessTimeoutException is thrown. Any
thoughts on what the default timeout should be? Couple seconds,
couple minutes, infinite?
The spec group hasn't determined what the related xml is for declaring
bean vs container concurrency management, so we'll have to make
something up. Same goes for how to specify the "concurrency
attribute" of a bean's methods. Any ideas on what the xml should look
like?
-----------------------------------
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?
-----------------------------------
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?
-David
