Btw, a small side note on the 'manual' way you took in some Extensions: I now had to look at Seams persistence module because we got an OWB bug reported in conjunction with seam-persistence and I like to state that it is really hard to track down the producer for the EntityManager, etc because Seam does _not_ use CDI mechanics but instead provide all this stuff guice-like via AnnotatedTypeBuilder in an Extension. This is almost impossible to debug and to track down! Especially since this effectively disables all IDE tools for CDI.
LieGrue, strub --- On Sun, 7/10/11, Mark Struberg <[email protected]> wrote: > From: Mark Struberg <[email protected]> > Subject: Re: [seam-dev] Seam Startup Performance > To: "IIILincoln Baxter" <[email protected]> > Cc: "Seam Dev List" <[email protected]> > Date: Sunday, July 10, 2011, 11:31 AM > Of course, we'd first need to do a > performance evaluation to see if it would help a lot. > > In OpenWebBeans we did it 'half way' now. Whenever we > detect that a class doesn't have any Scope annotation > (directly or indirectly via an @Stereotype), nor any @Inject > or @Produces inside, we only initialize the bean meta info > as an empty shale. And if it gets injected into another bean > later, we just initialize this bean lazily. > > Of course, this trick didn't help that much with scanning > performance (maybe ~15%), but it greatly reduced the memory > footprint. > > Btw, we really should spec the exclude paths in beans.xml. > I now found the regarding issue already filed in > https://issues.jboss.org/browse/CDI-87 > I added a proper description, but Pete, could you please > edit the title and give it a more meaningful text? :) > > LieGrue, > strub > > > --- On Sat, 7/9/11, Lincoln Baxter, III <[email protected]> > wrote: > > From: Lincoln Baxter, III <[email protected]> > Subject: Re: [seam-dev] Seam Startup Performance > To: "Mark Struberg" <[email protected]> > Cc: "Stuart Douglas" <[email protected]>, > "Dan Allen" <[email protected]>, > "Seam Dev List" <[email protected]> > Date: Saturday, July 9, 2011, 11:00 PM > > At this point, I think that may actually be a good option. > I can't get forge to start up in under 8 seconds anymore. > I'm all for doing this I suppose, though it will be a bit of > a departure from the current functionality. I like the > auto-pickup, but this performance is pretty attrocious :( > > > On Sat, Jul 9, 2011 at 8:40 AM, Mark Struberg <[email protected]> > wrote: > > Folks, what if we step back and fix the CORE of this > disaster? > > > > Lets not pickup non CDI scope annotated beans as @Dependent > automatically anymore! > > > > We could automatically enable this feature if we detect a > version="1.1" in beans.xml. This way we can keep backward > compatibility > > > > LieGrue, > > strub > > > > --- On Fri, 7/8/11, Dan Allen <[email protected]> > wrote: > > > > From: Dan Allen <[email protected]> > > Subject: Re: [seam-dev] Seam Startup Performance > > To: "Stuart Douglas" <[email protected]> > > Cc: "Seam Dev List" <[email protected]> > > Date: Friday, July 8, 2011, 11:45 PM > > > > On Fri, Jul 8, 2011 at 19:27, Stuart Douglas <[email protected]> > wrote: > > > > > > Hi Guys, > > > > > > > > I was just looking at the startup performance of the Seam 3 > booking example on AS7, and I noticed that because the Seam > 2 archives that it deploys are bean archives, it actually > wastes quite a lot of time on startup registering Seam 3 > classes as CDI beans that are never used. > > > > > > > > > > > > > It occurred to me that we can get around this by using a > beans.xml that includes welds <scan> extension in > beans.xml to prevent uneeded beans being registered we could > significantly improve the performance and memory usage of > Seam 3 apps. > > > > > > > > > Now that the ridiculous visibility and extensions in > non-bean archive problems are resolved, I'm in favor of > switching back to registering beans manually rather than > using beans.xml. That seems like a performance enhancement > that's portable, so that we don't suck if Weld isn't the > provider. > > > > > > > But I agree we should do one of the two options. We'll be > moving tests around in Seam to align the setup, so it seems > like a good time to run tests with the updated bean > registration strategy. > > > > > > -Dan > > -- > > Dan AllenPrincipal Software Engineer, Red Hat | Author of > Seam in Action > > Registered Linux User #231597 > > > > http://www.google.com/profiles/dan.j.allen#about > > > > > > http://mojavelinux.com > > http://mojavelinux.com/seaminaction > > > > > > > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > seam-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > > _______________________________________________ > > seam-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > > > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
