EJB 3.1 Embedded Container API and the examples

[David Blevins <da...@gmail.com>]

Currently all our examples use the OpenEJB-specific InitialContext approach.  The main reason is that the Embedded API implementation is quite a bit different and it isn't possible to switch from one to the other without changes.

One of the tricks to making them the same is that there is a spec defined difference in default scanning behavior.  Our legacy default is to require ejb-jar.xml files (performance minded).  The spec approach is to not require descriptors (several times slower).

I was aware of this difference when we (the EG) made that rule, but was confident we (us here) could probably find some pragmatic compromise.

Here's my thoughts on that...

The spec doesn't require that even things like the VM classes have to be scanned.  This would be quite silly and definitely was not the intention of the "no descriptors required" rule.  So somewhere between everything and nothing is fair game.  A reasonable default that makes most people happy is all we need.  But what would that be?

With the package based filtering that we [will shortly] have we can switch from classpath based filtering and probably wind up with something that is way better.  The user can specify the packages they want us to scan.  In the event that no packages are specified, the bootstrapper (EJBContainer or IntialContext) will throw and catch an exception in initialization, which is triggered by user code, and *collect* the packages.  Those will be your defaults.

We can probably continue to filter out some packages (org.apache.openejb., javax., etc.) and maybe even chop the remaining packages down to two components "org.foo" so that we still have a nice and wide default namespace.  If people want to go wider or more narrow than that, they can take some explicit configuration action.

Thoughts?



-David

Re: EJB 3.1 Embedded Container API and the examples

[Thiago Veronezi <th...@veronezi.org>]

Hi, David!
Don't you think that a big ugly warning at startup time with some tips to
the user on how to improve the performance can do the job? This way we keep
the "ejb-jar.xml" (I love this one!), the "go through all classes" and the
"by package" approaches.

[]s,
Thiago.

On Tue, Mar 22, 2011 at 5:34 PM, David Blevins <da...@gmail.com>wrote:

> Currently all our examples use the OpenEJB-specific InitialContext
> approach.  The main reason is that the Embedded API implementation is quite
> a bit different and it isn't possible to switch from one to the other
> without changes.
>
> One of the tricks to making them the same is that there is a spec defined
> difference in default scanning behavior.  Our legacy default is to require
> ejb-jar.xml files (performance minded).  The spec approach is to not require
> descriptors (several times slower).
>
> I was aware of this difference when we (the EG) made that rule, but was
> confident we (us here) could probably find some pragmatic compromise.
>
> Here's my thoughts on that...
>
> The spec doesn't require that even things like the VM classes have to be
> scanned.  This would be quite silly and definitely was not the intention of
> the "no descriptors required" rule.  So somewhere between everything and
> nothing is fair game.  A reasonable default that makes most people happy is
> all we need.  But what would that be?
>
> With the package based filtering that we [will shortly] have we can switch
> from classpath based filtering and probably wind up with something that is
> way better.  The user can specify the packages they want us to scan.  In the
> event that no packages are specified, the bootstrapper (EJBContainer or
> IntialContext) will throw and catch an exception in initialization, which is
> triggered by user code, and *collect* the packages.  Those will be your
> defaults.
>
> We can probably continue to filter out some packages (org.apache.openejb.,
> javax., etc.) and maybe even chop the remaining packages down to two
> components "org.foo" so that we still have a nice and wide default
> namespace.  If people want to go wider or more narrow than that, they can
> take some explicit configuration action.
>
> Thoughts?
>
>
>
> -David
>
>
>
>