Hi, Filtering urls/dependencies is probably faster than packages, no?
However i think the ejb-jar approach could still be used/activated by configuration, it is really a pretty nive feature but it can't be the default one today, your proposal looks nice as the default behavior. - Romain ----- Reply message ----- De : "Thiago Veronezi" <[email protected]> Date : jeu., mars 24, 2011 18:39 Objet : EJB 3.1 Embedded Container API and the examples Pour : <[email protected]> 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 <[email protected]>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 > > > >
